Vernetzt-kooperative Planungsprozesse im Konstruktiven Ingenieurbau GERMAN

Uwe Rüppel (Hrsg.) Vernetzt-kooperative Planungsprozesse im Konstruktiven Ingenieurbau

Uwe Rüppel (Hrsg.)

Vernetzt-kooperative Planungsprozesse im Konstruktiven Ingenieurbau Grundlagen, Methoden, Anwendungen und Perspektiven zur vernetzten Ingenieurkooperation Mit Beiträgen zahlreicher Fachwissenschaftler

Mit 189 Abbildungen und 4 Tabellen

123

Univ.-Prof. Dr.-Ing. Uwe Rüppel TU Darmstadt Institut für Numerische Methoden und Informatik im Bauwesen Petersenstr. 13 64287 Darmstadt, Germany [email protected]

Bibliografische Information der Deutschen Bibliothek Die Deutsche Bibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie; detaillierte bibliografische Daten sind im Internet über http://dnb.ddb.de abrufbar.

ISBN 978-3-540-68102-1 Springer Berlin Heidelberg New York Dieses Werk ist urheberrechtlich geschützt. Die dadurch begründeten Rechte, insbesondere die der Übersetzung, des Nachdrucks, des Vortrags, der Entnahme von Abbildungen und Tabellen, der Funksendung, der Mikroverfilmung oder der Vervielfältigung auf anderen Wegen und der Speicherung in Datenverarbeitungsanlagen, bleiben, auch bei nur auszugsweiser Verwertung, vorbehalten. Eine Vervielfältigung dieses Werkes oder von Teilen dieses Werkes ist auch im Einzelfall nur in den Grenzen der gesetzlichen Bestimmungen des Urheberrechtsgesetzes der Bundesrepublik Deutschland vom 9. September 1965 in der jeweils geltenden Fassung zulässig. Sie ist grundsätzlich vergütungspflichtig. Zuwiderhandlungen unterliegen den Strafbestimmungen des Urheberrechtsgesetzes. Springer ist ein Unternehmen von Springer Science+Business Media springer.de © Springer-Verlag Berlin Heidelberg 2007

Die Wiedergabe von Gebrauchsnamen, Handelsnamen, Warenbezeichnungen usw. in diesem Werk berechtigt auch ohne besondere Kennzeichnung nicht zu der Annahme, dass solche Namen im Sinne der Warenzeichen- und Markenschutz-Gesetzgebung als frei zu betrachten wären und daher von jedermann benutzt werden dürften. Text und Abbildungen wurden mit größter Sorgfalt erarbeitet. Verlag und Autor können jedoch für eventuell verbliebene fehlerhafte Angaben und deren Folgen weder eine juristische Verantwortung noch irgendeine Haftung übernehmen. Satz: Digitale Druckvorlage des Herausgebers Herstellung: LE-TEX, Jelonek, Schmidt & Vöckler GbR, Leipzig Umschlaggestaltung: WMXDesign GmbH, Heidelberg Gedruckt auf säurefreiem Papier 68/3100 YL – 5 4 3 2 1 0

Vorwort

Die ersten Überlegungen zur Erforschung der vernetzten Kooperation im Konstruktiven Ingenieurbau wurden bereits im Jahr 1997 anlässlich der siebten International Conference on Computing in Civil & Building Engineering (ICCCBE) in Seoul (Korea) geführt. Auf dieser Konferenz wurden erste Ansätze zum „Internet Enabled Engineering“ vorgestellt, das im Hinblick auf die Anforderungen einer vernetzten Kooperation innerhalb einer sich globalisierenden Bauwirtschaft ein großes Entwicklungspotential versprach. Das Thema wurde daraufhin im Arbeitskreis Bauinformatik und insbesondere mit den Kollegen Prof. Dr. Dr. h. c. mult. P. J. Pahl (Berlin), Prof. Dr.-Ing. K. Beucke (Weimar), Prof. Dr.-Ing. R. Damrath (Hannover, verstorben in 2003), Prof. Dr.-Ing. E. Rank (München), Prof. Dr.-Ing. Dr. E. h. U. F. Meißner (Darmstadt) und Prof. Dr.-Ing. D. Hartmann (Bochum) vertieft und es wurde der Entschluss gefasst, zu Beginn des Jahres 1999 einen Antrag bei der Deutschen Forschungsgemeinschaft (DFG) zur Schwerpunktförderung zum Themenbereich „Vernetzt-kooperative Planungsprozesse im Konstruktiven Ingenieurbau“ zu stellen. Das Schwerpunktprogramm wurde 1999 für die Dauer von 6 Jahren ab 2000 mit einem Volumen von ca. 7,5 Mio. EURO eingerichtet. Im Schnitt wurden 15 Projekte pro Jahr gefördert. Von herausragender Bedeutung für die kooperative Forschung und die Qualität der Ergebnisse und Erkenntnisse im Schwerpunktprogramm waren die jährlich durchgeführten Kolloquien: 2001 in Berlin, 2002 in Darmstadt, 2003 in Herrsching am Ammersee, 2004 in Braunschweig, 2005 in Dresden und das Abschlusskolloquium 2006 in Darmstadt. Im Hinblick auf den Transfer der Ergebnisse und Erkenntnisse in die Praxis wurden zwei Strategietreffen – 2003 in Berlin und 2005 in Weimar – mit Vertretern der Bauindustrie erfolgreich durchgeführt. Die dadurch erreichte große Praxisrelevanz der Forschungsarbeiten führte zur speziellen Einrichtung eines von der DFG geförderten Transferbereichs im Anschluss an das hier dargestellte Schwerpunktprogramm. Der Transferbereich besteht aus Transferprojekten, die mit den jeweiligen Ergebnissen und Erkenntnissen der Projekte des Schwerpunktprogramms konzipiert wurden und sachlich und zeitlich definierte Kooperationen zwischen Universitäten und Industrieunternehmen zum Forschungstransfer darstellen. Die internationale Präsentation der Projekte des Schwerpunktprogramms erfolgte regelmäßig im Rahmen der zu den jeweiligen Forschungsbereichen des Schwerpunktprogramms einschlägig ausgewiesenen Konferenzen: International Conference on Computing in Civil & Building Engineering (ICCCBE; 2000 in

VI

Uwe Rüppel

Stanford, 2002 in Taipei, 2004 in Weimar und 2006 in Montreal), internationales Kolloquium über Anwendungen der Informatik und der Mathematik in Architektur und Bauwesen (ikm) in Weimar (2000, 2003 und 2006), ASCE International Conference on Computing in Civil Engineering (2005 in Cancun, 2006 in Montreal), CIB W78's International Conference of Information Technology For Construction (2003 in Auckland, 2005 in Dresden, 2006 in Montreal) und die European Conference On Product And Process Modelling In The Building Industry (ECPPM; 2000 in Lissabon, 2002 in Portoroz, 2004 in Istanbul und 2006 in Valencia). Auf diesen Konferenzen fanden die präsentierten Ergebnisse und Erkenntnisse eine große Beachtung auf internationaler Ebene und es wurden viele wissenschaftliche Kontakte geknüpft und vertieft, die zu einer großen Internationalisierung der Forschungsarbeiten im Schwerpunktprogramm führten. Besonders erwähnen möchte ich an dieser Stelle die im Rahmen der internationalen Wissenschaftskooperationen des Schwerpunktprogramms durchgeführten Symposien im Iran 2002 (Teheran und Isfahan) und in Russland 2004 (Moskau und St. Petersburg). Wesentlich für den Erfolg des gesamten Schwerpunktprogramms waren die von der DFG berufenen Gutachter. Im Namen aller Projekte des Schwerpunktprogramms möchte ich mich an dieser Stelle bei den von der DFG eingesetzten Gutachtern, Herrn Prof. Dr.-Ing. K.-H. Boekeler (Stuttgart), Herrn Prof. Dr.-Ing. S. Holzer (München), Herrn Prof. Dr. M. Jarke (Aachen), Herrn Prof. Dr. S. Kirn (Hohenheim), Herrn Prof. Dr.-Ing. K. Lennerts (Karlsruhe), Herrn Dr.-Ing. R. Los (Amsterdam), Frau Prof. Dr. G. Malycha (Moskau), Herrn Prof. Dr. Dr. h. c. mult. P. J. Pahl (Berlin, Sprecher der Prüfungsgruppe), Herrn Prof. Dr. H. D. Rombach (Kaiserslautern) und Herrn Prof. Dr. G. Schmitt (Zürich) für die sehr engagierte und durch hohe Sachkompetenz geprägte Zusammenarbeit bedanken. Mein Dank gilt weiterhin meinen Fachkolleginnen und Fachkollegen und allen wissenschaftlichen Mitarbeiterinnen und Mitarbeitern, die in den Projekten des DFG-Schwerpunktprogramms 1103 hervorragende Forschungsarbeiten geleistet haben und so zum großen Gesamterfolg des Schwerpunktprogramms beigetragen haben. Besonders bedanken möchte ich mich bei meinem Kollegen Herrn Prof. Dr.-Ing. Dr. E. h. U. F. Meißner, der bis zu seinem Ruhestand das Schwerpunktprogramm gemeinsam mit mir koordiniert hat. Der DFG möchte ich im Namen aller am Schwerpunktprogramm beteiligten Kolleginnen und Kollegen sowie wissenschaftlichen Mitarbeiterinnen und Mitarbeitern für die sechsjährige Förderung und das damit entgegengebrachte Vertrauen danken. Insbesondere möchte ich im Namen aller Beteiligten Herrn Dr.-Ing. J. Hoefeld von der DFG-Geschäftsstelle in Bonn für seine hervorragende Betreuung als Fachreferent mit unermüdlicher Einsatzbereitschaft und für die wirksame Förderung sehr herzlich danken. Meinen Mitarbeitern Herrn Dipl.-Ing. M. Lange und Herrn Dipl.-Wirtsch.-Ing. A. Wagenknecht danke ich für die ausgezeichnete Unterstützung bei der Herausgabe dieses Buches. Dem Springer-Verlag sei gedankt, dass die Drucklegung des vorliegenden Abschlussberichts so zügig möglich war. Darmstadt, im Januar 2007 Uwe Rüppel

Inhaltsverzeichnis

Teil I

Überblick

1 Grundlegende Betrachtungen zur vernetzten Kooperation ...........................3 Uwe Rüppel 1.1 DFG-Schwerpunktprogramm 1103..............................................................3 1.1.1 Ausgangssituation und Zielsetzung ......................................................3 1.1.2 Struktur der Forschungsarbeiten...........................................................5 1.2 Kooperation .................................................................................................6 1.2.1 Grundlagen ...........................................................................................6 1.2.2 Kommunikation....................................................................................7 1.2.3 Koordination.........................................................................................9 1.2.4 Integratives Kooperationsmodell .......................................................12 1.3 Fazit und Ausblick .....................................................................................16 Literatur ...........................................................................................................17

Teil II

Netzwerkgerechte Prozessmodellierung

1 Überblick zum Themenbereich Netzwerkgerechte Prozessmodellierung ...21 Volker Berkhan 1.1 Ziele ...........................................................................................................21 1.1.1 Einführung und Motivation ................................................................21 1.1.2 Prozessmodellierung ..........................................................................22 1.1.3 Stand der Technik...............................................................................22 1.1.4 Zielsetzung .........................................................................................23 1.1.5 Lösungsstrategien...............................................................................24

VIII

Inhaltsverzeichnis

1.2 Arbeiten ..................................................................................................... 24 1.2.1 Relationale Prozessmodellierung in kooperativer Gebäudeplanung .. 25 1.2.2 Berücksichtigung von Ausnahmefällen bei der kooperativen Bearbeitung von Projekten des konstruktiven Tiefbaus ..................... 25 1.2.3 Prozessorientierte Vernetzung von Ingenieurplanungen am Beispiel der Geotechnik ................................................................................... 26 1.2.4 Prozessorientiertes Kooperationsmodell für eine anforderungsorientierte dynamische Unterstützung der Integralen Bauplanung..... 26 1.2.5 Neue Software-Werkzeuge zur Unterstützung des konzeptuellen Gebäudeentwurfs................................................................................ 27 1.3 Ergebnisse und Erkenntnisse ..................................................................... 27 1.3.1 Methoden und Algorithmen ............................................................... 27 1.3.2 Realisierung und Implementierung .................................................... 28 1.3.3 Vernetzt-kooperative Planungsprozesse............................................. 29 1.3.4 Perspektiven für weitere Forschungsarbeiten..................................... 29 Literatur ........................................................................................................... 30 2 Relationale Prozessmodellierung in kooperativer Gebäudeplanung ........... 31 Volker Berkhahn, Felix Hofmann, Axel Klinger, Markus König 2.1 Einleitung................................................................................................... 31 2.2 Ausgangssituation...................................................................................... 32 2.3 Zielsetzung................................................................................................. 32 2.4 Arbeiten und Ergebnisse............................................................................ 33 2.4.1 Prozessmodell .................................................................................... 34 2.4.2 Planungsvorgänge .............................................................................. 38 2.4.3 Ressourcen und Terminplanung......................................................... 42 2.4.4 Planungswerkzeug.............................................................................. 44 2.5 Ergebnisse.................................................................................................. 47 2.5.1 Anwendungsbeispiel .......................................................................... 48 2.5.2 Transferprojekt................................................................................... 48 2.6 Erkenntnisse............................................................................................... 49 2.7 Einordnung in den Gesamtzusammenhang des SPP.................................. 49 Nachwort ......................................................................................................... 50 Literatur ........................................................................................................... 50

3 Berücksichtigung von Ausnahmefällen bei der kooperativen Bearbeitung von Projekten des konstruktiven Tiefbaus .................................................... 53 Klaus-Peter Holz, Stavros Savidis, Frank Schley, Frank Rackwitz, Marcus Mejstrik 3.1 Vorbemerkungen ....................................................................................... 53 3.2 Einleitung und Zielsetzung ........................................................................ 55 3.2.1 Prozessabläufe im Spezialtiefbau....................................................... 55 3.2.2 Projektziele, Anforderungen und Randbedingungen.......................... 58

Inhaltsverzeichnis

IX

3.2.3 Lösungskonzept..................................................................................59 3.3 Beitrag des Projektes zu den Gesamtzielen des SPP und den Zielen der Arbeitsgruppe ............................................................................................60 3.4 Hybrides Informationsmanagement im Spezialtiefbau ..............................60 3.4.1 Ressourcenbasiertes Informationsmanagement..................................61 3.4.2 Modellbasiertes Informationsmanagement.........................................61 3.4.3 Modellmanagement ............................................................................66 3.5 Implementierung des Prototyps .................................................................69 3.6 Anwendungsbeispiel..................................................................................72 3.7 Zusammenfassung, Ausblick und Danksagung .........................................73 Literatur ...........................................................................................................74 4 Prozessorientierte Vernetzung von Ingenieurplanungen am Beispiel der Geotechnik ........................................................................................................75 Rolf Katzenbach, Uwe Rüppel, Armin Wagenknecht, Johannes Giere, Steffen Greb 4.1 Einleitung...................................................................................................75 4.2 Ergebnis- und Erkenntnisbeiträge des Projektes zu den Gesamtzielen des SPP und zu den Zielen der Arbeitsgruppe .................................................77 4.3 Prozessanalyse ...........................................................................................78 4.3.1 Bauteilorientierte Analyse von Planungsprozessen............................79 4.3.2 Anwendungsorientierte Analyse von Planungsprozessen ..................80 4.3.3 Normbasierte Analyse von Planungsprozessen ..................................80 4.4 Formale Beschreibung von Planungsprozessen .........................................81 4.4.1 Analyse von Methoden zur Prozessmodellierung ..............................81 4.4.2 Petri-Netze zur Prozessmodellierung .................................................81 4.4.3 Modellierung und Analyse von Bauprozessen auf der Basis von Petri-Netzen........................................................................................83 4.5 Vernetzte Kooperationsumgebung ProMiSE.............................................87 4.6 Validierung am Anwendungsbeispiel: Gallileo-Hochaus der DresdnerBank in Frankfurt/Main .............................................................................92 4.7 Zusammenfassung .....................................................................................94 4.8 Fazit ...........................................................................................................94 Literatur ...........................................................................................................95 5 Ein prozessorientiertes Kooperationsmodell für eine anforderungsorientierte dynamische Unterstützung der Integralen Bauplanung ............97 Petra von Both, Niklaus Kohler 5.1 Einleitung...................................................................................................97 5.2 Projektziele ................................................................................................98 5.3 Grundlagen des Projektes und Bewertung .................................................99 5.4 Lösungsansatz..........................................................................................101 5.4.1 Das systemische Projektmodell........................................................102 5.5 Konzeption des ProKoop-Prozessmodells ...............................................108

X

Inhaltsverzeichnis

5.5.1 Abhängigkeiten der Planungsprozesse ............................................. 111 5.5.2 Prozesskoordinierung über Statuswechsel ....................................... 112 5.6 Konzeptverifikation – Prototypische Umsetzung .................................... 112 5.7 Einordnung in den Gesamtzusammenhang des SPP................................ 116 5.8 Verknüpfung mit anderen Projekten des SPP .......................................... 117 Literatur ......................................................................................................... 117

Teil III Verteilte Produktmodelle 1 Überblick zum Themenbereich Verteilte Produktmodelle......................... 121 Berthold Firmenich, Ernst Rank 1.1 Ausgangsfragen und Zielsetzung............................................................. 121 1.2 Durchgeführte Arbeiten........................................................................... 122 1.3 Ergebnisse und Erkenntnisse ................................................................... 126 1.3.1 Modellbearbeitung und Modellverteilung........................................ 127 1.3.2 Produkt- und Wissensmodellierung ................................................. 128 1.3.3 Fazit.................................................................................................. 131 Literatur ......................................................................................................... 132 2 Verteilte Bearbeitung mit versionierten Produktmodellen im Bauwesen . 133 Karl Beucke, Berthold Firmenich, Daniel G. Beer, Torsten Richter 2.1 Einleitung und Zielsetzung ...................................................................... 133 2.2 Beitrag des Projekts zu den Gesamtzielen des SPP und der Arbeitsgruppe .......................................................................................... 134 2.3 Durchgeführte Arbeiten ........................................................................... 135 2.4 Erreichte Ergebnisse und deren Bedeutung ............................................. 136 2.4.1 Theoretische Grundlagen des Lösungskonzepts............................... 136 2.4.2 Beschreibung mit einer Mengenalgebra........................................... 143 2.4.3 Systemarchitektur............................................................................. 145 2.4.4 Anwendungsbeispiel ........................................................................ 148 2.5 Zusammenfassung und Fazit ................................................................... 152 Literatur ......................................................................................................... 152 3 Graphbasierte Werkzeuge zur Unterstützung des konzeptuellen Gebäudeentwurfs ........................................................................................... 155 Bodo Kraft, Manfred Nagl 3.1 Einleitung................................................................................................. 155 3.2 Ziele des Projekts..................................................................................... 156 3.3 Geleistete Arbeiten .................................................................................. 157 3.3.1 Szenario............................................................................................ 158

Inhaltsverzeichnis

XI

3.3.2 Semantische Modellierung konzeptueller Entwurfspläne ................160 3.3.3 Formalisierung konzeptuellen Fachwissens .....................................166 3.4 Umfeld .....................................................................................................172 3.4.1 Beitrag zu den Zielen des Schwerpunktprogramms .........................172 3.4.2 Projektpartner und wissenschaftliche Nachwuchsförderung ............173 3.4.3 Industrielle Verwertbarkeit der Ergebnisse ......................................174 3.5 Zusammenfassung ...................................................................................174 Literatur .........................................................................................................175 4 Allgemeingültige Benutzungsoberfläche für rechnergestützt koordinierte, vernetzt-kooperative Planungsprozesse ................................177 Georg Pegels, Torsten Weckmann 4.1 Vorbemerkungen .....................................................................................178 4.2 Einleitung und Zielsetzung ......................................................................179 4.3 Beitrag des Projekts zu den Gesamtzielen des SPP und den Zielen der Arbeitsgruppe ..........................................................................................179 4.3.1 Definition vernetzt-kooperativer Planungsprozesse für Stahl-, Metall-, Holz- und Glasbau ..............................................................180 4.3.2 Globale Verständlichkeit von Benutzungsoberflächen vernetztkooperativer Planungsprozesse ........................................................180 4.3.3 Rechnergestützte Koordination vernetzt-kooperativer Planungsprozesse .............................................................................181 4.4 Erkenntnisse zu Benutzungsoberflächen für überwacht koordinierte, vernetzt-kooperative Planungsprozesse ...................................................181 4.4.1 Allgemeingültigkeit (Internationalität) von Benutzungsoberflächen für vernetzt-kooperativ eingesetzte CAD-Hochleistungssysteme ....182 4.4.2 Benutzungsoberfläche für die rechnergestützte Koordination vernetzt-kooperativer Planung..........................................................186 4.5 Anwendungsbeispiele ..............................................................................190 4.6 Zusammenfassung und Ausblick .............................................................194 Literatur .........................................................................................................194 5 Ein Kooperationsmodell für die Kontrolle divergierender Planungszustände ..........................................................................................................197 Raimar J. Scherer, Matthias Weise, Peter Katranuschkov 5.1 Problemstellung und Projektziele ............................................................197 5.2 Lösungsansatz..........................................................................................198 5.2.1 Kooperationsmodell .........................................................................198 5.2.2 Kooperationsszenarien .....................................................................203 5.2.3 Bezug zu anderen Forschungsarbeiten des Schwerpunktprogramms...................................................................205 5.3 Forschungsergebnisse ..............................................................................206 5.3.1 Teildatensatzbildung und Modelltransformation..............................207 5.3.2 Modellvergleich ...............................................................................211

XII

Inhaltsverzeichnis

5.3.3 Modellzusammenführung................................................................. 213 5.4 Schlussfolgerungen.................................................................................. 216 5.4.1 Bewertung des Lösungsansatzes ...................................................... 216 5.4.2 Ausblick und Verwertungsmöglichkeiten ........................................ 217 Literatur ......................................................................................................... 218 6 Vernetzt-kooperative Gebäudeplanung im Massivbau mit verteilten deklarativen Wissensinstanzen und Fuzzy-Methoden................................ 219 Martina Schnellenbach-Held, Torben Pullmann, Markus Hartmann 6.1 Zusammenfassung ................................................................................... 219 6.2 Arbeits- und Ergebnisbericht ................................................................... 221 6.2.1 Ausgangslage ................................................................................... 221 6.2.2 Die Ergebnisse des Forschungsprojektes ......................................... 222 6.2.3 Ausblick auf zukünftige Arbeiten .................................................... 235 Literatur ......................................................................................................... 237

Teil IV Verteilte Simulation 1 Überblick zum Themenbereich Verteilte Simulation.................................. 241 Manfred Krafczyk 1.1 Ziele der Arbeitsgruppe ........................................................................... 241 1.1.1 Einführung und Motivation .............................................................. 241 1.1.2 Stand der Technik ............................................................................ 241 1.1.3 Verfolgte Ansätze in der Arbeitsgruppe........................................... 245 1.2 Arbeiten ................................................................................................... 245 1.2.1 Sensitivitätsanalyse netzwerkübergreifender Produkt- und Strukturmodelle bei Planungsprozessen des Konstruktiven Ingenieurbaus ................................................................................... 245 1.2.2 Ein Prototyp für verteilte, interaktiv-kooperative Simulationen zur Beschleunigung von Entwurfszyklen im Konstruktiven Ingenieurbau..................................................................................... 246 1.2.3 Volumenorientierte Modellierung als Grundlage einer vernetztkooperativen Planung im Konstruktiven Ingenieurbau .................... 247 1.3 Ergebnisse................................................................................................ 248 1.4 Erkenntnisse............................................................................................. 248 Literatur ......................................................................................................... 249

Inhaltsverzeichnis

XIII

2 Sensitivitätsanalyse netzwerkübergreifender Produkt- und Strukturmodelle bei Planungsprozessen des Konstruktiven Ingenieurbaus ...........251 Kai-Uwe Bletzinger, André Lähr 2.1 Zusammenfassung und Ziele ...................................................................251 2.2 Angewandte Methoden/Vorgehensweise.................................................252 2.2.1 Entwurf und Implementierung eines Kooperationsmodells .............253 2.2.2 Entwurf und Umsetzung eines Analysetools....................................258 2.3 Ergebnisse und ihre Bedeutung für das SPP1103 ....................................269 2.3.1 Beitrag zu den Zielen des SPP1103..................................................269 2.3.2 Beitrag zu den Zielen der Arbeitsgruppe..........................................270 Literatur .........................................................................................................271 3 Ein Prototyp für verteilte, interaktiv-kooperative Simulationen zur Beschleunigung von Entwurfszyklen im Konstruktiven Ingenieurbau.....273 Manfred Krafczyk, Jonas Tölke, Torsten Fahrig 3.1 Einleitung und Zielsetzung ......................................................................273 3.2 Stand der Forschung ................................................................................274 3.2.1 Produktmodelle und vernetzt-kooperative Planungsprozesse ..........274 3.2.2 Volumenbasierte Simulation ............................................................275 3.2.3 Computational Steering....................................................................275 3.3 Vernetzt-kooperativer Ansatz des Prototyps............................................275 3.4 Aufbau und Funktion des Prototypen ......................................................276 3.4.1 Geometrischer Modellierer...............................................................277 3.4.2 Volumenbasierte numerische Analyse und Paralleles Rechnen .......279 3.4.3 Visualisierer .....................................................................................279 3.4.4 Modelltransfer innerhalb des Software Prototyps ............................280 3.4.5 Einbeziehung mess-, steuer-, regeltechnischer Anlagen (MSRTechnik) über agentenbasierte Systeme ...........................................285 3.4.6 Multi-User-Umgebung .....................................................................288 3.5 Simulationsbeispiel..................................................................................289 3.6 Zusammenfassung und Ausblick .............................................................290 Literatur .........................................................................................................290 4 Volumenorientierte Modellierung als Grundlage einer vernetztkooperativen Planung im Konstruktiven Ingenieurbau .............................295 Ernst Rank, Hans-Joachim Bungartz, Richard Romberg, Ralf-Peter Mundani, Andreas Niggl 4.1 Einführung ...............................................................................................295 4.1.1 Rechnen am Gesamtsystem im Konstruktiven Ingenieurbau ...........296 4.2 Vom Bauwerksmodell zur volumenorientierten Tragwerksanalyse ........297 4.2.1 Ein standardisiertes Bauwerksmodell als Grundlage........................298 4.2.2 Analyse und Aufbereitung der Gebäudestruktur ..............................299 4.2.3 Dekomposition und Vernetzung des Modells...................................300

XIV

Inhaltsverzeichnis

4.2.4 Die p-Version der FEM zur Berechnung volumenbasierter Strukturen......................................................................................... 302 4.2.5 Volumenmodellierung im Konstruktiven Ingenieurbau................... 303 4.3 Oktalbaumbasiertes CSCW-Framework.................................................. 304 4.3.1 Generierung von Oktalbäumen ........................................................ 304 4.3.2 Kollisionserkennung und globale Datenkonsistenz.......................... 305 4.3.3 Regulierung von Zugriffen............................................................... 307 4.3.4 Agentenbasierte Benachrichtigungsdienste...................................... 307 4.4 Oktalbaum als grundlegendes Organisationsschema ............................... 308 4.4.1 Hierarchische Organisation des Gebäudeinformationsmodells........ 308 4.4.2 Integration und Einbettung von Simulationsaufgaben ..................... 310 4.4.3 Hierarchische Organisation und Einbettung einer Simulationsaufgabe .......................................................................... 311 4.4.4 Steuerung der Berechnung am Beispiel der Bauphasensimulation .. 315 4.5 Vernetzt-kooperative Planung ................................................................. 317 4.6 Zusammenfassung und Ausblick ............................................................. 317 Literatur ......................................................................................................... 318

Teil V

Agentensysteme

1 Überblick zum Themenbereich Agentensysteme......................................... 323 Dietrich Hartmann 1.1 Einleitende Bemerkungen........................................................................ 323 1.2 Einordnung der Agententechnologie ....................................................... 323 1.3 Agententechnologie für vernetzt-kooperative Planungsprozesse ............ 325 1.4 Verwendete Agentendefinitionen ............................................................ 326 1.5 Gruppierung von Agenten zu Multiagentensystemen.............................. 329 1.6 Realisierung und Implementierung.......................................................... 331 1.7 Ausblick................................................................................................... 333 Literatur ......................................................................................................... 334 2 Agentenbasierter Modellverbund für die kooperative Gebäudeplanung.. 335 Uwe Rüppel, Michael Lange, Mirko Theiß 2.1 Einleitung und Zielsetzung ...................................................................... 335 2.2 Beitrag des Projekts zu den Gesamtzielen des SPP und den Zielen der Arbeitsgruppe .......................................................................................... 336 2.3 Agentenbasierter Modellverbund ............................................................ 337 2.4 Fachmodelle zur verteilten Brandschutzplanung..................................... 339 2.4.1 Gebäudemodell ................................................................................ 339 2.4.2 Brandschutzmodell........................................................................... 340 2.4.3 Regelmodell ..................................................................................... 342

Inhaltsverzeichnis

XV

2.5 Modellverbund zur verteilten Brandschutzplanung .................................343 2.5.1 Agentenbasierte Informationsbereitstellung.....................................343 2.5.2 Fachgerechte Kommunikation zur Informationsrecherche...............344 2.5.3 Semantische Beschreibung des Kommunikationsinhaltes................345 2.5.4 Agentenbasierter Modelltransport ....................................................346 2.5.5. Regelbasierte Abbildung von Brandschutzanforderungen ..............347 2.5.6 Agentenbasierte Brandschutzplanung ..............................................348 2.6 Umsetzung und Anwendungsbeispiel......................................................349 2.6.1 Einleitung .........................................................................................349 2.6.2 Definition und Bereitstellung von brandschutzrelevanten Regeln ...351 2.6.3 Überprüfung der Anforderungen des baulichen Brandschutzes .......352 2.7 Zusammenfassung ...................................................................................354 Literatur .........................................................................................................355 3 Kooperative Tragwerksplanung basierend auf Multiagentensystemen und adaptiven Assoziationsnetzen ................................................................357 Jochen Bilek, Dietrich Hartmann 3.1 Vorbemerkungen .....................................................................................357 3.2 Einleitung und Zielsetzung ......................................................................358 3.3 Beitrag des Projektes zu den Gesamtzielen des SPP................................359 3.4 Agentenbasierter Lösungsansatz..............................................................359 3.5 Agentenmodell für die Tragwerksplanung...............................................361 3.5.1 Das agentenbasierte Kooperationsmodell ........................................362 3.5.2 Das agentenbasierte Produktmodell .................................................362 3.5.3 Das agentenbasierte Modell zur Prozessunterstützung.....................364 3.5.4 Das agentenbasierte Modell zur Softwareintegration.......................365 3.5.5 Das agentenbasierte Modell zur Integration von Fachwissen...........366 3.5.6 Kopplung der Teilmodelle................................................................368 3.6 Multiagentensystem für die Tragwerksplanung ACOS ...........................368 3.6.1 Design und Implementierung der Kooperations-Agenten ................370 3.6.2 Design und Implementierung des Produktmodell-Agenten..............371 3.6.3 Design und Implementierung des Workflow-Agenten.....................373 3.6.4 Design und Implementierung der Wrapper-Agenten........................375 3.6.5 Design und Implementierung des Nachweis-Agenten......................376 3.6.6 Eingesetzte Hard- und Software.......................................................376 3.7 Evaluierung und Anwendungsbeispiel.....................................................377 3.8 Zusammenfassung und Ausblick .............................................................379 Literatur .........................................................................................................380

XVI

Inhaltsverzeichnis

4 Komponentenbasierte Plattform für anpassbare, vernetzte Systeme im Bauwesen ........................................................................................................ 383 Armin B. Cremers, Sascha Alda 4.1 Einleitung................................................................................................. 383 4.1.1 Ziele des Projekts ............................................................................. 383 4.1.2 Beiträge des Projekts........................................................................ 384 4.1.3 Weitere Gliederung des Berichts...................................................... 385 4.2 Ergebnisse der Vorstudie ......................................................................... 385 4.2.1 Visionäres Szenario.......................................................................... 385 4.2.2 Use Case Diagramm......................................................................... 387 4.3 Die DEEVOLVE Plattform ........................................................................ 389 4.3.1 Peer Services und Komponentenmodell........................................... 389 4.3.2 Die DEEVOLVE Laufzeitumgebung (Plattform) ............................... 390 4.3.3 Integration von Standard-Software .................................................. 391 4.3.4 Ein Anwendungsszenario mit DEEVOLVE ........................................ 393 4.3.5 Integritätsbedingungen als Service-Kontrakt ................................... 394 4.4 Das COBE AWARENESS FRAMEWORK ..................................................... 397 4.4.1 Allgemeines Konzept ....................................................................... 397 4.4.2 Filterung von Ereignissen................................................................. 399 4.5 Integrative Architektur MAS-P2P ........................................................... 400 4.6 Zusammenfassung und Ausblick ............................................................. 402 Literatur ......................................................................................................... 402 Sachverzeichnis.................................................................................................. 405

Teil I Überblick

1 Grundlegende Betrachtungen zur vernetzten Kooperation

Uwe Rüppel Technische Universität Darmstadt, Institut für Numerische Methoden und Informatik im Bauwesen [email protected]

1.1 DFG-Schwerpunktprogramm 1103 1.1.1 Ausgangssituation und Zielsetzung Der dringende Forschungsbedarf für neue vernetzte Kooperationsformen im Konstruktiven Ingenieurbau zu Beginn des DFG-Schwerpunktprogramms 1103 im Jahr 1999 ergab sich aus der folgenden Sachlage: Zu häufig traten bei der Abstimmung der stark arbeitsteiligen Planungsprozesse in Bauprojekten Mängel auf. Zu oft reichten die traditionellen Prozessstrukturen zur Bewältigung der steigenden technischen Komplexität nicht mehr aus. Immer deutlicher zeichnete sich ab, dass die herkömmlichen Arbeitsprozesse bei Planung und Ausführung nicht für eine globalisierte, weltweit vernetzte Bauwirtschaft geeignet waren. Offensichtlich waren tief greifende Veränderungen zur Unterstützung der Ingenieurarbeit erforderlich. Aufgrund der zu diesem Zeitpunkt erstmalig gegebenen Verfügbarkeit von leistungsstarken Computernetzen ergaben sich viel versprechende Möglichkeiten für die Neugestaltung der Kooperation im Konstruktiven Ingenieurbau. Das von den Softwarehäusern bereits angepriesene „Internet Enabled Computing“, das beispielsweise den Austausch von CAD-Konstruktionszeichnungen im Computernetz ermöglichte, griff zu kurz. Essentielle Anforderungen an ein Network-Computing im Konstruktiven Ingenieurbau, insbesondere die netzwerkgerechte Strukturierung aller Teilprozesse mit Verarbeitung der gegenseitigen Abhängigkeiten und ebenso die transparente Darstellung der Konsequenzen von Planungsentscheidungen im Gesamtzusammenhang, wurden nicht erfüllt. Wirkliche Fortschritte waren deshalb erst zu erwarten, wenn die bisher stattfindende intuitive

4

Uwe Rüppel

Partner-zu-Partner-Kommunikation um netzwerkfähige Kooperationsmodelle ergänzt würde, die über eine disziplinübergreifende Semantik verfügen, die Zeitdimension der Projektarbeit erfassen und die Leitungs- und Lenkungsstrukturen der Projektbearbeitung abbilden. Besonders kennzeichnend für den Konstruktiven Ingenieurbau ist eine stark arbeitsteilige Entwicklung von Bauwerks-Unikaten mit hoher Änderungshäufigkeit bei der Projektierung, der Erstellung, der Nutzung und der Ertüchtigung bzw. Revitalisierung. Die hohe Komplexität der von vielen Partnern arbeitsteilig durchgeführten Ingenieuraufgaben konnte und kann dabei im internationalen Wettbewerb auf Dauer nur dann effizient und unter Beibehaltung hoher Qualitätsanforderungen bewältigt werden, wenn erstens die Planungsprozesse in einer verteilten Umgebung generisch zusammenwirken und zweitens Kooperationsmodelle für die Fachplanung im Informationsverbund der Projektbeteiligten entwickelt werden, so dass die kooperative Projektbearbeitung unter Nutzung zusammenfügbarer Teilprozesse und zugehöriger Fachmodelle in Computernetzen adäquat durchgeführt werden kann. Die enge Kooperation über Rechnernetze ist im Konstruktiven Ingenieurbau deshalb erforderlich, weil die einzelne Ingenieurleistung mit Blick auf das gemeinsame Ziel ganzheitlich orientiert sein muss, die einzelnen Ingenieuraktivitäten aufeinander aufbauen und aufeinander angewiesen sind, Entwurfs-, Konstruktions-, Bemessungs- und Bauprozesse iterativ abgewickelt werden und eine ganzheitliche Qualität aufgrund der Komplexität nur arbeitsteilig erreicht werden kann. Zur Entwicklung adäquater vernetzt-kooperativer Planungsprozesse war diesbezüglich dringend folgende Grundlagenforschung erforderlich: Aus der Sicht der Bauprojekte war der Bearbeitungsprozess systematisch zu analysieren und im Hinblick auf kompatible Informationsflüsse und Interaktionen in generisch zusammenwirkende Teilprozesse für eine verteilte Rechnerumgebung zu zerlegen. Aus der Sicht der Bauprojektbeteiligten waren der Kommunikationsbedarf und die fachlichen Anforderungen an die verschiedenen Formen der Kommunikation in einer verteilten Rechnerumgebung zu ermitteln. Für die Fachmodelle und Fachsoftware des Konstruktiven Ingenieurbaus waren Konzepte zur Integration und Verwaltung im Informations- und Kommunikationsverbund zu entwickeln und praxisnah zu erproben. Aus den geschilderten Anforderungen ergaben sich die folgenden wissenschaftlichen Hauptzielsetzungen:

x Neugestaltung der Planungsprozesse für Projekte des Konstruktiven Ingenieurbaus im Hinblick auf die Durchführung in einer verteilten Rechnerumgebung.

x Neukonzeption der Kommunikation hinsichtlich der Kooperationsinhalte und -formen aus Sicht der Projektbeteiligten.

x Entwicklung neuer Verfahren und Methoden zur Interaktion und Verwaltung der im Konstruktiven Ingenieurbau einsetzbaren Fachsoftware und Fachmodelle für die vernetzt-kooperativen Planungsprozesse.

Grundlegende Betrachtungen zur vernetzten Kooperation

5

x Entwicklung neuer Verfahren zur Analyse und fachgerechten Verarbeitung der Normen, technischen Regelwerke und Vorschriften im Informations- und Kommunikationsverbund. Hierzu waren neue Verfahren und Methoden in Zusammenarbeit mit der Informatik zu entwickeln. 1.1.2 Struktur der Forschungsarbeiten Zu Beginn der Forschungsarbeiten wurden vier Themenbereiche herausgearbeitet, die zur Erreichung der oben beschriebenen Zielsetzungen im gesamten DFGSchwerpunktprogramm 1103 von zentralem Interesse waren: 1. 2. 3. 4.

Verteilte Produktmodelle Netzwerkgerechte Prozessmodellierung Verteilte Simulation Agentensysteme

Zur Bearbeitung jedes Themenbereichs wurde eine Arbeitsgruppe gegründet. Jedes Projekt ordnete sich je nach individuellem Forschungsfokus einer Arbeitsgruppe zu. Auf dieser Grundlage wurde je Arbeitsgruppe der Themenbereich mit Arbeitspunkten in Bezug auf die Hauptziele konkretisiert, so dass sich die in Abb. 1.1 dargestellte Kooperationsmatrix für alle teilnehmenden Projekte ergab.

1 Beucke 2 Bletzinger 3 Cremers 4 Berkhahn (/ Damrath †) 5 Hartmann 6 Holz / Savidis 7 Katzenbach / Rüppel / Meißner 8 Kohler 9 Krafczyk / Tölke 10 Meißner / Rüppel 11 Nagl 12 Pegels 13 Rank / Bungartz 14 Scherer 15 Schnellenbach-Held

X X

X X X X

X X X X X X

X X X X X

X

Abb. 1.1. Kooperationsmatrix der Forschungsprojekte

Agentenbasierte Regelverarbeitung

X X

X X

X X

X X

X X X X X X

A

X

X X

MP

X X

X

Verfahren zur Regelverarb.

Wissensbanken

X X

A

Agenten-Wrapping

X

MSAP

IFC / XML / …

P

Integration der Software u. -modelle

Middle-Ware

A

X

P

Semantik zur Prozesssteuerung

Verteilte Modelle

Projektleiter

A

Agentenbasierte Kommunikation

X

M - Verteilte Produktmodelle P - Netzwerkger. Prozessmodellierung A - Agentensysteme S - Verteilte Simulation

MS

Konsistenz der Modelle

M S A P A P P P S A M M S M M

S

Arbeitsgruppen

Prozessbeschreibung und simulation

M

Mobile Verarbeitungsmethoden

AG

Neukonzeption der Kommunikation

Verteilte Simulation

Neugestaltung der Planungsprozesse

X X

X X X X

X

6

Uwe Rüppel

Mit der Kooperationsmatrix wurden die Forschungsarbeiten der Projekte sowohl innerhalb der Arbeitsgruppen als auch übergreifend mit Projekten anderer Arbeitsgruppen strukturiert. Diese Vorgehensweise erwies sich als sehr gut geeignet zur Erlangung hervorragender Forschungsergebnisse und -erkenntnisse für die Projekte, aber auch übergreifend für das gesamte Schwerpunktprogramm im Sinne der übergeordneten Zielstellungen. Im Folgenden werden aus übergeordneter Sicht die für alle Projekte des DFGSchwerpunktprogramms 1103 maßgeblichen Grundlagen erläutert. Die übergreifenden Forschungsansätze, -ergebnisse und -erkenntnisse der Projekte werden aufgezeigt. Weitere fachliche Detaillierungsstufen der Ergebnisse und Erkenntnisse sind den Überblicken zu den Themenbereichen, denen im Buch jeweils ein Teil gewidmet ist, und innerhalb der Themenbereiche den Beiträgen der Einzelprojekte zu entnehmen. Auf diese Weise wird erreicht, dass die Ergebnisse und Erkenntnisse strukturiert im Gesamtzusammenhang erläutert werden, und je nach individuellem Informationsbedürfnis von der Ebene Gesamtüberblick, zu Themenbereichsüberblick bis hin zum Einzelprojekt der Detaillierungsgrad der Ergebnisse und Erkenntnisse erhöht werden kann.

1.2 Kooperation 1.2.1 Grundlagen In der Ingenieurplanung verfügen die Fachplaner über spezialisierte Kenntnisse. Diesbezüglich sind die einzelnen Planungsaktivitäten auf Informationen der anderen Planungsbeteiligten angewiesen. Da die Dauer bei Bauprojekten begrenzt ist, müssen die Aufgaben arbeitsteilig und teilweise gleichzeitig in Kooperation durchgeführt werden. Allgemein wird Kooperation als die Zusammenarbeit mehrerer Gruppen, Personen und Organisationen in einem Team an einem gemeinsamen Material und auf ein gemeinsames Ziel hin bezeichnet (Bretschneider 1998). In der Ingenieurplanung werden von der heterogenen Bauprojektorganisation gemeinsam Dokumente, Pläne und Modelle mit dem Ziel erstellt, ein virtuelles Bauwerk im Sinne von Handlungsanweisungen für das real zu erstellende Gebäude zu entwickeln. Die beteiligten Personen werden dabei als Akteure bezeichnet. Die Typisierung eines Akteurs im Hinblick auf die für die Aufgabenerledigung erforderlichen Eigenschaften, wie z.B. Wissen, Rechte, Pflichten und Fähigkeiten, wird als Rolle bezeichnet. Dadurch können in der Ingenieurplanung erforderliche Rollen unabhängig von den tatsächlich beteiligten Personen und Organisationen spezifiziert werden. Die Kooperation kann implizit durch die Arbeit am gemeinsamen Material oder explizit durch den bewussten Austausch von Informationen im Sinne einer Konversation erfolgen.

Grundlegende Betrachtungen zur vernetzten Kooperation

7

Die Kooperation kann einerseits hinsichtlich des Ortes klassifiziert werden: Sie wird als zentral bezeichnet, wenn alle Beteiligten am selben Ort arbeiten und als verteilt, wenn die Beteiligten an verschiedenen Orten agieren. Andererseits kann eine Klassifikation auch hinsichtlich der Zeit erfolgen: Die Kooperation wird als synchron wechselseitig bezeichnet, wenn die Planungsaktivitäten gleichzeitig zusammen an genau einem Bereich des gemeinsamen Materials erfolgen. Diese Art der Kooperation erfolgt meistens bei Planungskonflikten. Als synchrone parallele Kooperation wird auch das parallele Arbeiten, d.h. die gleichzeitige Bearbeitung verschiedener Teile des gemeinsamen Materials, bezeichnet. Hierzu ist eine vorherige Aufteilung des gemeinsamen Materials in einzelne, voneinander unabhängig zu bearbeitende Arbeitsbereiche erforderlich. Die Kooperation wird als asynchron sequentiell bezeichnet, wenn die Bearbeitung der zugewiesenen Teilaufgaben nacheinander im Sinne eines Arbeitsflusses zu unterschiedlichen Zeiten erfolgt. Zur Kooperation ist eine Kommunikation zwischen den Planungsbeteiligten erforderlich. Als Kommunikation wird der reine Austausch von Informationen zwischen den Planungspartnern zum Zwecke der Verständigung bezeichnet. Die Kommunikationsform beschreibt das Darstellungsmittel, mit dessen Hilfe Informationen ausgedrückt werden, wie z.B. verbal (Text, Grafik etc.) und nonverbal (Gestik, Mimik etc.). Als Kommunikationsmittel wird das Medium zur Überwindung der räumlichen und/oder zeitlichen Distanz bezeichnet. Grundsätzlich ist zu beachten, dass Kommunikation für die Kooperation eine notwendige Voraussetzung ist. In Anlehnung an die zeitliche Klassifikation der Kooperation kann die Kommunikation auch synchron oder asynchron erfolgen. Die Planungstätigkeiten auf dem gemeinsamen Material in der Ingenieurkooperation stehen oftmals in Konkurrenz, d.h. die individuellen Ziele der Beteiligten stehen im Konflikt zueinander. Für die Lösung dieser Planungskonflikte ist eine Koordination erforderlich. Die Koordination besteht aus der Abstimmung konkurrierender Planungstätigkeiten auf dem gemeinsamen Material und der Verwaltung der Abhängigkeiten zwischen den aufgabenbezogenen Tätigkeiten. Als vernetzt-kooperative Ingenieurplanung wird die fachtechnische Kooperation in Computernetzen bezeichnet, die software-gestützte Koordinationsmechanismen unterschiedlicher Automatisierung und Granularität in Bezug auf die Prozesse und Modelle beinhaltet (Rueppel u. Lange 2006). In den nächsten Abschnitten werden die Ergebnisse und Erkenntnisse des DFG-Schwerpunktprogramms 1103 in Bezug auf die erforderlichen Anwendungssituationen der Kommunikation und Koordination sowie der darauf aufbauenden vernetzten Kooperationsmethoden eingeordnet und zusammenfassend im integrativen Kooperationsmodell dargestellt. 1.2.2 Kommunikation Zur Unterstützung der Kommunikation gibt es eine Vielzahl von StandardSoftware-Umgebungen, wie z.B. Video- und Audiokonferenzsysteme zur

8

Uwe Rüppel

Unterstützung der synchronen Kommunikation und E-Mail im Rahmen asynchroner Kommunikation. Diese branchenübergreifenden Systeme sind als Ergänzung der im DFG-Schwerpunktprogramm 1103 erforschten spezifischen Kommunikationsmethoden für den Konstruktiven Ingenieurbau zu sehen. Kommunikation dient in der Regel dazu, ein Informationsdefizit zu beheben. Eine effiziente Kommunikationsmöglichkeit stellt die Informationsbeschaffung mit Software-Agenten (nachfolgend Agenten bezeichnet) dar (Kirn et al. 2006). Hierbei ist zwischen stationären Agenten, die ortsgebunden lokale Aufgaben erledigen, und mobilen Agenten, bei denen einzelne Agenten über das Rechnernetz migrieren können, zu unterscheiden. Nach dem heutigem Stand der Forschung können Agenten folgende Eigenschaften besitzen, die sie von herkömmlichen Software-Systemen unterscheiden: Sie agieren autonom ohne direkte Intervention eines menschlichen Auftraggebers, sie kommunizieren mit anderen Agenten bzw. menschlichen Auftraggebern, sie nehmen ihre Umgebung wahr und können mit den sie betreffenden Veränderungen umgehen und sie regieren nicht nur auf ihre Umgebung, sondern ergreifen auch selbst Initiativen (Kirn et. al. 2006). Im Bereich der asynchronen Kommunikation ist speziell die Kategorie der Informationsagenten zu nennen, die Informationsquellen aufspüren, Informationen aus Quellen extrahieren, aus der Gesamtmenge der gefundenen Informationen die dem Interessensprofil des Benutzers entsprechenden herausfiltern und die Ergebnisse in anschaulicher Form aufbereiten und präsentieren. Die Forschungsergebnisse der Arbeitsgruppe „Agenten“ lassen erkennen, dass neben der Informationsbeschaffung auch für die Koordination der Ingenieurplanungen Agenten eine hervorragende Lösungsstrategie darstellen (Rueppel u. Lange 2006). Die Kommunikation in den Prozessen des Planens und Bauens besteht zu einem Großteil aus dem Austausch von Dokumenten, wie z.B. CAD-Plänen oder Leistungsverzeichnissen, zwischen den Projektbeteiligten. Eine gemeinsame, digitale Informationsverwaltung stellt einen ersten Ansatz zur Verbesserung der Kommunikation zwischen den Projektbeteiligten dar. Dieser Informationsverbund ist gegenwärtig mit Projektkommunikationssystemen (PKS), die als Online-Portale mit orts- und zeitunabhängigem Zugriff auf Planungs- und Ausführungsinformationen speziell bei großen Bauprojekten zum Einsatz kommen, realisiert und wird in der Praxis angewendet. Internetbasierte Projektkommunikationssysteme gehören zur Kategorie des Computer Supported Cooperative Work (CSCW). Mit CSCW wird das universelle Arbeitsgebiet des verteilten, kooperativen Arbeitens und die dazugehörigen Forschungsgebiete bezeichnet. Hierzu gehören Systeme zur Kommunikations-, Koordinations- und Kooperationsunterstützung. Projektkommunikationssysteme bieten neben den allgemeinen Kommunikationsdiensten des Internets, die den Anwender bei der Kommunikation (E-Mail) mit dateibasiertem Austausch von Informationen unterstützen, zusätzliche, an die Planungsabläufe angepasste Funktionen. Derartige Systeme sind eine zentrale Plattform für alle an einem Projekt beteiligten Akteure. In einem Datenpool, d.h. dem Dokument-Management-System (DMS), werden sämtliche

Grundlegende Betrachtungen zur vernetzten Kooperation

9

Planungs- und Ausführungsunterlagen bereitgestellt, z.B. CAD-Daten, Leistungsverzeichnisse und Terminpläne. Für Fachinformationen in der Ingenieurplanung werden als Kommunikationsform z.B. die Schnittstellendefinitionen gemäß STEP (ISO 10303) und IFC (Industry Foundation Classes; ein standardisiertes Bauwerksmodell) verwendet. Insbesondere für den Bereich der Leistungsverzeichnisse sind hier die Standardisierungen nach dem Gemeinsamen Ausschuss für Elektronik im Bauwesen (GAEB) zu nennen und für den Dokumentenaustausch im Allgemeinen EDIFACT (DIN 2005). Problematisch ist hierbei nach wie vor die Konvertierung der Dateiformate. Für diese Problematik bilden so genannte Wrapper-Agenten eine hervorragende Lösungsstrategie (s. Teil V „Agentensysteme“). 1.2.3 Koordination Um eine konsistente Modellierung der hochkomplexen Bauplanungsprozesse zu erreichen, ist es notwendig, grundlegende mathematische Modelle zu entwickeln und zu nutzen, um die verschiedenen Aspekte der Kooperation, wie beispielsweise unterschiedliche Fachdomänen, Verwaltung der Arbeitsmodelle und Arbeitsmethoden, Aspekte der Gestaltung menschlicher Arbeit, Berücksichtigung moderner Kommunikationsmethoden und die Koordination der Planungsvorgänge, beherrschbar zu machen und in einer Prozesssteuerungsumgebung abzubilden. Hierfür bieten formale Methoden der Prozessmodellierung, wie beispielweise Petri-Netze und Workflow-Graphen, eine geeignete Grundlage (Rueppel u. Klauer 2004). Andere Industriezweige, wie zum Beispiel der Maschinenbau, belegen, dass es grundsätzlich möglich ist, erhebliche Verbesserungen in der Planung und Produktion durch den Einsatz von innovativen Methoden der Prozessmodellierung zu erreichen. Diese können dann in einer prozessoptimierten vernetzten Kooperationsumgebung abgebildet und verwaltet werden, um zu einer besseren Qualität durch Vorausplanung und Controlling sowie zu größerer Termin- und Kostensicherheit zu kommen. Aus der vernetzten und computergestützten Prozessmodellierung ergeben sich neue Arbeitsweisen und Kooperationsformen zwischen den Beteiligten im Sinne eines elektronischen Workflows, die insgesamt zu einer höheren Effizienz der Planung und Ausführung im Bauwesen führen. Workflow-Management Ein Workflow ist die Automation eines Geschäftsprozesses im Ganzen oder in Teilen, in dessen Verlauf Dokumente, Informationen oder Aufgaben zur Erfüllung von Tätigkeiten von einem Teilnehmer zum anderen gemäß prozeduraler Regeln geleitet werden. Workflows sind dabei überwiegend als ergonomische und weniger als technische Prozesse zu verstehen, da die Ausführung der Aktivitäten in der Regel eine Interaktion zwischen Mensch und Maschine erfordert.

10

Uwe Rüppel

Workflow-Management beschäftigt sich mit den Aufgaben, die bei der Modellierung, der Simulation sowie bei der Ausführung und Steuerung von Workflows erfüllt werden müssen. Workflows können je nach Strukturiertheit und Grad der Prozessorientierung in verschiedene Typen klassifiziert werden. Hierzu wird folgende Kategorisierung vorgenommen:

x Ad-hoc-Abläufe: Ad-hoc-Vorgänge werden in Form von kurzlebigen Arbeitsschritten realisiert. Bei gängigen Projektkommunikationssystemen zeigt sich ein solcher Workflow häufig als Plan- bzw. Dokumentenlauf in unterschiedlich starker Ausprägung. Es werden Aufgaben mit Terminverfolgung definiert und häufig auf Basis eines Mail-Systems verteilt, die beispielsweise die Erstellung oder Bearbeitung eines Plans fordern. Nach der Bearbeitung der Aufgabe wird ein Genehmigungszyklus in Gang gesetzt, der die Überprüfung des Ergebnisses an weitere dafür vorgesehene Projektbeteiligte als Aufgabe übermittelt. x Strukturierte Abläufe: Strukturierte Abläufe können für oft auftretende Vorgänge mit vorhersehbaren Situationen verwendet werden. x Semistrukturierte Abläufe: Eine Mischform stellen semistrukturierte Abläufe dar. Offene Gruppenprozesse beinhalten keine Ablaufregeln, erfordern aber dennoch definierte Eingangs- und Ausgangsinformationen für die Vorgänge. Kontrollierte Gruppenprozesse sind auf einen bestimmten Kreis von Beteiligten mit unterschiedlichen Zugriffsmöglichkeiten beschränkt. Eine für Bauprojekte geeignete Workflow-Kategorie ist der strukturiert vorgegebene Ablauf mit der Möglichkeit von Ad-hoc-Modifikationen. Hier kann trotz vorstrukturierter Prozesse flexibel auf Besonderheiten im Sinne von dynamischen Abweichungen, die während der Durchführung eines Bauprojektes auftreten, reagiert werden. Mit einem Workflow-Management-System (WfMS) werden Workflows definiert, erzeugt und deren Ausführung verwaltet. Solch ein System ist in der Lage, die Prozessdefinitionen zu interpretieren, mit den Teilnehmern zu kommunizieren und – wenn nötig – andere Applikationen aufzurufen. Workflow-Management-Systeme eignen sich besonders für stark strukturierte Prozesse. Grundsätzlich gibt es viele Bereiche, in denen man sich den erfolgreichen Einsatz von Workflow-Management-Systemen vorstellen kann. Besonders geeignet sind sie zur Unterstützung von Vorgängen, die in der Regel folgende Eigenschaften aufweisen:

x Eine hohe Anzahl von Personen oder Anwendungen ist in den Vorgang einbezogen. x Der Vorgang weist einen hohen Strukturierungsgrad auf. x Der Vorgang hat einen hohen Koordinierungsbedarf. x Der Vorgang hat eine hohe Wiederholungsrate und erfordert wenige Ausnahmebehandlungsmechanismen. Die durchgeführten Forschungsarbeiten ergaben, dass die Einführung eines Workflow-Management-Systems in eine Bauprojektorganisation einen beachtens-

Grundlegende Betrachtungen zur vernetzten Kooperation

11

werten Aufwand darstellt, der durch den Nutzen des Systems gerechtfertigt werden muss. Je nach Art der Bauprojektorganisation und des Bauprojektes können sich unterschiedliche Effekte ergeben. Ausgewählte Vorteile, die grundsätzlich durch den Einsatz von Workflow-Management-Systemen im Konstruktiven Ingenieurbau erreicht werden können, sind:

x Erhöhte Produktivität: Zeiteinsparungen werden z.B. durch Optimierung der Kooperation im Sinne der Mängelvermeidung und der aufgabengerechten Informationsbereitstellung mit schnellem Zugriff erreicht. x Nachweisbarkeit: Die Dokumentation von Abläufen wird von den Systemen übernommen. Das ist vor allem dort von Bedeutung, wo diese Dokumentation vorgeschrieben ist. x Qualitätssicherung: Das System überwacht die Ausführung von Aktivitäten und sorgt dafür, dass sie auch wirklich erledigt werden oder meldet zumindest, dass die Erledigung noch aussteht. x Auskunftsfähigkeit: Der aktuelle Bearbeitungsstand eines Vorgangs kann jederzeit ermittelt werden. Voraussetzung für den Einsatz des Workflow-Managements im Sinne einer vernetzten Kooperation im Konstruktiven Ingenieurbau ist die netzwerkgerechte Modellierung der Planungsprozesse. Prozessmodellierung Eine erfolgreiche Kooperation – d.h. die Zusammenarbeit mehrerer Personen, Gruppen oder Institutionen in einem Team an einem gemeinsamen Material auf ein gemeinsames Ziel hin – kann nur erreicht werden, wenn die Kommunikation in einem Bauprojekt durch Koordination strukturiert wird. Solch eine automatisierte semantisch-koordinierte Kommunikation bedingt das Vorhandensein eines Prozessmodells. Im Sinne der Koordinierung des Informationsflusses werden in den in der Baupraxis eingesetzten Projektkommunikationssystemen i.d.R. Verteilerlisten und Benachrichtigungen verwendet, die individuell nach der Bearbeitung jedes einzelnen Arbeitsschritts ad hoc definiert werden können. Dadurch können Abhängigkeiten zwischen den kooperierenden Beteiligten und den durch diese ausgeführten Tätigkeiten nicht vollständig erfasst werden (Rueppel u. Klauer 2004). Im Falle von Änderungen in Planung und Ausführung kann eine adäquate Berücksichtigung von Auswirkungen auf andere Tätigkeiten und Beteiligte somit nicht automatisiert erfolgen. Die Entscheidung, auf welche Projektpartner sich Auswirkungen ergeben, obliegt stattdessen der subjektiven Einschätzung des Bearbeiters des jeweiligen Arbeitschritts. Zur Unterstützung der Kooperation ist hier die Entwicklung von Prozessmodellen im Sinne des Workflow-Managements erforderlich. Solche Prozessmodelle wurden in der Arbeitsgruppe „Netzwerkgerechte Prozessmodellierung“ erforscht. 

12

Uwe Rüppel

Gemäß Definition der Workflow Management Coalition ist ein Prozess die inhaltliche und sachlogische Folge von Aktivitäten, die zur Bereitstellung eines Objekts in einem spezifizierten Endzustand notwendig ist (Fischer 2006). Zur Erstellung von Prozessdefinitionen wird die Prozessmodellierung als Formalismus mit entsprechenden Ausdrucksmitteln verwendet. Beispiele für Methoden zur Prozessmodellierung sind: Aktivitäts-, Sequenz- und Zustandsdiagramm der Unified Modelling Language (UML), ereignisgesteuerte Prozess-Ketten (EPK), Netzplantechniken, Workflow-Graphen und Petri-Netze (s. Teil II „Netzwerkgerechte Prozessmodellierung“). Ein Klassifizierungsmerkmal zur Eignung einer Modellierungsmethode stellt der Formalisierungsgrad dar. Der Grad der Formalisierung gibt an, inwieweit die Syntax und Semantik der Modellierungselemente festgelegt sind, was gerade beim Übergang vom Prozessmodell hin zum ausführbaren Workflow eine wesentliche Rolle spielt. Nicht-formale (z.B. UML) und semi-formale (z.B. EPK und Netzplan) Modellierungsmethoden werden in der Praxis zur Modellierung eingesetzt, sind aber in der Regel nicht für Analysen, Simulationen oder eine Überführung in einen projektbegleitenden, ausführbaren Workflow geeignet. Formale Methoden, wie Petri-Netz und WorkflowGraph, hingegen erlauben eine durchgängige Verwendung in allen Phasen des Workflow-Managements. Analysen und Simulationen von Prozessmodellen sind notwendig, um Konflikte identifizieren zu können, so dass das Prozessmodell strukturell richtig ist und eindeutig definiert, analysiert, verifiziert und verbessert wurde, bevor es zur Unterstützung der Ausführung von Prozessen eines Bauprojekts in einem Workflow-Management-System eingesetzt wird. Um die Ausführung der modellierten und verifizierten Prozesse während eines Bauprojekts mit einem Workflow-Management-System zu unterstützen, zu überwachen und zu steuern, ist der Einsatz eines Laufzeitsystems (Workflow-Engine) erforderlich. Hierbei handelt es sich um eine spezielle Software-Komponente, welche die einzelnen Arbeitsschritte gemäß des im Prozessmodell definierten strukturellen und zeitlichen Ablaufs in Aufgaben überführt und diese den Projektbeteiligten in Form von Aufgabenlisten zuweist. Das Laufzeitsystem überwacht darüber hinaus den Ausführungsstatus der sequentiell oder nebenläufig ablaufenden Aktivitäten und unterstützt die Projektbeteiligten in Entscheidungssituationen, die sich durch alternative Verzweigungen der Prozesse ergeben. Gegebenenfalls ist eine Interaktion mit externen Fachanwendungen notwendig, um die verschiedenen Aktivitäten auszuführen. Abweichungen vom Prozessmodell, die sich erst während der Durchführung der Prozesse ergeben, werden ebenfalls mit dem Laufzeitsystem verarbeitet. Zur Berücksichtigung der Koordination der stark arbeitsteiligen Planungsprozesse wurden im DFG-Schwerpunktprogramm 1103 daher neue, für Bauprojekte geeignete Methoden zur Prozessmodellierung, Prozessanalyse und Prozessausführungsunterstützung entwickelt. Insbesondere die Wiederverwendung von Prozesswissen im Sinne der Erfahrungen abgeschlossener Bauprojekte bietet Möglichkeiten zur Steigerung der Qualität und Effizienz für nachfolgende Bauplanungen.

Grundlegende Betrachtungen zur vernetzten Kooperation

13

1.2.4 Integratives Kooperationsmodell Zur Unterstützung der Kooperation gibt es eine Vielzahl von branchenübergreifenden Standard-Software-Umgebungen, wie z.B. Shared Whiteboard und Application Sharing. Diese Systeme sind als Ergänzung der im DFGSchwerpunktprogramm 1103 erforschten spezifischen Kooperationsmethoden für den Konstruktiven Ingenieurbau zu sehen. Im Zuge der im Konstruktiven Ingenieurbau häufig auftretenden synchronen wechselseitigen Kooperation ergibt sich die Problemstellung der Bearbeitung des gemeinsamen Datenbestandes. Die Erforschung solcher Datenbestände zur vernetzten Anwendung im Konstruktiven Ingenieurbau war Gegenstand der Arbeitsgruppe „Verteilte Produktmodelle“. Als Produktmodell wird ein einheitliches Informationsmodell bezeichnet, das alle Lebenszyklen eines Produktes erfasst und die Sichten der beteiligten Fachplanungen abbildet. Produktmodelle für Bauwerke, auch kurz Bauwerksmodelle genannt, werden mit objektorientierten Methoden entwickelt. Grundsätzliche Methoden zur Bauwerksmodellierung wurden bereits im vorangegangenen DFG-Schwerpunktprogramm der Bauinformatik „Objektorientierte Modellierung in Planung und Konstruktion“ erforscht (Hartmann 2000). In der Arbeitsgruppe „Verteilte Produktmodelle“ wurde erarbeitet, welche Eigenschaften vernetzte Produktmodelle aufweisen müssen, damit sie für vernetztkooperative Planungsprozesse geeignet sind. In den Forschungsprojekten sind Anwendungsszenarien dargestellt, die verdeutlichen, dass die Nutzung von Produktmodellen im Rahmen einer synchronen wechselseitigen Kooperation grundsätzlich zu einer Qualitätserhöhung führen kann. Im Rahmen der synchronen parallelen Kooperation ergibt sich die Problemstellung, die Aufgaben der Beteiligten so zu strukturieren, dass die Bearbeitung in Perioden unabhängig erfolgen kann. Die Ergebnisse der parallelen Bearbeitung sind zyklisch abzugleichen. Hieraus ergeben sich spezielle Anforderungen an den gemeinsamen Datenbestand im Sinne vernetzter Produktmodelle. Im Hinblick auf die Nutzung der Produktmodelle zur Simulation von Systemen, beispielsweise zur Prognose des Verhaltens eines Tragsystems bei bestimmten Belastungen, treten im Allgemeinen Konflikte bei der Zusammenführung parallel bearbeiteter Simulationsmodelle auf. Zur Vermeidung dieser Konflikte werden neue Methoden zur konsistenten Modellentwicklung und Modellverwaltung im Sinne einer vernetzten Kooperation benötigt. Dies stellte den Schwerpunkt der Forschungsarbeiten in der Arbeitsgruppe „Verteilte Simulation“ dar. Es wurden diesbezüglich die methodischen Entwicklungen und exemplarischen Validierungen von Simulations- und Organisationsmodellen auf unterschiedlichen Verteilungsebenen im Sinne der Konfliktminimierung bei der Bearbeitung durch vernetzte Planungspartner durchgeführt. Die in den Projekten der Arbeitsgruppe „Verteilte Simulation“ aufgeführten Anwendungen zeigen, dass sich die entwickelten Methoden und Modelle grundsätzlich bewährt haben, aber im Hinblick auf die Praxistauglichkeit noch einer Weiterentwicklung bedürfen. Im Rahmen der asynchronen Kooperation ist das gemeinsame Material zu Beginn so zu strukturieren, dass eine sequentielle Bearbeitung erfolgen kann. Die zu-

14

Uwe Rüppel

gehörige Kommunikation ist ebenfalls asynchron und die Koordination erfolgt über Workflows. Insgesamt führen die Ergebnisse und Erkenntnisse aller Projekte des DFGSchwerpunktprogramms 1103 zu einem integrativen Kooperationsmodell für den Konstruktiven Ingenieurbau, das in Abb. 1.2 dargestellt ist. Das integrative Kooperationsmodell besteht aus vier Schichten, die die grundsätzlichen Elemente einer Kooperationsumgebung für den Konstruktiven Ingenieurbau darstellen. 1. Über die Kommunikationsschicht werden die dynamischen Nachrichtenverbindungen moderner Kommunikationsnetze in die Prozessmodellierung einbezogen. Hierbei sind insbesondere alle Wählverbindungen zu beachten, die für die Informationsübertragung dynamisch geschaltet werden können und für deren Einbindung auf der Koordinationsebene entsprechende Ereignisbeobachter vorgesehen werden müssen. Das Bauwesen ist durch einen sehr hohen Grad an Arbeitsteilung und Heterogenität der Planungsorganisation gekennzeichnet. Daher ist es notwendig, in diese Schicht die spezifische Projektkommunikation einzubinden, die neben der klassischen Kommunikation - wie Brief, Telefon, Fax und E-Mail - auch dokumenten- und modellbasierte synchrone und asynchrone Kommunikation berücksichtigt. Insbesondere ergaben die Forschungsarbeiten, dass mobile Agenten hervorragend zur Unterstützung der Kommunikation geeignet sind. In Teil V „Agentensysteme“ sind hierfür entwickelte Agenten aufgeführt. 2. In der Organisationsschicht werden die beteiligten Fachplaner bzw. deren Repräsentation abgebildet, soweit sie die Hoheit über die Zustände des Prozessmodells innehaben und bei den Arbeitsvorgängen des Prozessmodells mitwirken. Mithilfe wohl definierter Rollen werden in dieser Ebene die Rechte und Fähigkeiten der Fachorganisationen des Konstruktiven Ingenieurbaus erfasst und mit den Modellen und Verarbeitungsmethoden der Ressourcen-Ebene verknüpft. Ziel dieser Ebene ist die Integration von fachlichen Entscheidungen und Handlungskompetenzen, die letztendlich für eine rechtssichere Bauplanung von maßgebender Bedeutung sind. Insbesondere belegen die Forschungsarbeiten zu Agentensystemen in Teil V, dass zur Unterstützung der am Planungsprozess beteiligten Fachplaner Agenten automatisierbare Überwachungs- und Handlungsaufgaben übernehmen können, um so im Kommunikationsverbund als digitaler Interessenvertreter des Fachplaners zu agieren. Dadurch ergeben sich – wie in Teil V dargestellt – enorme Steigerungspotentiale im Hinblick auf Effizienz und Qualität der Kooperation. 3. Die Koordinationsschicht dient zur Modellierung und Ablaufsteuerung der Arbeitsvorgänge und des Informationsflusses. In dieser Ebene werden die zeitabhängigen Planungsaktivitäten und Informationszustände erfasst. Mit mathematischen Modellen der Prozessmodellierung werden die Abfolge und die Synchronisation der sequentiellen, iterativen und nebenläufigen Arbeitsvorgänge geregelt. Petri-Netze erwiesen sich hierfür wegen der zu Grunde liegenden mathematisch beschreibbaren Struktur als geeignet. Die im Hinblick auf vernetzt-kooperative Planungsprozesse erforschten Metho-

Grundlegende Betrachtungen zur vernetzten Kooperation

15

den zur Analyse, Modellierung und Simulation von Prozessen sind in Teil II „Netzwerkgerechte Prozessmodellierung“ aufgeführt.

Dynamische Kommunikation

Organisation (Akteure, Rollen)

Digitales Netz

b

b

b

Beobachter

b Ereignis

Vorgang Koordination (Workflows, Prozessmodelle)

Zustand

Zustand

Vorgang

Ressourcen Methoden Modelle

Wissen

Abb. 1.2. Integratives Kooperationsmodell

4. Die Ressourcenschicht umfasst die Modelle, das Wissen und die Verarbeitungsmethoden, die zur Ausführung der Planungsvorgänge benötigt werden. Sie stellt netzwerkgerechte Methoden und Werkzeuge zur Speicherung und Manipulation von Objekten mit deren spezifischen Zuständen in den verschiedenen Planungsphasen als Grundlage für das vernetzt-kooperative Arbeiten zur Verfügung. In Teil III „Verteilte Produktmodelle“ werden hierzu die entwickelten fachspezifischen Produktmodelle und zugehörigen Verarbeitungsmethoden für die verteilte Nutzung im Verbund der Planungspartner dargestellt. Für die Prognose von Systemreaktionen unter speziellen Einwirkungen und Randbedingungen sind Modellierung und Simulation integrale Bestandteile des Planungsprozesses. Die erforschten Simulationsmodelle und -methoden für komplexe Ingenieursysteme, die von den verteilten Planungspartnern im Verbund betrieben und genutzt werden können, sind in Teil IV „Verteilte Simulation“ dargestellt. Die Einführung des integrativen Kooperationsmodells in die Baupraxis erfordert neben den hier beschriebenen innovativen Software-Methoden und -Modellen aber auch die Schaffung der geeigneten wettbewerbsrechtlichen Rahmenbedingungen: Weg von der preiswettbewerbsorientierten Konfrontation hin zur synergieschaffenden Kooperation mit Wertschöpfungspotential über technologische Innovation (Girmscheid 2005).

16

Uwe Rüppel

1.3 Fazit und Ausblick Zusammenfassend ist die Evolution der Modelle und Methoden der Bauinformatik zu vernetzten Kooperation in Abb. 1.3 dargestellt. Durch die interdisziplinäre Forschung im DFG-Schwerpunktprogramm 1103 wurden zusammenfassend neue wissenschaftliche Grundlagen

x zur Gestaltung der Bearbeitungsprozesse des Konstruktiven Ingenieurbaus im Informations- und Kommunikationsverbund,

x zur Erhöhung der Transparenz und der Entscheidungssicherheit im Gesamtzusammenhang von Projekten des Konstruktiven Ingenieurbaus und

x zur Steigerung der Effizienz der arbeitsteiligen Projektbearbeitung bei gleichzeitiger Qualitätsverbesserung geschaffen. Austausch von „flachen Daten“ und Produktmodellen in Dateien

Nutzung von Produktmodellen in zentraler Datenbank

Nutzung verteilter Produktmodelle in inhomogener Umgebung

Integratives Kooperationsmodell

b

STEP, IFC

Daten

Objekte (Daten & Methoden)

b

b

b

CORBA

Verteilte Objekte mit Middleware

Prozessgesteuerte Agenten mit verteilten Produktmodellen und Simulationen im dynamischen Kommunikationsverbund

Internet 11111010111

Entwicklungsfortschritt

Abb. 1.3. Evolution der Kooperation

Die Aufteilung der Forschungsarbeiten in vier Arbeitsgruppen mit jeweils zentraler Themenstellung erwies sich als äußerst effizient und führte zu hervorragenden Forschungsergebnissen und weiterführenden Erkenntnissen. Insbesondere bleibt festzuhalten, dass in den mit den Arbeitsgruppen fokussierten Themenbereichen ein enormes Potential zur Verbesserung der Kooperation steckt, welches in den jeweiligen Einzelprojekten aufgezeigt wird.

Grundlegende Betrachtungen zur vernetzten Kooperation

17

Die vielfältigen Anwendungsgebiete der Forschungsprojekte stellen sicher, dass die Ergebnisse und Erkenntnisse des DFG-Schwerpunktprogramms 1103 in unterschiedlichen Fachdomänen des Konstruktiven Ingenieurbaus ihre Anwendung finden werden. Als weitere Maßnahme zum Transfer der Ergebnisse und Erkenntnisse in die Baupraxis konnte im Anschluss an das hier vorgestellte Schwerpunktprogramm die Förderung eines Transferbereichs durch die DFG erreicht werden. In diesem Transferbereich werden Nachfolgeprojekte zu Projekten des Schwerpunktprogramms 1103 als Transferprojekte gefördert. Diese Transferprojekte sind eine sachlich und zeitlich definierte Kooperationen zwischen Universitäten und Industrieunternehmen, die der Umsetzung und Überprüfung der prinzipiellen praktischen Realisierbarkeit („proof of principle“) von Ergebnissen und Erkenntnissen der wissenschaftlichen Grundlagenforschung des DFG-Schwerpunktprogramms 1103 in die Praxis dienen.

Literatur Bretschneider D (1998) Modellierung rechnerunterstützter, kooperativer Planung in der Tragwerksplanung. VDI, Düsseldorf DIN Deutsches Institut f. Normung e. V. (2005) Datenaustausch im Geschäftswesen und in der Verwaltung. Beuth Verlag Fischer L (2006) 2006 Workflow Handbook. Future Strategies Inc. Girmscheid G (2005) Partnerschaften und Kooperationen in der Bauwirtschaft – Chance oder Irrweg? Fachzeitschrift „Der Bauingenieur“, Bd 80, Springer, Berlin Heidelberg, S 103–113 Hartmann D (2000) Objektorientierte Modellierung in Planung und Konstruktion. WileyVCH GmbH, Weinheim Kirn S, Herzog O, Lockemann P, Spaniol O (2006) Multiagent Engineering. Springer, Berlin Heidelberg Rueppel U, Klauer T (2004) Internet-based Workflow-Management for Civil Engineering Projects. Proceedings of the 10th International Conference on Computing in Civil & Building Engineering, Paper 159 Rueppel U, Lange M (2006) An Integrative Process Model for Cooperation Support in Civil Engineering. Electronic Journal of Information Technology in Construction (www.itcon.org)

Teil II Netzwerkgerechte Prozessmodellierung

1 Überblick zum Themenbereich Netzwerkgerechte Prozessmodellierung

Volker Berkhahn Leibniz Universität Hannover, Institut für Bauinformatik [email protected]

1.1 Ziele 1.1.1 Einführung und Motivation Planungsprozesse im Ingenieurwesen sind dynamische Prozesse, die über die Prozesslaufzeit hinsichtlich des Umfangs, der Struktur und des Inhalts variieren. Planungsprozesse des Bauingenieurwesens zeichnen sich darüber hinaus durch die Komplexität der unikatartigen Bauvorhaben, durch eine hohe Prozessdynamik, durch die Vielzahl von Planungsakteuren und durch sehr differenzierte Planungsaufgaben aus. Hierbei bedingt die Komplexität der Bauvorhaben eine große Bandbreite an fachspezifischen Planungsakteuren, die in Abhängigkeit vom jeweiligen Planungsstand differenzierte Planungsinformationen benötigen. Weiterhin existiert eine Vielzahl von spezifischen Vorschriften und Regeln, die in Abhängigkeit von dem jeweiligen Bundesland variieren können, in dem das Bauvorhaben realisiert werden soll. Die Planungsakteure sind in der Regel unterschiedlichen Organisationseinheiten zugeordnet. Die Kooperation der Planungsakteure erfolgt häufig über eine räumliche Distanz und die Kooperationspartner sind oft nicht aufeinander eingespielt. Weiterhin können die Planungsakteure aus verschiedenen Organisationen bei einigen Bauvorhaben als Kooperationspartner und bei anderen Bauvorhaben als Konkurrenten auftreten. Die Informations- und Kommunikationstechnologie hat in den letzten Jahrzehnten eine rasante Entwicklung erfahren. Die aktuellen Software-Werkzeuge zur Prozessplanung nutzen die neuen Möglichkeiten dieser aktuellen Technologie nur begrenzt aus. Es besteht in der Baupraxis ein Bedarf für Planungswerkzeuge,

22

Volker Berkhahn

die die Kooperation verteilter Planungsakteure effizient unterstützen und die relevanten spezifischen Planungsinformationen für den jeweiligen Planungsakteur zur Verfügung stellen. 1.1.2 Prozessmodellierung Entsprechend der einschlägigen Fachliteratur (z.B. Scheer 1995, Janusz 1998) aus dem Bereich der Wirtschaftsinformatik wird durch einen Prozess die logische Abfolge von Aktivitäten und Zuständen beschrieben, die für die Bearbeitung einer Aufgabe erforderlich sind. Hierbei ist eine Aktivität ein Schritt im Arbeitsablauf, der durch einen Akteur ausgeführt wird und Zeit oder Kosten erfordert. Ein Zustand beschreibt die Systemeigenschaften zu einem bestimmten Zeitpunkt. Jeder Prozess besitzt einen definierten Anfang und ein definiertes Ende. Die Prozessmodellierung kann in das Prozessmodell, die Prozessanalyse und die Prozesssteuerung gegliedert werden. Ein Prozessmodell stellt ein Modell eines realen Prozesses dar und wird entsprechend einer bestimmten Modellierungsmethode erzeugt. Beispielsweise können Prozesse mit Netzplänen, Graphensystemen oder Petri-Netzen modelliert werden. Für das Prozessmodell sind Aktivitäten und Zustände sowie deren logische und zeitliche Abfolge zu identifizieren. Gegebenenfalls können zusätzlich Ressourcen in Form von beispielsweise Zeit, Kosten, Material oder Personal in das Prozessmodell einbezogen werden. Die Prozessanalyse beinhaltet das qualitative und quantitative Analysieren von Prozessen. Wird ein Prozess beispielsweise als Petri-Netz modelliert, so stehen nach (v. d. Aalst 2000) oder nach (v. d. Aalst u. v. Hee 2002) Methoden und Algorithmen der Strukturanalyse zur Verfügung, um Blockaden oder mangelhafte Synchronisationen im Prozessmodell zu identifizieren. Neben der reinen Strukturanalyse sind Simulationen des Prozessablaufs möglich. Die Prozesssteuerung umfasst die Koordination von Aktivitäten und Teilprozessen sowie das Initiieren von Aktivitäten als Reaktion auf Ereignisse. Ziel ist hierbei die Optimierung der Prozesse hinsichtlich definierter Zielvorgaben, die beispielsweise den Kostenaufwand, den Zeitbedarf oder die Produktqualität umfassen können. 1.1.3 Stand der Technik In Anlehnung an (Greb u. Klauer 2004) lassen sich die wesentlichen Standardisierungsansätze für die Prozessmodellierung wie folgt zusammenfassen: Die Workflow Management Coalition (WfMC 2006) stellt einen Zusammenschluss von Anwendern, Softwareanbietern und Wissenschaftlern dar. Im Rahmen dieses Zusammenschlusses stehen die Identifizierung von Gemeinsamkeiten verschiedener Workflow-Produkte und die Entwicklung geeigneter Spezifikationen zur Implementierung von Workflow-Produkten im Fokus der Aktivitäten. Angestrebte Verbesserungen zielen auf die Interoperabilität zwischen verschiedenen

Überblick zum Themenbereich Netzwerkgerechte Prozessmodellierung

23

Workflow-Produkten sowie auf die Integration von Workflow-Produkten und Anwendungen bzw. Diensten der Informationstechnologie ab. Die Business Process Management Initiative (BPMI 2006) und die Object Management Group (OMG) haben sich 2005 zur Business Modeling & Integration Domain Task Force (BMI.OMG 2006) zusammengeschlossen. Zielsetzung dieser neuen Gruppe ist die Spezifikation von Modellen für Geschäftsprozesse. Hierdurch soll die firmeninterne und firmenübergreifende Zusammenarbeit von Mitarbeitern, Geschäftspartnern und Kunden sowie von Softwaresystemen und Prozessabläufen verbessert werden. Die Architektur Integrierter Software Systeme (ARIS 2006) stellt ein Rahmenkonzept zur ganzheitlichen Modellierung von computergestützten Informationssystemen dar, wobei der Fokus auf der Unterstützung von betriebswirtschaftlichen Geschäftsprozessen liegt. Die Prozessmodellierung stützt sich auf ereignisgesteuerte Prozessketten und spezifische Sichten für Organisationen, Daten, Funktionen, Leistungen und Steuerungen. Mit den Industry Foundation Classes der Industrieallianz für Interoperabilität (IAI 2006) ist ein Standard für die digitale Beschreibung von Gebäudemodellen definiert worden. Durch die IFC Process Extension wird das Ziel verfolgt, zusätzlich Bauprozesse zu berücksichtigen. Hierbei sollen Organisationen und Personen mit den auszuführenden Aktivitäten und mit prozessrelevanten Informationen modelliert werden. Die erstgenannten Standardisierungen beziehen sich auf die Modellierung von Geschäftsprozessen. Für eine Prozessmodellierung im Rahmen einer vernetztkooperativen Planungsumgebung im Konstruktiven Ingenieurbau erfüllen die aufgeführten Standardisierungen nicht die Anforderungen. Gegenüber der Geschäftsprozessmodellierung sind im Bauwesen zusätzlich Anforderungen zu berücksichtigen, die insbesondere auf die Modellierung von ingenieurspezifischen Fachkenntnissen und Vorschriften, die Koordination der verteilten fachspezifischen Planungen und Ausführungen sowie die Optimierung der Bauprozesse mit komplexen Abhängigkeiten beim Informationsfluss, bei Entscheidungen und bei Synchronisationen zielen. 1.1.4 Zielsetzung Das gemeinsame Ziel der Arbeitsgruppe „Netzwerkgerechte Prozessmodellierung“ (NPM) ist die systematische Analyse und die formale Beschreibung von Planungsprozessen im Konstruktiven Ingenieurbau. Die moderne Informationsund Kommunikationstechnologie schafft die Grundlage dafür, dass diese Planungsprozesse rechnergestützt, vernetzt und kooperativ von den verschiedenen Fachplanungsgruppen und der Projektleitung durchgeführt werden können. Um diese Technologie sinnvoll einsetzen zu können, sind jedoch gegenüber der traditionellen Projektsteuerung die Planungs- und Kommunikationsprozesse für Projekte des Konstruktiven Ingenieurbaus neu zu gestalten. Im Rahmen der Projekte zur Prozessmodellierung werden neue Konzepte, Strukturen und Methoden für eine verteilte, netzwerkgestützte Projektbearbeitung und Kommunikation der kolla-

24

Volker Berkhahn

borierenden Fachplanungsgruppen entwickelt. Die entwickelten SoftwarePrototypen sind in enger Kooperation mit Industriepartnern zu validieren. 1.1.5 Lösungsstrategien Für die Analyse, die formale Beschreibung und die Steuerung von Planungsprozessen bieten sich verschiedene Methoden an. Innerhalb der AG NPM konzentrieren sich die Lösungsansätze auf die Netzplantechnik, die Graphentheorie und die Petri-Netze. Hierbei wird die Netzplantechnik insbesondere für die Berücksichtigung von Ausnahmefällen während der Prozesslaufzeit eingesetzt. Für die Modellierung von komplexen Prozessstrukturen kommen hierarchische Graphensysteme zum Einsatz, wobei die Konsistenz der Relationen zwischen den Elementen verschiedener Hierarchieebenen sicherzustellen ist. Um bei der Modellierung einen besonderen Fokus auf Informationsflüsse zu legen, werden Petri-Netze mit farbigen Markierungen eingesetzt. Die verschiedenen Modellierungsmethoden werden mit den Methoden der aktuellen Informations- und Kommunikationstechnologie verknüpft, um den Ansprüchen in einer verteilten Planungsumgebung gerecht zu werden.

1.2 Arbeiten Innerhalb dieser Arbeitsgruppe waren insgesamt fünf Projekte vertreten. Die drei Projekte aus Hannover, Cottbus/Berlin und Darmstadt waren an einem Bauinformatik-Institut bzw. kooperativ an einem Bauinformatik- und einem GrundbauInstitut angesiedelt. In diesen drei Projekten wurden unterschiedliche Konzepte und Methoden verfolgt, um die Neugestaltung der Planungsprozesse und die Neukonzeption der Kommunikation zwischen den Planungsbeteiligten zu analysieren, zu modellieren und softwaretechnisch zu realisieren. In den beiden Projekten aus Cottbus/Berlin und Darmstadt hatte es sich sehr bewährt, dass die Forschungsarbeit kooperativ jeweils an einem Bauinformatik-Institut und einem anwendungsorientierten Institut des Bauingenieurwesens erfolgte. Zusätzlich zu den genannten drei Projekten war in der ersten Förderphase ein Projekt aus Karlsruhe (Fakultät für Architektur) in dieser Arbeitsgruppe vertreten. Das Projekt aus Aachen (Fakultät für Informatik) war gleichzeitig mit der Arbeitsgruppe „Netzwerkgerechte Prozessmodellierung“ und der Arbeitsgruppe „Verteilte Produktmodelle“ assoziiert. Die fachliche Bandbreite, die in dieser Arbeitsgruppe vertreten war, reichte von der Architektur über das Bauingenieurwesen bis hin zur Informatik. Die einzelnen Projekte werden im Folgenden aus der projektübergreifenden Arbeitsgruppenperspektive zusammengefasst. Hierbei wird jeweils auf die projektspezifischen Zielsetzungen sowie die unterschiedlichen Konzepte und Methoden eingegangen.

Überblick zum Themenbereich Netzwerkgerechte Prozessmodellierung

25

1.2.1 Relationale Prozessmodellierung in kooperativer Gebäudeplanung Die Zielsetzung des Projektes Hannover (Beitrag II.2) umfasste die systematische Analyse und formale Beschreibung des kooperativen Planungsprozesses für die Gebäudeplanung. Das entwickelte Prozessmodell war zunächst für die Anwendung in den ersten drei Phasen der Gebäudeplanung vorgesehen. Durch die Abstraktion dieses Prozessmodells eröffneten sich weitere Anwendungsfelder im Bereich der Planung, des Baus und der Nutzung von Bauwerken des Konstruktiven Ingenieurbaus. Das Konzept für die formale Beschreibung des Planungsprozesses besteht aus einem relationalen Prozessmodell mit drei Teilmodellen: Organisationsstruktur mit Planungsakteuren, Prozessstruktur mit Planungsaktivitäten und Gebäudestruktur mit Planungszuständen. Die äußeren Beziehungen zwischen diesen Teilmodellen werden durch Relationen und Abbildungen unter Berücksichtigung der Konsistenzbedingungen realisiert. Die Methoden zur systematischen Analyse und formalen Beschreibung der kooperativen Gebäudeplanung basieren auf der Mengen-, Relationen- und Graphentheorie. Die Prozessstruktur ist hierbei als gerichteter hierarchischer bipartiter Graph abgebildet und bietet die Möglichkeit, die Methoden der Petri-Netze und der Netzplantechnik auf diese Struktur anzuwenden. Die Gebäudestruktur wird als hierarchischer bipartiter Graph und die Organisationsstruktur durch Zuordnungen abgebildet. 1.2.2 Berücksichtigung von Ausnahmefällen bei der kooperativen Bearbeitung von Projekten des konstruktiven Tiefbaus Im Projekt Cottbus/Berlin (Beitrag II.3) wurden Ausnahmesituationen bei der kooperativen Projektbearbeitung im konstruktiven Tiefbau betrachtet. In der Bauausführung können Situationen auftreten, die nicht im Projektablauf geplant oder berücksichtigt waren und die eine unmittelbare Ad-hoc-Reaktion der beteiligten und räumlich verteilten Fachexperten erfordern. Das entwickelte Konzept beinhaltet ein zentrales Informationssystem zur Unterstützung des regulären Bauablaufs und der Wahl von Sofortmaßnahmen und Sanierungsvorschlägen. Die Daten und Informationen über Ausnahmefälle wurden über Interviews, vorhandene Dokumente, geltende Normen und Vorschriften sowie Fachliteratur erfasst und in geeigneter Weise abstrahiert, um eine Übertragbarkeit auf andere Ausnahmesituationen zu erreichen. Das entwickelte Softwaresystem umfasst als zentrale Komponente einen graphischen Navigator zur schnellen Navigation durch die bereitgestellten Informationen, die Funktionalität zur Terminplanung und Ablaufsteuerung sowie Werkzeuge zur Verwaltung von geotechnischen Daten und Informationen zu Ausnahmesituationen und zum aktuellen Projekt. Dem geotechnischen Informationssystem liegt ein objektorientiertes Informationsmodell zugrunde, welches das Bauvorhaben, seinen Erstellungsprozess sowie die zugehörigen Organisations-

26

Volker Berkhahn

strukturen abbildet. Für die Prozessmodellkomponente wurden u.a. die Methoden der Netzplantechnik eingesetzt. Im Fall von Ausnahmesituationen wurde der ursprüngliche Netzplan durch das Einfügen eines Havarienetzplans dynamisch erweitert. 1.2.3 Prozessorientierte Vernetzung von Ingenieurplanungen am Beispiel der Geotechnik Das Ziel des Projektes aus Darmstadt (Beitrag II.4) war die Entwicklung eines netzwerkbasierten Systems zur Koordination von Fachplanungen im Konstruktiven Ingenieurbau. Hierbei wurde die Petri-Netz-basierte Prozessmodellierung in Verbindung mit einer semantischen Informationsauswertung analysiert. Der Fokus wurde in diesem Projekt beispielhaft auf Planungsprozesse der Geotechnik gesetzt. Das entwickelte Konzept basiert auf der Strukturierung der auszutauschenden Informationen und Dokumente sowie deren Charakterisierung durch Metainformationen. Auf Grundlage der Auswertung der Metainformationen in Verbindung mit der Prozessmodellierung wird die Kommunikation der Planungsbeteiligten gesteuert. Anhand der Anforderungen, die sich aus den Charakteristika geotechnischer Planungsprozesse ergeben, wurden in diesem Projekt verschiedene Modellierungsansätze für Prozessmodelle analysiert. Die verwendeten Methoden zur Modellierung der Planungsprozesse basieren auf Petri-Netzen mit individuellen Marken. Diese individuellen Marken beinhalten zusätzliche Informationen, die zum Schalten der Transitionen im Petri-Netz ausgewertet werden. Es wurden SoftwareWerkzeuge entwickelt, mit denen die in lokalen Domänen agierenden Fachplaner unter Nutzung von netzwerkgerechten Technologien in das globale Prozessmanagementsystem (SOAP, Web-Services, XML) integriert wurden. 1.2.4 Prozessorientiertes Kooperationsmodell für eine anforderungsorientierte dynamische Unterstützung der Integralen Bauplanung Dieses Projekt aus Karlsruhe (Beitrag II.5) wurde über die erste Phase des Schwerpunktprogramms von der Deutschen Forschungsgemeinschaft gefördert und befasste sich mit der Entwicklung eines assistierenden Systems für einen flexiblen koordinierenden Rahmen für verteilt stattfindende kreative Planungsprozesse. Aufbauend auf einer Klassifizierung der Prozesse wurde ein phasenorientiertes Prozessmodell entwickelt und prototypisch in der internetbasierten Kooperationsumgebung ProKoop implementiert.

Überblick zum Themenbereich Netzwerkgerechte Prozessmodellierung

27

1.2.5 Neue Software-Werkzeuge zur Unterstützung des konzeptuellen Gebäudeentwurfs Dieses Projekt aus Aachen (Beitrag III.3) war den Arbeitsgruppen „Netzwerkgerechte Prozessmodellierung“ und „Verteilte Produktmodelle“ inhaltlich zugeordnet. Hierbei stand die Entwicklung von neuen rechnergestützten Methoden für den konzeptionellen Gebäudeentwurf im Mittelpunkt der Forschungsaktivitäten. In diesem Projekt wurden zunächst Datenstrukturen und Methoden zur Strukturierung, Repräsentation und Evaluation von gebäudespezifischem Fachwissen erarbeitet. Diese Forschungsarbeit baut auf den graphbasierten Werkzeugen PROGRES und UPGRADE des Lehrstuhls auf. Die erzielten Ergebnisse wurden als zusätzliche Funktionalität für frühe, konzeptuelle Gebäude-Entwürfe in ein kommerziell verfügbares Computer-Aided-Design-System für das Bauwesen integriert. Hierfür wurde eng mit Partnern aus der Industrie kooperiert.

1.3 Ergebnisse und Erkenntnisse Die Ergebnisse und Erkenntnisse, die innerhalb der einzelnen Projekte zur netzwerkgerechten Prozessmodellierung erarbeitet wurden, sind in zahlreichen Publikationen dokumentiert worden. Die wesentlichen nationalen und internationalen Publikationen sind auf den Internet-Seiten des Schwerpunktprogramms (DFG-SPP 1103 2006) zusammengestellt. Gegenüber diesen Publikationen ist der Workshop „Prozessmodellierung und Workflow-Management im Bauwesen“ (Greb u. Klauer 2004) auf dem „16. Forum Bauinformatik“ in Braunschweig (Zimmermann u. Geller 2004) hervorzuheben. Zur Zielgruppe dieses Workshops gehörten junge wissenschaftliche Mitarbeiter und Studierende der Bauinformatik und der bauinformatikaffinen Fachgebiete. In diesem Workshop wurden zunächst die theoretischen und fachlichen Grundlagen sowie der aktuelle Stand der Forschung im Bereich der Prozessmodellierung vermittelt. Darüber hinaus wurden jedoch auch die Erkenntnisse aus den aktuellen Forschungsergebnissen zur Prozessmodellierung, die innerhalb der Arbeitsgruppe „Netzwerkgerechte Prozessmodellierung“ erzielt wurden, an den wissenschaftlichen Nachwuchs weitergegeben. Mit diesem Workshop haben Greb und Klauer einen bedeutsamen Beitrag zum Wissenstransfer aus dem Schwerpunktprogramm in die wissenschaftliche Breite geleistet. 1.3.1 Methoden und Algorithmen Die Projekte weisen spezifische Forschungsschwerpunkte auf, die arbeitsgruppenintern sorgfältig aufeinander abgestimmt worden sind. Im Vorhaben aus Darmstadt wird hierbei der spezifische Fokus auf die Ausnahmebehandlung für PetriNetz-basierte Workflow-Systeme und auf eine regelbasierte Entscheidungsunterstützung auf Grundlage von unscharfen Petri-Netzen gesetzt. Die spezifische For-

28

Volker Berkhahn

schungsausrichtung im Vorhaben Cottbus/Berlin beinhaltet die Integration von verteilten Fachmodellen und Softwaresystemen sowie die Entwicklung eines Informationsmodells für aktuell generierte Herstellungsdaten. Innerhalb des Vorhabens aus Hannover wird die spezifische Forschungsaktivität auf die Integration des Ressourcen- und Terminmanagements in das Prozessmanagement gerichtet, wobei die Konsistenz über die Hierarchieebenen der jeweiligen Teilmodelle sicherzustellen ist. Die Analyse und Modellierung von vernetzt-kooperativen Planungsprozessen haben im Mittelpunkt der ersten beiden Förderphasen der Projekte der Arbeitsgruppe gestanden. Die Implementierung der entwickelten Konzepte und Methoden konnten in diesem Zeitraum zu großen Teilen abgeschlossen werden, sodass mit Beginn der dritten Förderphase mit der ersten Validierung anhand praxisnaher Szenarien begonnen werden konnte. Die exemplarischen Szenarien stammen aus dem Bereich der Geotechnik, des Spezialtiefbaus und des Hochbaus und decken somit die wesentlichen Bereiche des Konstruktiven Ingenieurbaus ab. Nach einer grundlegenden Analysephase werden innerhalb der Arbeitsgruppe für die Modellierung der bauspezifischen Planungsprozesse Netzplanmethoden, Methoden der einfachen Petri-Netze und Methoden der farbigen Petri-Netze mit individuellen Marken eingesetzt. Die Netzplanmethoden haben sich als besonders vorteilhaft bei der dynamischen Prozessmodellierung für die Einbindung von Havarie-Netzplänen erwiesen. Für einfache Petri-Netze sind Konsistenzbedingungen mathematisch formuliert worden, deren Einhaltung auch bei hierarchischen Strukturen sichergestellt wird. Die individuellen Marken bei farbigen Petri-Netzen beinhalten Metainformationen zum Planungsprozess und werden vorteilhaft für das Schalten von Transitionen genutzt. Im Rahmen der Petri-Netz-basierten Prozessmodellierung sind unter anderem Methoden für die strukturelle Analyse, Erreichbarkeitsanalyse und die Prozesssimulation entwickelt worden. 1.3.2 Realisierung und Implementierung Die Informations-, Kommunikations- und Planungssysteme der Projekte sind mathematisch fundiert und basieren auf der Mengen-, Graphen- und Relationentheorie. Um die Grundlage für eine handhabbare Nutzeroberfläche zu schaffen, sind kooperative Prozessmodelle und die erforderlichen Teilmodelle als hierarchische Strukturen abgebildet worden. Die relevanten Informationen werden dem Nutzer über graphische und schematische Navigatoren vermittelt. Hierbei kann die Menge und Detaillierung der benötigten Informationen vom Nutzer spezifiziert werden. Während der letzten Förderphase haben abschließende Ergänzungen der prototypischen Implementierung und erste Validierungen der Informations-, Kommunikations- und Planungssysteme im Mittelpunkt der Aktivitäten gestanden. Hierfür sind geeignete Konzepte und Methoden für die Nutzeroberflächen spezifiziert und realisiert worden, um die sehr umfangreichen Planungs- und Projektinformationen in geeigneter Weise den Nutzern verfügbar zu machen.

Überblick zum Themenbereich Netzwerkgerechte Prozessmodellierung

29

Diese Oberflächenkonzepte basieren auf hierarchischen Strukturen für die Informations-, Kommunikations- und Planungsmodellierung, die in den ersten beiden Förderphasen entwickelt worden sind. Die Methoden für die graphische und schematische Navigation in hierarchischen Strukturen und deren Visualisierung sind softwaretechnisch realisiert worden. Für einen ersten Schritt der Validierung wurden geeignete, aktuelle Planungsprojekte und Szenarien in praxisnaher Kooperation mit Industriepartnern ausgewählt. 1.3.3 Vernetzt-kooperative Planungsprozesse Innerhalb der verschiedenen Projekte der Arbeitsgruppe wurden netzwerkbasierte Kooperations- und Informationssysteme softwaretechnisch realisiert und praxisnahen Erprobungen in verteilten Planungsszenarien unterzogen. In diesem Zusammenhang konnten prozessrelevante Informationen durch Metainformationen und hierarchische Konzepte strukturiert werden. Hierdurch konnten die Planungsinformationen hinsichtlich der speziellen Relevanz und des erforderlichen Umfangs gezielt durch verteilte Planungsakteure genutzt und bearbeitet werden. Die strategischen Auswirkungen der entwickelten Software-Werkzeuge umfassen insbesondere das Management verteilter Planungsinformationen, die Unterstützung bei unvorsehbaren Planungsereignissen und die Diagnose der strukturellen Konsistenz von Prozessmodellen. 1.3.4 Perspektiven für weitere Forschungsarbeiten Die ersten praxisnahen Erprobungen haben untermauert, dass in der Baupraxis ein Bedarf für verteilte Planungswerkzeuge vorhanden ist. In diesem Zusammenhang konnte die prinzipielle Einsetzbarkeit der Software-Werkzeuge unter Beweis gestellt werden. Es zeigte sich jedoch ein Potential für eine generelle Weiterentwicklung der umgesetzten Modelle und Methoden. Insbesondere Anpassungen der Funktionalität, der Visualisierung und der Nutzeroberfläche an anwendungsspezifische Anforderungen sollten in enger Kooperation mit den jeweiligen Partnern aus der Baupraxis weiterentwickelt werden.

30

Volker Berkhahn

Literatur v. d. Aalst WMP (2000) Workflow Verification: Finding Control-Flow Errors. In: v. d. Aalst WMP, Desel J, Oberweis A (ed) Business Process Management – Models, Techniques, and Empirical Studies, Springer Verlag, Berlin, S 161–183 v. d. Aalst WMP, v Hee K (2002) Workflow Management – Models, Methods and Systems. MIT Press, Cambridge ARIS (2006) IDS Scheer (www.aris.de) BMI.OMG (2006) Business Modeling & Integration Domain Task Force (bmi.omg.org) BPMI (2006) Business Process Management Initiative (www.bpmi.org) DFG-SPP 1103 (2006) DFG-Schwerpunktprogramm 1103 Vernetzt-kooperative Planungsprozesse im Konstruktiven Ingenieurbau (www.dfg-spp1103.de) Greb S, Klauer T (2004) Prozessmodellierung und Workflow-Management im Bauwesen. In: Zimmermann J, Geller S (Hrsg.) Forum Bauinformatik 2004, Shaker Verlag, Aachen, S 143–152 IAI (2006) Industrieallianz für Interoperabilität (www.buildingsmart.de) Janusz B (1998) Modellbasierte Reorganisation von Geschäftsprozessen. FortschrittBerichte, Reihe 16, Nr 97, VDI Verlag, Düsseldorf König M (2004) Ein Prozessmodell für die kooperative Gebäudeplanung. Shaker Verlag, Aachen OMG (2006) Object Management Group (www.omg.org) Scheer AW (1995) Wirtschaftsinformatik: Referenzmodelle für industrielle Geschäftsprozesse. Springer Verlag, Berlin WfMC (2006) Workflow Management Coalition (www.wfmc.org) Zimmermann J, Geller S (Hrsg) (2004) Forum Bauinformatik 2004 – Junge Wissenschaftler forschen. ISBN 3-8322-3233-8, Shaker Verlag, Aachen

2 Relationale Prozessmodellierung in kooperativer Gebäudeplanung

Volker Berkhahn, Axel Klinger, Felix Hofmann Leibniz Universität Hannover, Institut für Bauinformatik {berkhahn | klinger | hofmann}@bauinf.uni-hannover.de

Markus König Bauhaus-Universität Weimar, Juniorprofessur Theoretische Methoden des Projektmanagements [email protected]

2.1 Einleitung Das Forschungsvorhaben befasst sich mit der systematischen Analyse der kooperativen Gebäudeplanung und ihrer formalen Beschreibung in vernetzter Rechnerumgebung. Dabei wird von dem Lösungsansatz ausgegangen, dass sich der Planungsprozess in drei relationale Teilmodelle gliedern lässt: Eine Prozessstruktur mit Planungsaktivitäten, eine Gebäudestruktur mit Planungszuständen und eine Organisationsstruktur mit Planungsakteuren. Von zentraler Bedeutung sind dabei die inneren Verknüpfungen der jeweiligen Teilmodelle und die äußeren Verknüpfungen der drei Teilmodelle. Der Komplexität großer Bauvorhaben wird hierbei durch eine hierarchische Gliederung der Teilstrukturen entgegnet. Im Rahmen dieser relationalen Prozessmodellierung wurden geeignete Methoden für Planungsabstimmungen, Planungskonflikte, Planungsentscheidungen und Planungsfortschreibungen sowie für die Kontrolle und Steuerung des Projektes entwickelt. Bei der Verteilung von Aktivitäten an Akteure bieten grundlegende Methoden der Termin- und Ressourcenplanung eine geeignete Unterstützung. Sie bestimmen maßgebend die Planungssicherheit im kooperativen Planungsprozess. Zur Gewährleistung der Ausführbarkeit der Methoden des Prozessmanagements wurden

32

Volker Berkhahn, Felix Hofmann, Axel Klinger, Markus König

Konsistenzbedingungen für das hierarchische relationale Prozessmodell formuliert, welche die Planer beim dynamischen Aufbau des Prozessmodells unterstützen.

2.2 Ausgangssituation Eine Gebäudeplanung ist gekennzeichnet durch die Zusammenarbeit von vielen verteilt arbeitenden Beteiligten mit unterschiedlichen Zuständigkeiten. Die Zusammenarbeit kann wirkungsvoll durch den Einsatz von modernen Informationsund Kommunikationstechniken in einer verteilten Rechnerumgebung unterstützt werden. Eine rechnergestützte und netzbasierte Zusammenarbeit erfordert eine formale Beschreibung des Planungsprozesses. Häufig auftauchende Probleme bei der Planung sind inkonsistente Daten bei unterschiedlichen Versionen der Planungsdokumente, unzureichende Kommunikation und mangelnde Transparenz. Mit dem Ansatz eines zentralen Prozessmodells, auf das über das Internet mit geeigneten Oberflächen und entsprechenden Rechten und Pflichten zugegriffen werden kann, und kommunikationsunterstützenden Methoden wurde im Rahmen des Projekts diesen Problemen entgegnet. Des Weiteren erfordert die zunehmende Menge der anfallenden Daten bei der Planung eine geeignete Strukturierung der Daten, um schnell auf bestimmte Inhalte zugreifen zu können und sie in überschaubarer Form darstellen und in ihnen navigieren zu können. Dies führte zu dem Ansatz der hierarchischen Gliederung der Daten in Form eines hierarchischen relationalen Prozessmodells.

2.3 Zielsetzung Das Ziel des Forschungsprojekts „Relationale Prozessmodellierung in kooperativer Gebäudeplanung“ war es, die Planungsprozesse der Gebäudeplanung systematisch zu untersuchen und ein mathematisch fundiertes Prozessmodell für die verteilte Planung zu entwickeln. Hierbei waren typische Planungsvorgänge der Fortschreibung und Änderung, sowie die Modellierung von Entscheidungssituationen zu berücksichtigen. Aufbauend auf einem formalen Prozessmodell und unter Berücksichtigung der Planungsvorgänge waren geeignete Methoden des Prozessmanagements mit Methoden für die Termin- und Ressourcenplanung zu definieren. Dieses Modell war in geeigneter Form am Rechner umzusetzen, um in einer prototypischen Anwendung die Anwendbarkeit in der Praxis demonstrieren zu können. Als Basis für die Modellierung der erforderlichen Strukturen diente die Graphentheorie mit erweiterten Ansätzen wie den Theorien der Petri-Netze und der Netzplantechnik. Die zu entwickelnden Strukturen und Methoden sollten es den Planungsbeteiligten ermöglichen, auf sämtliche für sie relevante Planungsdaten jederzeit zuzugreifen und sie je nach Zugriffsrechten zu erweitern.

Relationale Prozessmodellierung in kooperativer Gebäudeplanung

33

2.4 Arbeiten und Ergebnisse Die Arbeiten des Projekts gliedern sich in drei Phasen, in denen das relationale Prozessmodell mit seinen Teilstrukturen und äußeren Verbindungen definiert wurde, um Methoden des Prozessmanagements erweitert wurde und schließlich in Form einer prototypischen Anwendung umgesetzt wurde. In allen drei Phasen wurden die erzielten Ergebnisse anhand realer Bauprojekte auf die Praxistauglichkeit hin untersucht und entsprechend an die Anforderungen der Baupraxis ergänzt. In der ersten Phase des Projekts wurde ein relationales Prozessmodell, bestehend aus einer hierarchischen Prozessstruktur mit Aktivitäten und Übergängen, einer hierarchischen Gebäudestruktur mit Komponenten und Verbindungen sowie einer hierarchischen Organisationsstruktur mit Akteuren und Rollen entwickelt. Zur Unterstützung der Planung wurden Methoden zur Zeit- und Ablaufplanung auf der Basis einfacher Petri-Netze und Netzpläne entwickelt. Zur Gewährleistung der Anwendbarkeit dieser Methoden auf hierarchischen Strukturen wurden überdies strukturelle Konsistenz- und Korrektheitsbedingungen formuliert und Methoden entwickelt, die diese Bedingungen beim dynamischen Aufbau eines Prozessmodells gewährleisten. Aufbauend auf diesem Prozessmodell wurden in der zweiten Phase die äußeren Beziehungen zwischen den Teilmodellen analysiert und Konsistenzbedingungen formuliert, die im Rahmen von Planungsvorgängen zu beachten sind. Die Planungsvorgänge bestehen aus Fortschreibungen, Änderungen und Entscheidungen. Die Fortschreibung umfasst das Hinzufügen und das Verfeinern von Elementen der drei Teilstrukturen. Änderungen werden insbesondere durch die fehlerhafte Ausführung einer Planungsaufgabe, die Änderung von Entwurfsgrößen einer Komponente oder das Entfernen einer Verbindung aus der Gebäudestruktur erforderlich und führen zu Nachträgen und Versionen in den einzelnen Teilstrukturen. Zur Modellierung von Entscheidungen, die Varianten für Komponenten oder Verbindungen und Alternativen für einzelne Planungsaufgaben umfassen, wurde die Gebäudestruktur des relationalen Prozessmodells erweitert. Varianten einer Komponente oder Verbindung können zur weiteren Untersuchung zu einer Gruppe zusammengefasst werden. Für die Planungsaufgaben einer Komponente oder Verbindung können alternative Planungsaufgaben vorgesehen werden. In der dritten Phase wurde das Prozessmodell um Methoden der Ressourcenund Terminplanung mit weiteren Konsistenzbedingungen erweitert. Hierbei bezog sich die Modellierung der Ressourcen und Termine auf die Planungsakteure und die Planungsaktivitäten. Basierend auf den in den ersten Phasen entwickelten und implementierten Strukturen und Methoden wurde eine prototypische Anwendung entwickelt. Auf der Basis dieses Prototyps wurden erste Praxistests in enger Kooperation mit einem Industriepartner erfolgreich durchgeführt. Hierbei wurden kleine Teilaspekte eines abgeschlossenen Planungsprojekts nachträglich modelliert und die Anwendbarkeit des Prototyps getestet.

34

Volker Berkhahn, Felix Hofmann, Axel Klinger, Markus König

2.4.1 Prozessmodell Das Prozessmodell umfasst alle Informationen zu den Komponenten eines Bauwerks, den erforderlichen Aktivitäten und den ausführenden Akteuren. Es gliedert sich in drei Teilstrukturen für die Organisation, das Gebäude und den Prozess. Die drei Teilstrukturen werden durch hierarchische bipartite Graphen beschrieben, die über äußere Beziehungen miteinander verbunden sind (Abb. 2.1.). Prozessmodell Organisationsstruktur

Prozessstruktur

Gebäudestruktur

Abb. 2.1. Aufbau des relationalen Prozessmodells

Zur Gewährleistung der Anwendbarkeit der Methoden des Projektmanagements wurden die Eigenschaften der Konsistenz und der strukturellen Korrektheit definiert. Die Einhaltung dieser Eigenschaften wird zu jedem Zeitpunkt der Bearbeitung durch geeignete Methoden sichergestellt. Prozessstruktur Der Ablauf der Gebäudeplanung wird durch die Prozessstruktur beschrieben. Sie besteht aus den Planungsaktivitäten und den Planungsübergängen sowie deren Anordnungsbeziehungen. Formal wird die Struktur eines Planungsprozesses durch einen hierarchisch gegliederten bipartiten Graphen ohne Zyklen beschrieben (Abb. 2.2.). Eine Aktivität des Planungsprozesses ist eine tätigkeitsbezogene Aufgabe, die sich auf Komponenten oder Verbindungen der Gebäudestruktur bezieht. Jede Aktivität wird so festgelegt, dass sie mit verfügbarer Fachsoftware ohne Interaktion mit anderen Aktivitäten ausführbar ist. In besonderen Fällen kann eine Aktivität im Planungsprozess so festgelegt werden, dass sie von mehreren Fachplanern im Sinne einer Teamarbeit mit eigenständiger Kommunikationsstruktur ausgeführt

Relationale Prozessmodellierung in kooperativer Gebäudeplanung

35

werden kann. Jeder regulären Aktivität wird eine Bearbeitungsdauer zugeordnet, so dass eine Terminplanung möglich ist. Eine Transition des Planungsprozesses ist ein Übergang von vorangehenden Aktivitäten zu nachfolgenden Aktivitäten. Jede Transition, bis auf eine Starttransition und eine Endtransition, besitzt mindestens einen Vorgänger und mindestens einen Nachfolger. Eine Transition kann mit zusätzlichen Attributen, Regeln und Funktionen versehen werden, die der Steuerung des Planungsablaufs dienen.

Abb. 2.2. Hierarchische Prozessstruktur

Der zeitliche Verlauf und die damit verbundene Terminplanung sind von wesentlicher Bedeutung für einen Planungsprozess. Hierfür wurden die bekannten Methoden der Netzplantechnik eingesetzt. Diese Methoden sind in der Literatur für schlichte Graphen formuliert und wurden in generalisierter Form auf bipartite Graphen übertragen. Zur Gewährleistung der Anwendbarkeit dieser Methoden in jedem Stadium des dynamischen Aufbaus wurden Konsistenzbedingungen formuliert, welche die zugrunde liegende Graphenstruktur, den hierarchischen Aufbau und die Bewertung der Struktur unter Beachtung der Hierarchie berücksichtigen, definiert und implementiert. Organisationsstruktur Der kooperative Planungsprozess in einer verteilten Rechnerumgebung erfordert eine Organisationsstruktur für die Planungsakteure (Abb. 2.3.). Diese Organisationsstruktur ist projektbezogen und kann während des Planungsprozesses verändert werden. Die Geschäftsstrukturen, in die die verschiedenen Planungsakteure auf Grund ihrer Beschäftigungsverhältnisse eingebunden sind, werden nicht berücksichtigt.

36

Volker Berkhahn, Felix Hofmann, Axel Klinger, Markus König

Planungsakteure sind am Projekt beteiligte Fachplaner. Eine besondere Rolle unter den Planungsakteuren nimmt der Projektleiter ein, der die gesamte Gebäudeplanung steuert. Jedem Planungsakteur ist ein gewisser Zuständigkeitsbereich und eine gewisse Entscheidungskompetenz zugeordnet. In bestimmten Planungsphasen können Arbeitsgruppen gebildet werden, die definierte Planungsaufgaben gemeinsam lösen.

Abb. 2.3. Hierarchische Organisationsstruktur

Gebäudestruktur Der topologische Aufbau eines Gebäudes wird in der Gebäudestruktur erfasst (Abb. 2.4.). Die Gebäudeplanung gliedert sich in die Raumplanung und die Bauwerksplanung. Dies führt zu einer raum- und bauteilorientierten Strukturierung von Gebäuden. Die Klassifikation von Komponenten und Verbindungen des Gebäudes mit ihren Planungszuständen bilden die Grundlage für die relationale Gebäudestruktur. Mit Hilfe der Gebäudestruktur lassen sich zu jedem Zeitpunkt der Planung die aktuellen Planungsergebnisse aus dem Produktmodell ermitteln. Produktmodelle bildeten den Schwerpunkt der Projekte aus der Arbeitsgruppe „Verteilte Produktmodelle“ und wurden daher im Rahmen dieses Projekts nicht näher betrachtet. Für die Raum- und Bauwerksplanung wurden zwei grundlegende Klassen von Komponenten eingeführt: Raum und Bauteil. Zur Klasse Raum gehören beispielsweise Grundstücke, Gebäude, Abschnitte, Geschosse und Räume. Zur Klasse Bauteil gehören beispielsweise Wände, Träger, Decken, Treppen und Fundamente. Diese beiden Klassen von Komponenten werden in der Gebäudestruktur gleichrangig behandelt. Die Zerlegung eines Gebäudes in seine Komponenten war nicht ausreichend. Planungskonflikte oder Planungsinkompatibilitäten traten häufig an den Verbin-

Relationale Prozessmodellierung in kooperativer Gebäudeplanung

37

dungen von Komponenten auf. Daher wurden Verbindungen als eigenständige Objekte eingeführt. Entsprechend der Klassifikation von Komponenten wurden drei verschiedene Klassen von Verbindungen vorgesehen: Raum-Raum, RaumBauteil und Bauteil-Bauteil. Eine Raum-Raum Verbindung beschreibt beispielsweise die Nachbarschaft von Räumen, eine Raum-Bauteil Verbindung beispielsweise die Berandung eines Raumes durch ein Bauteil und eine Bauteil-Bauteil Verbindung beispielsweise einen konstruktiven Anschluss zwischen Bauteilen.

Abb. 2.4. Hierarchische Gebäudestruktur

Für jede Komponente wird ein Planungsverzeichnis mit einem Bearbeitungszustand geführt. Ein Planungsverzeichnis enthält eine geordnete Menge von Planungsaufgaben und stellt damit einen komponentenorientierten Planungsablauf dar. Jeder Planungsaufgabe wird im Zuge des Planungsprozesses ein Bearbeitungszustand zugeordnet. Ist eine Planungsaufgabe ausgeführt, so enthält der Bearbeitungszustand Verweise auf die entsprechenden Planungsbestände im Produktmodell. Die Planungsverzeichnisse einschließlich der Bearbeitungszustände können für die verschiedenen Klassen von Komponenten systematisch nach einheitlichen Gesichtspunkten spezifiziert werden. Äußere Verknüpfungen Innerhalb des relationalen Prozessmodells bestehen äußere Verknüpfungen zwischen der Organisationsstruktur mit den Planungsakteuren, der Gebäudestruktur mit den Planungszuständen und der Prozessstruktur mit den Planungsaktivitäten (Abb. 2.5.). Für die kooperative Planung ist die konsistente Verknüpfung der drei Teilmodelle von entscheidender Bedeutung. Im Rahmen dieses Vorhabens wurde der Ansatz verfolgt, die ternäre Beziehung in drei binäre Beziehungen zu zerlegen. Die Konsistenz dieser binären Verknüpfungen wird durch Konsistenzbedingungen sichergestellt. Eine Aktivität kann nur dann mit einem bestimmten Akteur oder einer bestimmten Arbeitsgruppe verknüpft werden, wenn dieser Akteur oder diese

38

Volker Berkhahn, Felix Hofmann, Axel Klinger, Markus König

Arbeitsgruppe alle Fach- und Entscheidungsrollen der zugehörigen Planungsaufgaben der Aktivität besitzt. Organisationsstruktur

Prozessstruktur

Gebäudestruktur

Abb. 2.5. Äußere Beziehungen zwischen den Teilstrukturen

2.4.2 Planungsvorgänge Zu Beginn des Planungsprozesses liegen die Organisationsstruktur, die Gebäudestruktur und die Prozessstruktur sowie die äußeren Verknüpfungen nicht vor. Die drei Teilmodelle mit ihren inneren und äußeren Verknüpfungen werden erst im Laufe des Planungsprozesses entsprechend dem Planungsfortschritt aufgebaut und geändert. Diese dynamische Prozessmodellierung führt zu Planungsfortschreibungen, Planungsentscheidungen und Planungsänderungen. Diese drei Planungsvorgänge sind typisch für die kooperative Gebäudeplanung und wurden daher entsprechend modelliert. Auf der Grundlage des vorgestellten relationalen Prozessmodells können Fortschreibungen, Entscheidungen und Änderungen auf verschiedene Art und Weise berücksichtigt werden. Im Rahmen dieses Projekts wurden Planungsfortschreibungen, Planungsentscheidungen und Planungsänderungen mit Hilfe struktureller und inhaltlicher Fortschreibungen, Varianten und Alternativen sowie Versionen und Nachträgen modelliert. Hierzu wurde das relationale Prozessmodell entsprechend erweitert. Es sind jedoch auch andere Erweiterungen möglich, um diese Planungsvorgänge zu berücksichtigen. Fortschreibungen Planungsfortschreibungen sind Planungsvorgänge, mit denen die drei Teilmodelle im Rahmen der Planung erweitert werden, ohne dass dabei beendete Aktivitäten oder gültige Planungsergebnisse der Gebäudestruktur beeinflusst werden. Es wer-

Relationale Prozessmodellierung in kooperativer Gebäudeplanung

39

den strukturelle und inhaltliche Planungsfortschreibungen unterschieden. Eine strukturelle Planungsfortschreibung verändert die Struktur eines der Teilmodelle durch das Hinzufügen von neuen Objekten oder neuen Beziehungen. Eine inhaltliche Planungsfortschreibung verändert die Eigenschaften eines Objektes der Teilmodelle. Für die Organisationsstruktur, die Gebäudestruktur und die Prozessstruktur sind unterschiedliche Vorgehensweisen für Planungsfortschreibungen festgelegt worden. Die strukturelle Fortschreibung der Gebäudestruktur verändert die Struktur des zugehörigen hierarchischen Graphen. Die Änderungen umfassen das Hinzufügen einer neuen Komponente, einer Verbindung oder einer Beziehung sowie die Verfeinerung einer Komponente oder einer Verbindung durch andere Komponenten und Verbindungen. Eine inhaltliche Fortschreibung der Gebäudestruktur umfasst die Aktualisierung und Änderung eines Planungsverzeichnisses. Typische Beispiele hierfür sind die Erweiterung eines Planungsverzeichnisses um eine zusätzliche Planungsaufgabe oder die Aktualisierung eines Planungszustandes. Eine strukturelle Fortschreibung der hierarchischen Prozessstruktur verändert die Struktur des hierarchischen Graphen. Die Änderungen umfassen das Hinzufügen und das Entfernen von Aktivitäten, Transitionen und Beziehungen sowie das Verfeinern von Aktivitäten oder Transitionen. Eine inhaltliche Fortschreibung der Prozessstruktur ändert die Eigenschaft einer Aktivität oder einer Transition ohne Auswirkungen auf beendete Aktivitäten. Zur inhaltlichen Fortschreibung gehört das Ändern der Zeitdauer einer Aktivität, das Ändern des Zeitversatzes einer Transition oder das Setzen einer neuen Markierung einer Aktivität. Eine strukturelle Fortschreibung der Organisationsstruktur umfasst die Aufnahme einer neuen Fach- oder Entscheidungsrolle, eines neuen Planungsakteurs oder die Bildung einer neuen Arbeitsgruppe. Eine strukturelle Fortschreibung der Organisationsstruktur kann auf Grund einer neuen Planungsaufgabe notwendig werden. Die inhaltliche Fortschreibung der Organisationsstruktur umfasst die Aktualisierung von Informationen zu Fach- und Entscheidungsrollen sowie zu Planungsakteuren und Arbeitsgruppen. Hierzu gehören beispielsweise die Änderung des Namens, einer Adresse oder einer anderen Eigenschaft des Objektes. Eine Fortschreibung der äußeren Verknüpfungen umfasst die Erstellung oder Entfernung einer bestimmten äußeren Verknüpfung und wird durch eine Fortschreibung der Organisationsstruktur, Gebäudestruktur oder Prozessstruktur ausgelöst. Eine äußere Verknüpfung kann entfernt werden, wenn durch die Entfernung die Konsistenzbedingungen nicht verletzt werden und keine Auswirkungen auf aktuelle Planungsarbeiten oder gültige Planungszustände zu erwarten sind. Entscheidungen Für die Berücksichtigung von Planungsentscheidungen wurde im Rahmen dieses Projekts der Ansatz gewählt, das relationale Prozessmodell um Varianten und Alternativen zu erweitern. Im Laufe der Gebäudeplanung werden in bestimmten Fällen Variantenuntersuchungen vorgenommen. Eine Variantenuntersuchung wird durchgeführt, wenn verschiedene Varianten für den Aufbau der Gebäudestruktur möglich sind und

40

Volker Berkhahn, Felix Hofmann, Axel Klinger, Markus König

noch keine Variante als Lösung ausgewählt werden kann. Bei einer Variantenuntersuchung werden die verschiedenen Varianten bearbeitet und anschließend eine Variante ausgewählt. Für jede Variante ist eine entsprechende Komponente oder Verbindung in der Gebäudestruktur zu definieren. Somit hat die Berücksichtigung von Varianten strukturelle Änderungen der Gebäudestruktur zur Folge (Abb. 2.6.).

Abb. 2.6. Variantenuntersuchung in der Prozessstruktur

Alternativen werden eingesetzt, wenn innerhalb eines Planungsverzeichnisses verschiedene Planungsaufgaben möglich sind. Beispielsweise können verschiedene Alternativen für die technische Ausstattung eines Raumes oder für den Entwurf eines konstruktiven Anschlusses zwischen einer Decke und einer Stütze definiert werden. Für jede Alternative wird eine eigene Planungsaufgabe im Planungsverzeichnis der zugehörigen Komponente oder Verbindung definiert. Die Erweiterung eines Planungsverzeichnisses um Alternativen ist eine inhaltliche Änderung der Gebäudestruktur (Abb. 2.7.).

Abb. 2.7. Alternativen in der Prozessstruktur

Änderungen Im Laufe der Planung eines Gebäudes lassen sich Änderungen von vorhandenen Planungsaufgaben und Planungszuständen nicht vermeiden. Planungsänderungen sind außerordentlich vielfältig und hängen in hohem Maße von den Ursachen ab. Typische Ursachen für Planungsänderungen sind die fehlerhafte Ausführung einer Planungsaufgabe, die Änderung von Entwurfsgrößen einer Komponente oder die Entfernung einer Verbindung aus der Gebäudestruktur. Für das vorgestellte relati-

Relationale Prozessmodellierung in kooperativer Gebäudeplanung

41

onale Prozessmodells wurde ein Ansatz auf der Grundlage von Versionen und Nachträgen entwickelt. Planungsänderungen führen zu Versionen in der Gebäudestruktur, zu Nachträgen in den Planungsverzeichnissen oder zur Entfernung von Komponenten und Verbindungen. Die verschiedenen Planungsänderungen haben unterschiedliche Auswirkungen auf die aktuellen Planungsarbeiten und Planungsergebnisse. Eine Version bezieht sich auf eine Komponente oder Verbindung und ist eine strukturelle Änderung der Gebäudestruktur. Eine neue Version einer Komponente wird beispielsweise spezifiziert, wenn sich Beziehungen zu Verbindungen ändern oder grundlegende Änderungen von Planungsaufgaben oder Planungsergebnissen der Komponente vorgenommen werden (Abb. 2.8.).

Abb. 2.8. Versionen einer Komponente

Ein Nachtrag ist eine Ergänzung einer bereits abgeschlossenen Planungsaufgabe einer Komponente oder Verbindung der Gebäudestruktur. Im Nachtrag werden neue Arbeiten beschrieben, die vorhandene Planungsergebnisse ergänzen oder ersetzen. Die Planungsergebnisse der abgeschlossenen Planungsaufgabe werden dabei nicht verändert. Für jeden Nachtrag wird eine neue Planungsaufgabe im Planungsverzeichnis erstellt (Abb. 2.9.).

Abb. 2.9. Einfügen eines Nachtrags in die Prozessstruktur

Das Einfügen eines Nachtrages kann dazu führen, dass auch weitere Aktivitäten noch einmal überarbeitet oder ergänzt werden müssen. Die Auswirkungen des Nachtrages lassen sich in diesem Fall durch eine vorwärts gerichtete Breitensuche von der betroffenen Aktivität aus bis hin zum aktuellen Planungszustand, der

42

Volker Berkhahn, Felix Hofmann, Axel Klinger, Markus König

durch die Markierung des Graphen im Sinne der Petri-Netze beschrieben wird, ermitteln. Beim Erstellen eines Nachtrages wird eine Beziehung über einen Übergang von der Aktivität, im Rahmen derer ein Fehler entdeckt bzw. eine Änderung gewünscht wurde, zum eigentlichen Nachtrag eingetragen, um die strukturelle Konsistenz des Planungsablaufs zu wahren. Konsistenz und Korrektheit Die Anwendung der Methoden der Petri-Netze und der Netzplantechnik erfordert strukturelle Eigenschaften des Prozessmodells, die als Konsistenz- und Korrektheitsbedingungen bei der Definition des relationalen Prozessmodells formuliert wurden. Diese Bedingungen sind im Rahmen aller Planungsvorgänge einzuhalten. So erfordern die Methoden der Netzplantechnik, dass der zugrunde liegende Graph der Prozessstruktur azyklisch und schwach zusammenhängend ist, um eine Terminierung des Ablaufs zu gewährleisten. Die Methoden der Petri-Netze erfordern, dass die Prozessstruktur keine Konflikte wie Deadlocks oder fehlende Synchronisationen enthalten, welche durch eine Kombination von vorwärts und rückwärts gerichteten Verzweigungen auftreten können. Diese Bedingungen sind bereits in der einschlägigen Literatur zu Petri-Netzen und Netzplänen dokumentiert und wurden im Rahmen des Projekts auf die hierarchische Prozessstruktur erweitert. Neben den strukturellen Konsistenzbedingungen wurden des Weiteren inhaltliche Konsistenzbedingungen formuliert, welche die Bewertung der hierarchischen Prozessstruktur betreffen. 2.4.3 Ressourcen und Terminplanung Die Ressourcen- und Terminplanung baut auf der Zeitplanung auf, die bereits mit der Einführung der Netzpläne für die hierarchische Prozessstruktur zu Beginn des Projekts vorgesehen wurde. Als Ressourcen werden Akteure betrachtet, die Aktivitäten der Prozessstruktur ausführen und dafür eine bestimmte Zeitdauer benötigen. Um zeitliche Konflikte bei der Zuordnung von Akteuren zu Aktivitäten zu vermeiden, wurden die Konsistenzbedingungen für die äußeren Verknüpfungen zwischen den drei Teilmodellen erweitert und in das Prozessmanagement in Form von Methoden zur Ressourcen- und Terminplanung integriert. Die Konsistenzbedingungen stellen neben der fachlichen Qualifikation der Akteure für bestimmte Aufgaben auch die zeitliche Verfügbarkeit sicher, so dass ein Akteur nicht für mehrere Aufgaben gleichzeitig eingeteilt werden kann. Zeitplanung Beim Aufbau eines Modells für die Planung werden zunächst auf Erfahrung beruhende geschätzte Zeitdauern für die Aktivitäten angesetzt und Meilensteine definiert. Im Zuge der Planung werden die Aktivitäten und die damit verbundenen Aufgaben Akteuren zur Bearbeitung zugewiesen. Die Meilensteine bilden gemäß

Relationale Prozessmodellierung in kooperativer Gebäudeplanung

43

den Konsistenzbedingungen für die hierarchische zeitliche Bewertung obere Schranken für die Planung der verfeinerten Aktivitäten. Ressourcenplanung Jeder Akteur verfügt über einen eigenen Terminplan, in den sich auch externe Termine des Akteurs integrieren lassen. Externe Termine eines Akteurs sind für die an der Planung des Bauprojekts beteiligten Personen nicht einzusehen und werden anonym nur als verplante Zeiten angezeigt. Werden einem Akteur vom Planer Aufgaben zugewiesen, so müssen diese zur endgültigen Zuordnung vom Akteur bestätigt werden. Auf diese Weise kann der Planer bei der Zuweisung von Aufgaben zu Akteuren unterstützt werden, indem ihm zu einer ausgewählten Aktivität alle gemäß den Konsistenzbedingungen möglichen Akteure angezeigt werden. Hierbei werden sowohl die vorhandenen Termine des Akteurs als auch seine Fach- und Entscheidungsrollen berücksichtigt (Abb. 2.10.).

Aktivität 1

Akteur 1

Aktivität 2

Akteur 2

Aktivität 3

Akteur 3

Aktivität 4

Aktivität

ausgewählte Aktivität

möglicher Akteur

Akteur

Abb. 2.10. Unterstützung bei der Zuordnung der Aktivitäten zu Akteuren

Verzichtet der Planer auf die Beschränkung der Zuordnung durch die Konsistenzbedingungen, um die Planung flexibler gestalten zu können, so lassen sich auch mögliche Konflikte bei der Zuordnung parallel auszuführender oder sich überschneidender Aktivitäten zu einem Akteur anzeigen und manuell beheben. Hierbei kann der Planer vorhandene Zuordnungen wieder aufheben, oder die zeitliche Anordnung der Aktivitäten verändern (Abb. 2.11.).

44

Volker Berkhahn, Felix Hofmann, Axel Klinger, Markus König

Abb. 2.11. Konsistente Zuordnung der Aktivitäten zu Akteuren

Terminplanung Auf der Basis der Zeitplanung und der Ressourcenplanung erfolgt die Terminplanung. Bei der Terminplanung werden den Aktivitäten Datumswerte zugeordnet, die mit den angesetzten Zeiten und Meilensteinen der Zeitplanung konsistent sein müssen. Der Terminplan für ein Bauprojekt ist eine weitere Bewertung der hierarchischen Prozessstruktur. Ebenso wie der Terminplan des Gesamtprojekts können auch die Terminpläne der einzelnen Akteure hierarchisch gegliedert sein. Betrachtet man die Terminpläne eines Akteurs auf einer gröberen Ebene, so kann ein Akteur auch an mehreren Aufgaben gleichzeitig arbeiten. Auf der feinsten Ebene der Hierarchie müssen diese Aufgaben jedoch überschneidungsfrei angeordnet sein. Die Terminplanung ist konsistent, wenn alle Aufgaben Aktivitäten zugeordnet sind, was bei standardisierten Aufgaben bereits teilautomatisch geschehen kann, alle Aktivitäten Akteuren zugeordnet sind, die hierarchische Konsistenz der zeitlichen Bewertung eingehalten wird und kein Akteur zeitliche Überschneidungen in seinem Terminplan hat, die sich nicht spätestens auf der feinsten Ebene seines Zeitplans auflösen. 2.4.4 Planungswerkzeug Für die hierarchische Gebäudestruktur mit ihren Komponenten und Verbindungen und die hierarchische Prozessstruktur mit ihren Aktivitäten und Transitionen sind geeignete objektorientierte Klassen auf der Grundlage der definierten mathematischen Formulierungen implementiert worden. Zur dynamischen und konsistenten Erstellung der hierarchischen Strukturen ist ein Editor in einer ersten Pilotversion entwickelt worden, der es den Planern ermöglicht, ein Modell eines Planungsprozesses vollständig am Rechner aufzubauen (Abb. 2.12.). Für die Gebäudestruktur mit ihren Komponenten und Verbindungen wurde die Anbindung einer relationa-

Relationale Prozessmodellierung in kooperativer Gebäudeplanung

45

len Datenbank mit Produktdaten auf der Basis der „Industry Foundation Classes (IFC)“ in der Version 2x exemplarisch erstellt und getestet. Zur Steuerung der Planung wurden für die Prozessstruktur Methoden der Netzplantechnik in den Editor integriert, sodass die Ermittlung der kritischen Wege und eine Terminplanung für jede Ebene einer hierarchischen Prozessstruktur möglich sind. Eine einfache ereignisgesteuerte Kommunikation mit Hilfe der Methoden für Petri-Netze wurde auf der Basis von elektronischer Post entwickelt. Die Klassen für die hierarchischen Strukturen und den Editor sind in JAVA implementiert und bieten damit einen plattformunabhängigen Einsatz in einer verteilten Rechnerumgebung.

Abb. 2.12. Datenerfassung im Prozessmodell Editor

Die grafische Repräsentation der zugrunde liegenden Strukturen des Modells erfolgt über eine Oberfläche auf der Basis eines Graphen-Editors und bietet die Möglichkeit der Navigation im hierarchischen Modell. Sie unterstützt den Anwender bereits bei der Eingabe des Modells durch die Möglichkeit, Inkonsistenzen und strukturelle Fehler im Modell zu erkennen und entsprechend darauf zu reagieren, sofern es nicht von vorne herein möglich ist, Inkonsistenzen und Fehler zu vermeiden (Abb. 2.13.).

46

Volker Berkhahn, Felix Hofmann, Axel Klinger, Markus König

Abb. 2.13. Visualisierung der strukturellen Zusammenhänge

Im derzeitigen Entwicklungsstand bildet der Prozessmodelleditor bereits den größten Teil der Funktionalität des hierarchischen relationalen Prozessmodells ab. Für den praktischen Einsatz sind jedoch sowohl die Benutzerschnittstellen, als auch die Datenaustauschformate den Gegebenheiten der Baupraxis anzupassen. Je nach Anwendung lassen sich anwendungsbezogene Elementvorlagen für standardisierte Elemente wie Bauteile, Planungsaufgaben, Planungszustände, Rollen und Arbeitsschritte definieren und zu Bibliotheken zusammenfassen, um sie so in weiteren Projekten wieder verwenden zu können. Für die kooperative Gebäudeplanung auf der Grundlage des relationalen Prozessmodells wurde ein Konzept für eine geeignete Arbeitsumgebung entwickelt. Das Konzept für eine solche netzgestützte Arbeitsumgebung besteht aus einer Drei-Schichten-Architektur mit einer Fachanwendungsschicht, einer Modellschicht und einer Datenbankschicht (Abb. 2.14.). Die Fachanwendungsschicht umfasst alle Fachanwendungen wie CAD-Systeme, Berechnungssysteme oder auch den Prozessmodell Editor. Die einzelnen Fachanwendungen greifen über das Netzwerk auf die Objekte, Strukturen und Methoden der Modellschicht zu. In der Modellschicht werden die Objekte, Strukturen und Methoden des Prozessmodells und des Produktmodells zentral für die einzelnen Fachanwendungen vorgehalten. Die permanente Speicherung der Daten des relationalen Prozessmodells erfolgt in der Datenbankschicht. Im Rahmen des Projekts wurde für die Speicherung eine relationale Datenbank verwendet.

Relationale Prozessmodellierung in kooperativer Gebäudeplanung

47

Prozessmodell-

Prozessmodell

Prozessstruktur

Prozessmodell-

Abb. 2.14. Drei-Schichten-Architektur für eine netzgestützte Arbeitsumgebung für die Gebäudeplanung

2.5 Ergebnisse Das Ziel dieses Projekts war die Entwicklung eines Prozessmodells für die rechnergestützte kooperative Gebäudeplanung. Die kooperative Gebäudeplanung ist gekennzeichnet durch viele Projektbeteiligte, eine schrittweise Detaillierung sowie häufige Änderungen der Aufgaben und Unterlagen während des Planungsfortschritts. Dies bedingt vielfältige Entscheidungsvorgänge im Laufe der Gebäudeplanung. Diese Eigenschaften wurden bei der Spezifikation des relationalen Prozessmodells besonders berücksichtigt. Durch die formale und unabhängige Beschreibung der Prozessstruktur mit Hilfe eines bipartiten Graphen können sowohl Methoden der Netzplantechnik als auch Methoden der Petri-Netze auf der identischen Struktur zweckmäßig eingesetzt werden. Zur Berücksichtigung der Hierarchie wurden eigene Konsistenzbedingungen formuliert. Somit stellt diese Arbeit ein Konzept für Terminplanung und ereignisgesteuerte Kommunikation zur Unterstützung der Gebäudeplanung bereit. Es hat sich gezeigt, dass die formale Beschreibung des relationalen Prozessmodells für die Implementierung des Konzepts zweckmäßig ist. Die spezifizierten Strukturen und Konsistenzbedingungen konnten ohne aufwendige Anpassungen für die Programmierung übernommen werden. Mit dem vorgestellten relationalen Prozessmodell ist es gelungen, eine umfangreiche und abstrakte Basis für die Umsetzung einer rechnergestützten Arbeitsumgebung zu erstellen.

48

Volker Berkhahn, Felix Hofmann, Axel Klinger, Markus König

2.5.1 Anwendungsbeispiel In der dritten Phase des Projekts wurden die entwickelten Strukturen und Methoden in Kooperation mit der Sellhorn Ingenieurgesellschaft mbH (Hamburg) in Form der prototypischen Anwendungen anhand eines Beispiels aus der Baupraxis auf ihre Anwendbarkeit überprüft (Abb. 2.15). Dabei hat sich gezeigt, dass das Interesse an der digitalen Erfassung, zentralen Speicherung und verteilten Zugänglichkeit aller relevanten Daten durchaus vorhanden ist.

Abb. 2.15. Bauprojekt in Hamburg-Waltershof (Quelle: Sellhorn Ing.-Gesellschaft)

2.5.2 Transferprojekt Im Rahmen des Transferprojektes wird die Anwendung für die verteilte Planung von Bauprojekten in enger Zusammenarbeit mit einem Projektpartner aus der Baupraxis erprobt und an die speziellen Anforderungen des Praxispartners hinsichtlich der Benutzeroberflächen und Datenaustauschmöglichkeiten angepasst. Hierbei wird das Ziel verfolgt, die Anwendung so generisch wie möglich zu halten, um zukünftig die einfache Anpassung an neue Aufgabenfelder ohne Änderung der Programmquellen zu ermöglichen. Zusammen mit dem Praxispartner wird während des Transferprojektes ein Bauprojekt ausgewählt, das für die projektbegleitende Live-Modellierung eines Planungsprozesses geeignet ist. Gegenüber den bisherigen Praxistests zur NachModellierung des Planungsprozesses zeichnet sich dieser Live-Praxistest dadurch aus, dass zu Beginn des Bauprojektes nur Planungsinformationen mit einem geringen Detaillierungsgrad zur Verfügung stehen. Mit dem Fortschritt des Bauprojektes nimmt dann der Detaillierungsgrad der Informationen zu. Diese Problemstellung wird mit hierarchischen Konzepten zu lösen sein und stellt eine besondere

Relationale Prozessmodellierung in kooperativer Gebäudeplanung

49

Herausforderung an den Funktionalitätsumfang und die Benutzeroberfläche des Planungswerkzeugs dar.

2.6 Erkenntnisse In den vergangenen Jahren hat die Entwicklung von Werkzeugen zum kooperativen Projektmanagement an Bedeutung gewonnen, da mit zunehmender Größe und Komplexität von geplanten Projekten – wie im Bauwesen bei Hochbauprojekten – ein rechnergestütztes Informationsmanagement unumgänglich geworden ist. Die Planungsakteure, Arbeitsschritte und Objektkomponenten sind unter den Gesichtspunkten Kosten, Zeit und Ressourcen in optimaler Form zuzuordnen. Alle Informationen, die den Planungsprozess betreffen, müssen in übersichtlicher und leicht zugänglicher Weise dem Planer zur Verfügung stehen. Weitreichende Folgen bei Änderungen können durch geeignete Methoden sofort erkannt und den Planungsingenieuren angezeigt werden. Der Ansatz des relationalen Prozessmodells kann hierbei einen wertvollen Beitrag zur Unterstützung der Planung leisten, wobei im Rahmen eines Praxistransfers noch einige Anpassungen der Benutzerund Datenschnittstellen für eine vereinfachte Anwendung und höhere Flexibilität erforderlich sind.

2.7 Einordnung in den Gesamtzusammenhang des SPP Im Forschungsvorhaben ist die kooperative Gebäudeplanung mit rechnergestützter Projektbearbeitung und netzbasierter Kommunikation systematisch untersucht worden. Diese Untersuchung hat zu einem relationalen Prozessmodell mit Teilmodellen für die Organisationsstruktur, die Gebäudestruktur und die Prozessstruktur geführt. Die Gebäude- und Prozessstruktur sind hierarchisch gegliedert, sodass die Komplexität des dynamischen Planungsprozesses beherrschbar wird. Sie bilden die Grundlage zur Modellierung von Planungsfortschreibungen entsprechend dem Planungsfortschritt, von Planungsentscheidungen mit Varianten und Alternativen und von Planungsänderungen mit Nachträgen und Versionen. Damit wird eine gewisse Planungssicherheit gewährleistet und die Nachvollziehbarkeit von Planungsentscheidungen erreicht. Die Organisationsstruktur erlaubt die Realisierung verschiedenartiger Kooperationsmodelle für die Projektbearbeitung. Sie basiert auf den Hole-, Bringe- und Meldepflichten der Planungsakteure, so dass eine zweckmäßige Kooperation unter Einsatz eines gemeinsamen Produktmodells organisiert werden kann. Der Zugriff der an der Planung beteiligten Planungsakteure auf die gemeinsamen Produktdaten erfolgt über die entsprechenden Verweise in der Gebäudestruktur. Dadurch kann eine Einbindung der vorhandenen Fachmodelle und Fachsoftware erreicht werden. Das relationale Prozessmodell mit seinen drei Teilmodellen ist mathematisch auf der Grundlage der Mengen-, Relationenund Graphentheorie formuliert und wurde in systematischer Form implementiert.

50

Volker Berkhahn, Felix Hofmann, Axel Klinger, Markus König

Damit wurden im Forschungsvorhaben „Relationale Prozessmodellierung in kooperativer Gebäudeplanung“ zentrale Themenbereiche des Schwerpunktprogramms behandelt und grundlegende Strukturen für kooperative Planungsprozesse im Konstruktiven Ingenieurbau entwickelt.

Nachwort Dieses Forschungsvorhaben wurde von Prof. Dr.-Ing. Rudolf Damrath, dem ehemaligen Leiter des Instituts für Bauinformatik der Universität Hannover, initiiert, beantragt und bis zur Mitte der zweiten Förderphase geleitet. Herr Prof. Damrath hat hierbei entscheidende Impulse für dieses Forschungsvorhaben und den gesamten Schwerpunkt gesetzt. Sein unerwarteter und plötzlicher Tod im Herbst 2003 hat alle zutiefst erschüttert. Die Autoren sind sich sicher, dass sie dieses Forschungsvorhaben im Sinne der methodischen und inhaltlichen Intention von Prof. Damrath erfolgreich weitergeführt haben.

Literatur Berkhahn V (2004) Network based process modelling. In: Deutsch-Russisches Bauinformatik Symposium, Moskau/St.Petersburg Berkhahn V, Klinger A (2004) Relationale Prozessmodellierung in kooperativer Gebäudeplanung. Bericht über den 2. Förderzeitraum des Forschungsvorhabens. Hannover Berkhahn V, Klinger A, Rüppel U, Meißner UF, Greb S, Wagenknecht A (2005) Processes Modeling in Civil Engineering based on Hierarchical Petri Nets. In: Proceedings of the 22nd International Conference on Information Technology for Construction (CIBW78), Dresden von Both P (2002) An Internet-based co-operation environment for a dynamic and objective oriented planning. In Proceedings of the 9th International Conference on Computing in Civil and Building Engineering, Taipei Damrath R, König M (2002a) Relational Modelling of Planning Processes in Building Engineering. In: Proceedings of the 9th International Conference on Computing in Civil and Building Engineering (ICCCBE), Taipei Damrath R, König M (2002b) Relationale Prozessmodellierung in kooperativer Gebäudeplanung. Bericht über den 1. Förderzeitraum des Forschungsvorhabens. Hannover Firmenich B (2002) CAD im Bauplanungsprozess. Verteilte Bearbeitung von einer strukturierten Menge von Objektversionen. Shaker Verlag, Aachen Hanff J (2002) Computer aided co-operative Engineering. In: Proceedings of the 9th International Conference on Computing in Civil and Building Engineering, Taipei Hüttermann R (2000) Wegalgebra für hierarchische Graphensysteme. Fortschrittsberichte, VDI-Verlag, Düsseldorf IAI (2000) Industry Foundation Classes Release 2.x – IFC Technical Guide; International Alliance for Interoperability (http://www.iai.org.uk/) Katzenbach R, Meißner UF, Rüppel U, Giere J, Greb S (2002) Process-oriented networkbased collaboration in geotechnical engineering. In: Proceedings of the 9th International Conference on Computing in Civil and Building Engineering, Taipei

Relationale Prozessmodellierung in kooperativer Gebäudeplanung

51

Klinger A (2003) Strukturanalyse von Workflow-Graphen. In: Tagungsband des 15. Forum Bauinformatik in Hannover, Shaker Verlag, Aachen Klinger A, König M, Berkhahn V (2005) A graph based tool for modelling planning processes in building engineering. In: Proceedings of the International Conference on Computing in Civil Engineering (ICCC), Cancun Klinger A, Berkhahn V, König M (2006) Formal treatment of additions in planning processes. In: Proceedings of the Joint International Conference on Computing and Decision Making in Civil and Building Engineering, Montreal König M (2004) Ein Prozessmodell für die kooperative Gebäudeplanung. Dissertation, Institut für Bauinformatik, Universität Hannover, Hannover König M, Klinger A (2002) Modellierung von Planungsprozessen mit Hilfe von Hierarchischen Strukturen. In: 14. Forum Bauinformatik in Bochum, Fortschrittsberichte, Reihe 4, Nr 181, VDI-Verlag, Düsseldorf König M, Klinger A, Berkhahn V (2004a) Structural Correctness of Planning Processes in Building Engineering. In: Proceedings of the 10th International Conference on Computing in Civil and Building Engineering (ICCCBE), Weimar König M, Klinger A, Berkhahn V (2004b) Process Modelling in Building Engineering. In: Proceedings of the European Conference on Product and Process Modelling in Building and Construction Industry (ECPPM), Istanbul Kraft B, Nagl M (2003) Semantic Tool Support for Conceptual Design. In: Proceedings of the 4th International Symposium on Information Technology in Civil Engineering, ASCE (CD-ROM), Nashville, pp 1–12 Kraft B, Meyer O, Nagl M (2002) Graph Technology Support For Conceptual Design In Civil Engineering (invited talk). In: Schnellenbach-Held M, Denk H (eds) Proceedings of the 9th International Workshop of the European Group for Intelligent Computing in Engineering (EG- ICE2002) (180), pp 1–35, VDI Verlag, Darmstadt Olbrich M (1998) Relationenorientiertes Modellieren mit Objekten in der Bauinformatik,. Fortschrittsberichte, VDI-Verlag, Düsseldorf Pahl PJ, Damrath R (2001) Mathematical Foundations of Computational Engineering. Springer-Verlag, Berlin

3 Berücksichtigung von Ausnahmefällen bei der kooperativen Bearbeitung von Projekten des konstruktiven Tiefbaus

Klaus-Peter Holz, Frank Schley Brandenburgische Technische Universität Cottbus, Lehrstuhl Bauinformatik {holz | schley}@bauinf.tu-cottbus.de

Stavros Savidis, Frank Rackwitz, Marcus Mejstrik Technische Universität Berlin, Fachgebiet Grundbau und Bodenmechanik {savidis | frank.rackwitz | marcus.mejstrik}@grundbau.tu-berlin.de

3.1 Vorbemerkungen Die Entwicklungen im konstruktiven Tiefbau werden zunehmend durch neue und innovative Herstellungstechnologien sowie durch die Weiterentwicklung vorhandener Bauverfahren geprägt. Parallel hierzu erfolgte eine starke Spezialisierung gerade der kleineren und mittelständischen Unternehmen auf ausgewählte Herstellungsverfahren. Dies führte dazu, dass seit einigen Jahren die Bezeichnung Spezialtiefbau als Synonym für den konstruktiven Tiefbau gebräuchlich ist und auch im Folgenden verwendet wird. Ingenieurmaßnahmen des Spezialtiefbaus, wie die Herstellung von Tunnelbauten in offener Bauweise als Trogbaugruben, erfordern umfangreiche Kooperationen von räumlich verteilt arbeitenden Experten aus verschiedenen Fachgebieten. Diese dezentrale Kooperation lässt sich heute mit internetbasierten Methoden der Informations- und Kommunikationstechnologie unterstützen. Bei komplexen Bauvorhaben können sich die Planungsgrundlagen während der Ausführungsphase erheblich ändern. Im Spezialtiefbau tritt zusätzlich das Problem möglicher Ausnahmesituationen bis hin zu Havariefällen auf, die unabhängig

54

Klaus-Peter Holz, Stavros Savidis, Frank Schley, Frank Rackwitz, Marcus Mejstrik

von geplanten Prozessabläufen entstehen können, wie zum Beispiel Leckagen und Grundwassereinbrüche in Baugruben (Abb. 3.1) oder unvorhergesehene und ungünstige Änderungen der Baugrundverhältnisse.

Abb. 3.1. Leckagen und Grundwassereinbrüche als Havariefälle im Spezialtiefbau

Diese Ausnahmesituationen erfordern bei der kooperativen Projektbearbeitung u. U. sofortige Eingriffe zur Schadensabwehr, rapide Änderungen des Bauablaufes und/oder maßgebliche Änderungen der Planungsunterlagen. Eingriffe und Änderungen sind zwischen den Beteiligten in der Projektbearbeitergruppe zu entscheiden, zu koordinieren und durchzuführen. Erforderlich ist daher eine Informations- und Kooperationsplattform für den Spezialtiefbau, deren Anforderungen und Randbedingungen unter normalen Baustellenverhältnissen sowie für Ausnahmesituationen zu ermitteln sind. Die zu entwickelnden Methoden sollen eine schnelle Behandlung von Ausnahmefällen bei der Durchführung von Spezialtiefbauprojekten in einem dezentral arbeitenden Team von Experten auf der Basis von Internet-Technologien erlauben. Ausgangspunkt ist die Analyse durchgeführter und aktueller Spezialtiefbauprojekte zur Herstellung Tiefer Baugruben, um die Anforderungen und Randbedingungen für ein flexibles Kooperationsmodell festlegen zu können. Darauf aufbauend werden die Projektziele konkretisiert und ein Konzept für die Aufbereitung und das Management der im Spezialtiefbau anfallenden, ausführungsrelevanten Informationen entwickelt. Der durch dieses Konzept und die gewählte Methodik geleistete Beitrag des Projektes zu den Zielen der Arbeitsgruppe Netzwerkgerechte Prozessmodellierung sowie zu den Gesamtzielen des SPP 1103 wird dargestellt. Die Umsetzung des Konzeptes in einem Informationsmanagementsystem, welches für den Spezialtiefbau im Hinblick auf die wesentlichen Informationen (Schlüsselinformationen) ausgelegt wurde, wird vorgestellt. Die Implementierung des Prototypen erfolgte in Java. Es werden Ergebnisse und Erfahrungen aus einem Praxistest des entwickelten Informationsmanagementsystems für den Spezialtiefbau präsentiert.

Berücksichtigung von Ausnahmefällen bei Projekten des konstruktiven Tiefbaus

55

3.2 Einleitung und Zielsetzung 3.2.1 Prozessabläufe im Spezialtiefbau Organisationsstrukturen auf Baustellen des Spezialtiefbaus Firmen des Spezialtiefbaus sind überwiegend stark spezialisiert, Personal und Gerätetechnik sowie die eingesetzten Baumaterialien repräsentieren das spezifische Know-how eines Unternehmens. Derartige Spezialtiefbauunternehmen führen daher meist sehr wenige ineinandergreifende Gewerke aus. Daraus folgt eine große Anzahl beteiligter Unternehmen auf der Baustelle mit jeweils einem Fachbauleiter und einem Polier pro Gewerk. Abbildung 3.2 zeigt als Organigramm beispielhaft mit drei an einem Projekt beteiligten Firmen die Organisation, wie sie auf Baustellen des Spezialtiefbaus vorwiegend anzutreffen ist. Die Kommunikationswege zwischen den Beteiligten sind durch Pfeile dargestellt. Die Weisungsbefugnis verläuft hierarchisch von oben nach unten. Projektleiter und weitere Beteiligte stehen hierarchisch auf einer Ebene. Im Organigramm nicht dargestellt sind häufig anzutreffende weitere Organisationsebenen, die sich aus der vertraglichen Gestaltung sowohl auf der Auftragnehmerseite (Generalübernehmer, Arbeitsgemeinschaft etc.) als auch auf der Auftraggeberseite (Projektsteuerer, Bauüberwachung etc.) ergeben können. Bauleiter

Fachbauleiter 1

Fachbauleiter 2

Projektleiter

Fachbauleiter 3 Oberpolier

Polier 1

Firma 1

Polier 2

Firma 2

Polier 3

Weitere Beteiligte: Gutachter, Statiker, Behörden, …

Firma 3

Abb. 3.2. Organisation und Kommunikationswege auf Tiefbaustellen (exemplarisch)

Besondere Bedeutung hat das Verhältnis Oberpolier/Bauleiter. Die Gesamtkoordination übernimmt der Bauleiter, während dem Oberpolier die Ausführungskoordination obliegt. Bauleiter und Oberpolier halten häufig notwendige Rücksprachen und stimmen sich eng miteinander ab. Entscheidungsprozesse in Ausnahmesituationen erfordern hingegen die Einbeziehung zahlreicher Projektbeteiligter aufgrund ihrer jeweiligen Verantwortlichkeit und Kompetenz, um richtig und umfassend zu entscheiden und um die Verantwortung breit zu verteilen.

56

Klaus-Peter Holz, Stavros Savidis, Frank Schley, Frank Rackwitz, Marcus Mejstrik

Informationsverarbeitung Der Informationsbedarf im Spezialtiefbau zieht sich durch alle Phasen der Planung und Ausführung. Die dabei anfallenden Informationen sind sehr heterogen (Skizzen, Pläne, Gutachten, statische Berechnungen, Verträge, Herstellungsprotokolle, Messdaten, Abrechnungen, Nachtragsforderungen etc.). Ihre Verarbeitung erfolgt in kleinen und mittleren Bauunternehmen mit einer Ansammlung von spezialisierten Softwareapplikationen und „Standardsoftware“ inkl. Officeanwendungen. Eine integrierende Unterstützung durch Informations- und KommunikationsSysteme ist noch nicht so weit verbreitet wie in anderen Ingenieursdisziplinen (Jung et al. 2004). Lediglich die Anwendung elektronischen Dokumentenmanagements erfährt einen spürbaren Schub, besonders bei größeren Bauvorhaben (Björk 2003). Ein signifikanter qualitativer Nutzen kann durch den konsequenten Einsatz eines zentralen integrierenden digitalen Informationsmanagements in Multipartnerprojekten erreicht werden (Sulankivi 2004). Ausnahmefallbehandlung (Ist-Zustand) Die Vorgehensweise beim Eintritt einer Ausnahmesituation kann in folgende Phasen, die teilweise parallel ablaufen, untergliedert werden: 1. Erkennung und Erstbewertung des Ausnahmefalls, 2. Sicherungsmaßnahmen, 3. Benachrichtigung der verantwortlichen Projektbeteiligten, 4. Beschaffung von Informationen über Versagenszustand, 5. Sanierungsmaßnahmen und 6. Entwarnung. Ausnahmefälle werden entweder durch einen Soll-Ist-Vergleich von Messwerten, ggf. in Verbindung mit automatischen Warnsystemen, oder beim plötzlichen Eintreten einer Ausnahmesituation durch Beobachtung durch unmittelbar anwesende Personen erkannt. Unmittelbar danach folgt die Benachrichtigung der auf der Baustelle tätigen Personen sowie der verantwortlichen Projektbeteiligten, um ggf. erforderliche Sofort- und Sicherungsmaßnahmen einleiten zu können. Die Informationsbeschaffung erfolgt im Ausnahmefall hauptsächlich anhand der auf der Baustelle vorhandenen Dokumente der einzelnen Projektbeteiligten. Die Schnelligkeit des Zugriffs ist dabei von der persönlichen Dokumentenorganisation der beteiligten Personen abhängig. Bei der erheblichen Menge an Informationen in Dokumenten und Dateien, die während der Bauausführung anfallen, kann hier wertvolle Zeit verstreichen, bevor die notwendigen Informationen allen Verantwortlichen zur Verfügung stehen. Die im Einzelfall geeigneten Sanierungsmaßnahmen werden in den sogenannten Havariekonzepten für eine Reihe von Standardsituationen genannt und beschrieben. Die abschließende Entwarnung mit dem Übergang in den Normalbetrieb stellt einen rechtlich schwierigen Teil dar, vergleichbar zur Benachrichtigungsphase und zur Phase der Entscheidung über die Sanierungsmaßnahmen. Da gerade bei extremen Ausnahmefällen häufig Ungewissheiten über vertragliche und rechtliche Konsequenzen der Entscheidungen bestehen und die kausalen Zusammenhänge und Ursachen oft nicht in der zur Verfügung stehenden Zeit zweifelsfrei ermittelt werden können, wird die Entwarnung oft verzögert.

Berücksichtigung von Ausnahmefällen bei Projekten des konstruktiven Tiefbaus

57

Vorhandene Havariekonzepte und QS-Programme In der Praxis vorhandene Havariekonzepte bestehen aus einem Katalog von Maßnahmen für den Havariefall. Diese Konzepte werden für kritische Bauphasen, wie beispielsweise das Lenzen einer Trogbaugrube, erstellt. Tabelle 3.1 gibt einen Überblick zu Themen und Inhalten von Havariekonzepten für Trogbaugruben. Tabelle 3.1. Themen und Inhalte von Havariekonzepten für Trogbaugruben Themen Übersicht

Inhalt Terminplan, Grundriss, Lenzprogramm, Hinweis auf QS-Programm Vorbeugung, Verweis auf Herstellungsprotokolle sämtlicher Qualitätssicherung Bauteile, Überprüfungen vor jedem Arbeitsgang durch Taucher Vorbeugung, Vorschriften, Normen und Hinweise für Bauteile, Arbeitsvorbereitung Sanierungsverfahren und Wasserhaltung Vorbeugung, Messprogramm Messgrößen, Häufigkeit, Dauer von Messungen Schadensbegrenzung, Personal- und Materialeinsatz zur Sanierung, Vorbereitung Stoppen des Lenzens bei Schadensfällen Erkennen Leckage allgemein Festlegung der kritischen Punkte und Messstellen, zugehörige Daten aus QS-Programm Erkennen Leckage beim „Probelenzen“ Grenzmesswerte, Messprogramm Erkennen Leckage beim „Lenzen“ Grenzmesswerte, ständiges Personal vor Ort, vorgehaltene Pumpen und Material Benachrichtigung im Ernstfall Telefonliste

Basis der Havariekonzepte für Trogbaugruben sind die Qualitätssicherungs(QS)Programme. Ein wesentlicher Bestandteil der QS-Programme sind die Herstellungsprotokolle zu den einzelnen Bauteilen mit detaillierten Informationen über die Bauausführung. Eine wichtige Komponente der QS-Systeme bildet das Baustellen-Monitoring im Rahmen der Geotechnischen Beobachtungsmethode. Die Methode ist Bestandteil aktueller geotechnischer Normen1 und beinhaltet die Kontrolle der Bauteil-Baugrund-Interaktion während des Herstellungsprozesses und nach der Fertigstellung eines Bauteils. Die Informationen aus den Herstellungsprotokollen sowie die Daten aus dem Baustellen-Monitoring mit Bezug zu den verantwortlichen Personen sind wichtige Grundlagen für Entscheidungen in Ausnahmesituationen und dienen auch zur Beweissicherung. Nicht vorgedachte Ausnahmesituationen erfordern ad hoc Maßnahmen auf der Basis intensiver Konsultation aller am Projekt Beteiligter. Diese müssen zeitkritisch gestützt werden durch schnelle Identifikation, Beschaffung und Verteilung notwendiger Informationen der Qualitätssicherung.

1

DIN 1054: 2005-01: Baugrund-Sicherheitsnachweise im Erd- und Grundbau, DIN EN 1997-1: 2005-10: Eurocode 7: Entwurf, Berechnung und Bemessung in der Geotechnik

58

Klaus-Peter Holz, Stavros Savidis, Frank Schley, Frank Rackwitz, Marcus Mejstrik

3.2.2 Projektziele, Anforderungen und Randbedingungen Ziel ist die Schaffung einer flexiblen Informations- und Kooperationsplattform für den Spezialtiefbau auf der Basis von Internettechnologien. Ausgangspunkt ist hierfür die Analyse durchgeführter Projekte aus dem Bereich Tiefer Baugruben, aus denen Anforderungen und Randbedingungen unter normalen Baustellenverhältnissen sowie bei Ausnahmefällen zu ermitteln und darzustellen sind. Darauf aufbauend folgt die Entwicklung der Methoden, die eine schnelle Behandlung von Ausnahmefällen in einem dezentral arbeitenden Team von Experten durch integrierende Nutzung der IuK-Technologie erlauben. Voraussetzung für eine webbasierte Bearbeitung ist eine rechnergerechte Abbildung der in einem Spezialtiefbauprojekt anfallenden Informationen und Arbeitsprozesse. Zur Sicherstellung der Handlungsfähigkeit bei Ausnahmefällen ist die Zeitkomponente mit Bezug zu Baufortschritt, Bauüberwachung und beteiligten Personen mitzuführen. Beim Eintreten von Ausnahmesituationen, zu denen keine geeigneten Havariekonzepte bereitstehen, ist es erforderlich, zeitkritisch eine rasche Übersicht über den aktuellen Ausführungsstand der Baustelle zu erhalten. Von Bedeutung sind auch Verweise in den Informationen und die Kenntnis der Informationsentstehung, der Informationsverteilung sowie der Entscheidungsprozesse und der daran Beteiligten. Wichtige Sofortinformationen, die im Ausnahmefall benötigt werden, sind: 1. Lage und Zustand der schadhaften Bauteile sowie deren Herstellungsgeschichte einschließlich verantwortlicher Personen 2. Lage und Zustand sämtlicher Bauteile, Schächte, Leitungen in unmittelbarer Umgebung, Angaben über ggf. schon erfolgte Sanierungsmaßnahmen 3. Lage und Zustand der nahegelegenen Messinstrumente 4. Soll-Ist-Vergleich aller Messgrößen in der Umgebung schadhafter Bauteile 5. Vorhandene Baumaschinen, Personal, Baustoffe für die Sanierung 6. Erreichbarkeit anderer Projektbeteiligter 7. Zugänglichkeiten und Einsatzmöglichkeiten für Personal und Maschinen 8. Vorhandener Baugrund, Herstellungsdaten, Berechnungsparameter, Statik 9. Spezielles Wissen über Normen, Zulassungen und Genehmigungen Hinsichtlich der Planunterlagen zum Bauprojekt genügt eine möglichst zusammenhängende schematische Darstellung der wichtigsten Bauobjekte als Grundlage für Entscheidungen. Sie sollte geometrisch-grafisch gestützt sein. Detaildarstellungen sind unbedeutend. Eine Verknüpfung von Objekten mit weiterführenden Informationen ist sehr sinnvoll, da auch diese im Denken der Beteiligten mit der räumlichen Situation der Baustelle verknüpft werden. Der Erfolg bei der Einführung einer Kooperationsplattform hängt wesentlich von der Kooperationsbereitschaft der Projektbeteiligten ab. Sie kann angeordnet oder durch Motivation erreicht werden. Nachteilig auf die Kooperationsbereitschaft wirken sich unklare und unfaire Risikoverteilungen und damit unklare Haftungsverhältnisse unter den Beteiligten aus. Ebenso nachteilig sind unvollständige bzw. unklare Leistungsabgrenzungen sowie unklare Verantwortlichkeiten.

Berücksichtigung von Ausnahmefällen bei Projekten des konstruktiven Tiefbaus

59

Generell sollten vertragliche Aspekte durch die technisch notwendigen Erfordernisse dominiert werden. Gerade neuere Vertragsmodelle für private Betreibermodelle wie Build-Operate-Transfer(BOT)-Modelle (Gossow 1998) in der Vertragsform der FIDIC EPC/Turnkey Contract’s (Silver Book) eignen sich kaum für Projekte mit großem Baugrundrisiko (Nicklisch u. Weick 2001). Von Spiegl u. Schneider (2001) wurde daher das KEFIR-Modell für eine gerechtere Vergütung und Risikoverteilung entwickelt. Bei der Vertragsgestaltung sollte vermehrt auf technische Belange eingegangen werden, wie z.B. die Pflicht zur Erarbeitung von Havariekonzepten sowie zur Nutzung einer Kooperations- und Informationsplattform. Die Berücksichtigung dieser Aspekte kann zu mehr Kooperationsbereitschaft der Projektbeteiligten führen. Unabhängig davon sind Erfahrungen der Beteiligten mit Konzepten des Risikomanagements und des Controllings vorteilhaft für eine erfolgreiche Kooperation auch beim Eintreten von Ausnahmesituationen, gerade auch im Zusammenhang mit den Konditionen und der Zusammenarbeit mit Banken und Versicherungen. 3.2.3 Lösungskonzept Basis der Informations- und Kooperationsplattform bildet ein Informationsmanagementsystem, welches als hybrides System auf zwei Stufen basiert. In der ersten, dokumentbasierten Stufe wird mittels webbasierten Technologien ein ressourcenbasiertes Informationsmanagement erstellt, um auf die verteilt liegenden Dokumente zugreifen zu können (Hildebrandt 2006). Basis des ressourcenbasierten Informationsmanagements ist eine für jedes Projekt flexibel anpassbare Ontologie mit Bezug auf die wesentlichen Informationen (Schlüsselinformationen). Über die Datenbasis kann auf jedes einzelne Dokument, welches als Container heterogener Informationen angesehen wird, zu jeder Zeit von jedem Ort zugegriffen werden, wobei das Dokument selbst physisch am Erstellungsplatz verbleiben kann. Die zweite Stufe bildet ein modellbasiertes Informationssystem für den Spezialtiefbau mit einem adäquaten Interface. Dieses System beinhaltet die Schlüsselinformationen in der erforderlichen Granularität. Als Interface dient ein grafisch gestützter Navigator, der webbasiert allen dezentral arbeitenden Projektbeteiligten zeitgleich zur Verfügung steht. Der Navigator erleichtert wesentlich das Auffinden der notwendigen Informationen. Das Konzept des Informationsmodells basiert auf einer Beschreibung der Bauobjekte (Bauteile, Messinstrumente, Arbeitsgeräte etc.) mit deren spezifischen Eigenschaften und einer Zeitkomponente sowie der Einordnung in die Organisationsstruktur und in die Bauausführungsprozesse. Die Einbeziehung der Messdaten aus dem Monitoring erfolgt über Modellwerkzeuge. Wesentlich für den Entscheidungsprozess ist die Unterstützung der aktiven Zusammenarbeit im Team durch eine Kommunikationskomponente. Diese Komponente umfasst das gemeinsame Bearbeiten von Informationen sowie die Konsensfindung und Dokumentation der getroffenen Entscheidungen und unterstützt die Ausnahmefallbehandlung beginnend mit der Benachrichtigung bis hin zur Ent-

60

Klaus-Peter Holz, Stavros Savidis, Frank Schley, Frank Rackwitz, Marcus Mejstrik

warnung nach erfolgreicher Sanierung. Die Werkzeuge und Funktionalitäten sind Bestandteil der internetbasierten Kooperationsplattform.

3.3 Beitrag des Projektes zu den Gesamtzielen des SPP und den Zielen der Arbeitsgruppe Die Hauptbeiträge des Projektes zu den Gesamtzielen des SPP sind in den Bereichen Neugestaltung der Planungsprozesse und Neukonzeption der Kommunikation angesiedelt. Durch die integrierende Informationsverarbeitung mittels eines Informationsmanagementsystems sowie durch die Integration des Baustellenmonitorings wird der Entscheidungsfindungsprozess in Ausnahme- und Havariefällen unterstützt sowie die Adaption der Arbeits- und Planungsprozesse vereinfacht. Die im Havariefall benötigten Informationen werden an die betroffenen Akteure über das Informationssystem verteilt und die Kommunikation der Beteiligten ermöglicht. Ein weiterer Beitrag wird im Bereich Integration der Software und Modelle geleistet: Durch ein Verfahren zur Interaktion der eingesetzten Fachsoftware wird die Informationsaufnahme in das Informationsmanagementsystem erheblich vereinfacht und aus dem Verbund der Fachmodelle ein konsistentes Gesamtmodell erstellt. Zu den darüber hinaus gestellten Zielen der Arbeitsgruppe Prozessmodellierung werden Beiträge zur Analyse und Formalen Beschreibung von Planungsprozessen geleistet. Anhand realer Bauvorhaben wurden die Kerninformationen und Prozesse des Spezialtiefbaus identifiziert und sowohl bauteil- als auch prozessorientiert analysiert. Darauf aufbauend wurde ein Informationsmodell erstellt, welches das Bauvorhaben mit seinem Erstellungsprozess und der Organisationsstruktur abbildet. Für die Prozessmodellkomponente wurden u. a. die Methoden der Netzplantechnik eingesetzt.

3.4 Hybrides Informationsmanagement im Spezialtiefbau Das im Lösungskonzept erläuterte hybride Informationsmanagement kombiniert zwei Ansätze, die auf unterschiedlichen Ebenen der Informationsintegration basieren. Die erste Ebene bildet die Verwaltung von Informationsressourcen mittels webbasierter Technologien in einer verteilten Projektumgebung. Die zweite Ebene bildet ein integriertes modellbasiertes Informationsmanagementsystem, das das Auffinden von Information unterstützt. Den Kern bildet ein Informationsmodell für den Spezialtiefbau, das kritische „Schlüsselinformationen“ des Bauvorhabens abbildet. Der generalisierte Aufbau des Informationsmodells erlaubt die Anpassung an andere Fachdisziplinen.

Berücksichtigung von Ausnahmefällen bei Projekten des konstruktiven Tiefbaus

61

3.4.1 Ressourcenbasiertes Informationsmanagement Eine wesentliche Komponente des hybriden Informationsmanagementsystems ist das webbasierte Ressourcenmanagementsystem (Hildebrandt 2006). Es wurde ursprünglich entwickelt, um die gemeinsame Nutzung von heterogenen Informationsressourcen in verteilten Projektumgebungen zu unterstützen und den Nachteil, der durch verschiedene Versionen und Kopien von im Umlauf befindlichen Dokumenten entsteht, zu überwinden. Typische Informationsressourcen des Ingenieurwesens sind alle Arten von (traditionellen) Ingenieursdokumenten (Pläne, Berechnungen, Verträge etc.), Listen (Monitoringdaten) sowie Bild- und Videodateien (Beobachtung und Dokumentation). Die Verwaltung dieser Informationsressourcen verlangt nach der Kennzeichnung der impliziten und versteckten Informationen. Diese erfolgt mittels beschreibender Einträge, in denen vor allem Schlüsselinformationen zur referenzierten Ressource enthalten sind. Die Schlüsselinformationen werden mit einer Ontologie semantisch beschrieben, die projektspezifisch definierbar ist. Beispiele für die semantische Beschreibung von Ressourcen ist deren Einordnung nach Bauobjekttyp, Dokumententyp oder Messwert. Die beschreibenden Einträge werden in einer Datenbank gespeichert, nicht jedoch die referenzierten Ressourcen selbst. Diese verbleiben physisch an ihrem Ursprungsort und somit in der Verantwortung ihrer Ersteller/Autoren. Das Ressourcenmanagementsystem ist als eine Webapplikation implementiert, die die Datenbank verwaltet und Nutzeranfragen verarbeitet. Das System ist über übliche webbasierte Client-Software zugänglich. In der Basisfunktionalität können auch PDAs und Mobiltelefone beim Vorhandensein entsprechender Infrastruktur verwendet werden. Die Basisfunktionalität umfasst die Suche über die semantische Kennzeichnung, Navigation durch die Dokumenteneinträge, Bearbeitung von Dokumenteneinträgen, integrierte Visualisierung referenzierter Informationen und persönliche Arbeitsbereiche für registrierte Nutzer. Eine einfache Kooperationsunterstützung ist durch die Integration von Kommunikationswerkzeugen gegeben. 3.4.2 Modellbasiertes Informationsmanagement Die erforderliche Information zur Behandlung von Ausnahmefällen im Spezialtiefbau ist in einem generalisierten Informationsmodelltyp in der geforderten Granularität abbildbar. Das Informationsmodell besteht aus drei Komponenten zur Abbildung der Bauobjekte eines Bauvorhabens, des Ausführungsprozesses und der Organisationsstrukturen. Komponentenübergreifende Beziehungen zwischen Modellelementen kennzeichnen beispielsweise Verantwortlichkeiten für einzelne Bauobjekte oder deren zeitliche Gültigkeit oder bilden eine Verknüpfung von Bauaktivitäten, verantwortlichen Organisationseinheiten und zugehörigen Bauobjekten.

62

Klaus-Peter Holz, Stavros Savidis, Frank Schley, Frank Rackwitz, Marcus Mejstrik

Komponente zur Abbildung der Bauobjekte Die rechnergerechte Abbildung von Bauobjekten erfolgt durch Spezialisierungen der abstrakten Klassen Bauobjekt (ConstructionObject) und der sie beschreibenden Eigenschaften (Property). Bauobjekte sind die wesentlichen Bauteile eines Vorhabens sowie die zur Ausnahmefallbehandlung erforderlichen Arbeitsgeräte, Messinstrumente, Baustelleneinrichtung und Ver- und Entsorgungsleitungen. Das Herauslösen von Bauobjekteigenschaften in explizite Eigenschaftsobjekte anstelle der Abbildung als Attribute der Bauobjekt-Klassen hat eine hohe Adaptier- und Erweiterbarkeit des Informationsmodells zur Folge. In Abbildung 3.3 sind die wesentlichen Elemente der Bauobjektkomponente dargestellt. Jedes Bauobjekt ist Teil (modelObjectComposition) eines Bauvorhabens (ConstructionModel) außer das Bauvorhaben selbst. Das Bauvorhaben dient als zentrales Modellelement und verwaltet alle Bauobjekte. Die Bauobjekteigenschaften werden als aggregierte (objectPropertyAggregation) Bestandteile über explizite Eigenschaftsobjekte beschrieben. Beziehungen zwischen konkreten Bauobjekttypen bzw. zwischen konkreten Bauobjekteigenschaftstypen werden mit Spezialisierungen der abstrakten Assoziationen objectAssociation bzw. propertyAssociation abgebildet. ConstructionModel 0..1

modelObjectComp. * <>

objectRespAss.

OrganizationUnit 1

ConstructionObject

*

*

*

Anmerkung: jedes Bauobjekt ist Teil eines Bauvorhabens, außer das Bauvorhaben selbst

objectTimeComp.

Date

1..2

1..* objectPropertyAgg. objectAss. * propertyTimeComp. <>

1..2

<>

Property *

* <>

propertyAss.

Abb. 3.3. Bauobjekt-Komponente

Analog zu den Spezialisierungen von Bauobjekten erfolgt die Spezialisierung der Bauobjekteigenschaften (Property) mit den entsprechenden spezialisierten Assoziationen (propertyAssociation). Die Bauobjekteigenschaften bilden sowohl Sollals auch Ist-Werte ab, die Detaillierung der Abbildung der Eigenschaften ist allerdings auf den Einsatzzweck des Modells zur Beurteilung der Situation im Havariefall beschränkt. Die erste Spezialisierungsstufe der Bauobjekteigenschaften bilden Geometrie-, Material-, Tragverhaltens- oder Konstruktionseigenschaften. Geometrische Eigenschaften bilden aufgrund ihrer Relevanz bei der Beurteilung des Erstellungsprozesses von Bauteilen den Schwerpunkt der Modellierung von Bauobjekteigenschaften (Schley et al. 2004). Die Konstruktoren der spezialisierten Bauobjekte sind dafür verantwortlich, die sinnvolle Initialisierung notwendiger typspezifischer Eigenschaften sicherzustellen.

Berücksichtigung von Ausnahmefällen bei Projekten des konstruktiven Tiefbaus

63

Die zeitliche Gültigkeit (Lebensdauer) von Bauobjekten und Eigenschaften wird mit einer Komposition (objectTimeComposition, propertyTimeComposition) zu einem oder zwei Zeitpunkten beschrieben. Hat ein Objekt einen Zeitpunkt, ist es ab diesem gültig, bei zwei Zeitpunkten war es zwischen diesen beiden Zeitpunkten gültig. An ungültigen Objekten können keine Änderungen durchgeführt werden. Ungültige Objekte verbleiben zur Dokumentation und Nachvollziehbarkeit im System. Im Sinne einer Objekt-Verantwortlichkeitsbeziehung besteht eine Assoziation (objectResponsibleAssociation) zwischen Bauobjekt und Organisationseinheit. Verantwortlichkeiten für die Ausführung von Herstellungsprozessen sind separat modelliert und im nachfolgenden Abschnitt beschrieben. Komponente zur Abbildung des Ausführungsprozesses Die Ausführungsprozesse werden mit zeitlich bestimmten Aktivitäten, deren Beziehungen untereinander, Rollen und Akteuren abgebildet. Abbildung 3.4 zeigt die wesentlichen Elemente der Prozess-Komponente im Klassendiagramm.

ConstrObjEvent

Event

eventTimeAss.

<>

ActivityEvent

*

activityEventAss. * objectEventAss.

Role

<>

ConstructionObject

{acyclic}

activityGraph

*

1 1..* objectActivitysetComp.

ActivitySet *

*

1

1..*

activitysetActivityRoleAss.

*

*

*

Activity

plannedStartAss. plannedEndAss.

<>

* <>

0..1

1

Date

* 0..1 0..2 0..1 0..1 * activity- executedTimeAss. HistoryAss.

1..2

activitysetTimeAss.

Abb. 3.4. Prozess-Struktur-Komponente

Aktivitäten (Activity) werden mittels einer ternären Assoziation (activitysetActivityRoleAssociation) über Rollen (Role) an Aktivitätsmengen (ActivitySet) geknüpft. Rollen sind Elemente der Organisationsstruktur-Komponente und werden von Akteuren, die Aktivitäten ausführen, angenommen (siehe nächster Abschnitt). Eine oder mehrere Aktivitätsmengen sind Bestandteil (objectActivitysetComposition) eines Bauobjekts. Eine Aktivitätsmenge fasst alle Aktivitäten eines bestimmten Gültigkeitszeitraums zusammen, die mit oder an diesem Bauobjekt ausgeführt werden. Eine Aktivität steht über zwei Assoziationen (plannedStartAssociation, plannedEndAssociation) in Beziehung zu jeweils keinem oder einem Zeitpunkt, die im Sinne der Netzplantechnik den frühestmöglichen Anfangszeitpunkt und den spätestmöglichen Endzeitpunkt der Ausführung darstellen. Nicht assoziierte Zeiten werden bei der Berechnung des Netzplanes ermittelt. Ableitbare Größen

64

Klaus-Peter Holz, Stavros Savidis, Frank Schley, Frank Rackwitz, Marcus Mejstrik

sind – in Verbindung mit der eine Aktivität beschreibenden geplanten Ausführungsdauer – die Zeitpunkte des spätestmöglichen Beginns sowie des frühestmöglichen Endes. Null bis zwei weitere Zeiten dokumentieren die tatsächliche Ausführung einer Aktivität (executedTimeAssociation). Anhand der Kardinalität der entsprechenden Assoziation wird der Ausführungsstand der Aktivität bestimmt (null: geplant und noch nicht begonnen, eins: begonnen aber noch nicht beendet, zwei: vollständig ausgeführt). Die Modellierung der zeitlichen Abfolge von Aktivitäten erfolgt durch einen gerichteten azyklischen Aktivitätsgraphen (activityGraph). Er enthält alle Aktivitäten des Ausführungsprozesses mit ihren Vorgänger-/Nachfolgerbeziehungen als gerichtete Kanten. Zusammen mit den o. g. Planungszeiten stellt der Graph einen Netzplan der Bauausführung dar und ermöglicht die üblichen Operationen der Zeitenplanung. In Verbindung mit den Ausführungszeiten wird die zeitliche Verfolgung und Steuerung des Bauablaufes realisiert, wobei die einzelnen Bauzustände ableitbar sind. Über einfache Mengenoperationen können alle Aktivitäten in Submengen unterteilt werden, z.B. in die der startbaren oder der blockierten Aktivitäten. Zur Dokumentation von Planungsänderungen werden keine zeitlichen und organisatorischen Änderungen an bestehenden Aktivitäten zugelassen. Bei Planungsänderungen werden betroffene Aktivitäten als ungültig markiert und mit einer neuen Instanz assoziiert (activityHistoryAssociation). Ältere Planungszustände werden so mitgeführt und können bei Ausnahmeereignissen bewertet werden („Planungstagebuch“ zur Beweissicherung). Während der Aktivitätsgraph die Menge aller gültigen Aktivitäten zusammenfasst, werden in einer sogenannten Aktivitätsmenge (ActivitySet) alle (gültigen oder ungültigen) Aktivitäten eines Bauobjekts gruppiert. In Analogie zu den Aktivitäten werden unter bestimmten Bedingungen (Planungsänderungen, Ausnahmen etc.) Aktivitätsmengen ungültig gesetzt, zum Zwecke der Dokumentation aufbewahrt und durch neue Instanzen ersetzt. Somit kann nachträglich jeder Planungsund Ausführungszustand jedes Bauobjektes vergegenwärtigt werden (Schley et al. 2004). Ereignisse werden im Sinne von Ausnahmeereignissen als Spezialisierungen der abstrakten Klasse Event modelliert. Ein Bauobjektereignis (ConstructionObjectEvent) wird ausgelöst, wenn in der Bauüberwachung unzulässige Abweichungen von Bauobjekteigenschaften oder das Versagen von Bauteilen festgestellt werden. Eine zeitliche Abweichung vom geplanten Bauablauf löst ein Aktivitätsereignis (ActivityEvent) aus. Bauobjektereignisse sind mit dem jeweiligen sie betreffenden Bauobjekt verknüpft (objectEventAssociation), Aktivitätsereignisse mit der jeweiligen sie auslösenden Aktivität (activityEventAssociation). Der Zeitpunkt des Eintretens eines Ereignisses wird dokumentiert (eventTimeAssociation). Ereignisse werden automatisch durch Soll-Ist-Vergleiche oder manuell durch Akteure ausgelöst. Die abstrakten Klassen der Bauobjektereignisse und Aktivitätsereignisse müssen weiter spezialisiert werden. Beispiele für konkrete Aktivitätsereignisse sind z.B. Ereignisse des verspäteten oder auch vorzeitigen Beginns oder Endes der Ausführung einer Aktivität. Erstere erfordern unter Umständen gewisse Umpla-

Berücksichtigung von Ausnahmefällen bei Projekten des konstruktiven Tiefbaus

65

nungen, um Verspätungen auszugleichen. Bauobjektereignisse werden speziell für Bauobjekttypen und deren mögliche Versagensmechanismen spezialisiert, beispielsweise für das Überschreiten von vorgegebenen Maximalverformungen von Schlitzwänden oder den Wassereintritt beim Lenzen von Baugruben infolge Undichtigkeiten von Düsenstrahlsohle, Schlitzwänden bzw. deren Anschlüssen. Mögliche Maßnamen sind in den Ereignistypen entsprechend der vor der Ausführung in Havariekonzepten vordefinierten Reaktionen auf bestimmte Ausnahmefalltypen abgebildet, beispielsweise die stabilisierende Verankerung von Schlitzwänden bei Überschreitung der Maximalverformung. Maßnahmen können sowohl das Prozessmodell als auch das Bauobjektmodell betreffen. Vordefinierte Maßnahmen-Prozesse werden bei Bedarf in den Gesamtprozess integriert und Bauobjekteigenschaften werden bei einfachen Maßnahmen angepasst oder neue Bauobjekte und Bauobjekteigenschaften werden hinzugefügt. Komponente zur Abbildung der Organisationsstrukturen Die Organisationsstruktur-Komponente ist in der Lage, die auf Baustellen vorherrschenden Organisations- und Verantwortungsstrukturen in grober Form abzubilden. Abbildung 3.5 zeigt die wesentlichen Elemente der OrganisationsstrukturKomponente. Contact 1..*

contactableContactAss.

Person

1..*

Actor

Contactable

ActiveDevice

1..* roleActorAss. * 1

OrganizationUnit 0..1

*

orgRoleComp.

Role

*

objectRespAss.

organizationAgg.

ActivitySet 1..*

*

Activity activitysetActivityRoleAss.

objectActivitysetComp.

<>

ConstructionObject

Abb. 3.5. Organisationsstruktur-Komponente

Hierarchische Organisationsstrukturen werden mit einer Aggregation (organizationAggregation) von Organisationseinheiten (OrganizationUnit) modelliert. Eine Organisationseinheit definiert Rollen (Role) (Projektleiter, Polier etc.), die die ausführenden Akteure (Actor) in ihrer Tätigkeit bei der Bearbeitung einer Aktivität (Activity) beschreibt. Akteure werden unterschieden in Personen und nichtmenschliche Akteure. Letztere handeln autonom, z.B. zur automatisierten Aufzeichnung und Auswertung von Messwerten. Eine Rolle stellt die kontextspezifische Zuordnung von Akteur zu Aktivität und zu bearbeitendem Bauobjekt (über dessen Aktivitätsmenge) dar (activitysetActivityRoleAssociation). Organisati-

66

Klaus-Peter Holz, Stavros Savidis, Frank Schley, Frank Rackwitz, Marcus Mejstrik

onseinheit, Rolle und Akteur sind jeweils kontaktierbare Einheiten (Contactable), denen Kontaktinformationen (Contact) zugeordnet sind. 3.4.3 Modellmanagement Generell werden in Ingenieurprojekten viele verschiedene Modelle angewendet, die einzeln für sich genommen eng abgesteckte Teilbereiche des gesamten Projekts in unterschiedlichen Sichtweisen abbilden. Dies führt zu spezialisierten Softwarelösungen und Informationsmodellen, die häufig parallel und unabhängig voneinander Anwendung finden. Schlüsselinformationen über den aktuellen Zustand und den bisherigen Verlauf eines Bauprojekts werden aus externen Fachmodellen und Datenquellen extrahiert und im Spezialtiefbaumodell abgebildet, um einen schnellen und integrierenden Informationszugang zu gewähren. Dieses Modell kann jedoch nicht als die Summe aller eingebundenen externen Fachmodelle bzw. deren relevanten Modellteile gebildet werden, da dadurch hervorgerufenen Redundanzen grundlegende Abbildungsprinzipien verletzen und somit Konsistenzprobleme hervorrufen. Zwei Ansätze zur Erstellung konsistenter Informationsmodelle als Zusammenführung verschiedener Modelle wurden identifiziert. Der erste Ansatz ist die Entwicklung und Anwendung von Produktmodellen als zentrale Kernmodelle, etwa die IFC (IAI 2004) oder ganz generell Gebäudeinformationsmodelle (Tse et al. 2005) mit entsprechenden Schnittstellen zu spezialisierten Anwendungsprogrammen. In Produktmodellen werden Systeme idealerweise eindeutig, redundanzfrei und in einheitlicher Beschreibung dargestellt. Ein Nachteil von Produktmodellen ist die Notwendigkeit, eine Fachdomäne vollständig im zugehörigen Modelltyp abzubilden, wohingegen in den konkreten Projektumgebungen jeweils nur ein kleiner Teil des komplexen Produktmodelltyps Anwendung findet (Brüggemann 2006). Nach dem zweiten Ansatz verbleiben die heterogenen (verteilten) Teilmodelle in ihren spezifischen Darstellungen. Die Bearbeitung der Modelle erfolgt getrennt und weitgehend unabhängig voneinander. Ein Informationsaustausch zwischen den Teilmodellen erfolgt über verknüpfende Schnittstellen. Ein Nachteil dieses Modellierungsansatzes ist, dass Redundanzen zwischen den Teilmodellen auftreten und somit kein eindeutiges Gesamtmodell des Bauvorhabens existiert. Das Informationsmanagementsystem für den Spezialtiefbau verwendet Komponenten beider Ansätze (Schley et al. 2006). Einerseits wird die Bearbeitung der heterogenen Fachmodelle weiterhin unabhängig voneinander ermöglicht, andererseits wird das Informationsmodell für den Spezialtiefbau als zentrales integrierendes Modell behandelt, das Elemente der externen Fachmodelle integriert. Die unvermeidlich auftretenden Redundanzen werden durch ein Modellmanagement verwaltet. Die Persistenz des eigentlichen Modells wird über die Fachmodelle und die zugehörigen Softwaresysteme realisiert. Das Modellmanagement besteht aus zwei Teilen: einer Transferkomponente und einer Managementkomponente. Die Transferkomponente agiert als eine Zwischenschicht (vgl. Froese et al. 2000) und stellt (transformierende) Schnittstellen

Berücksichtigung von Ausnahmefällen bei Projekten des konstruktiven Tiefbaus

67

zwischen den Fachmodellen und dem Spezialtiefbaumodell bereit. Die Managementkomponente verwaltet die Abhängigkeiten zwischen den modellbeschreibenden Elementen im Spezialtiefbaumodell und den externen Fachmodellen. Das Aufzeigen von Inkonsistenzen zwischen mehreren Fachmodellen ist ein positiver Nebeneffekt des Modellmanagements. Transferkomponente Um die Kopplung der heterogenen Fachmodelle zu ermöglichen, wird für die Transferkomponente ein generalisiertes mengenbasiertes Kernmodell mit speziellen semantisch beschreibbaren Elementen zum lesenden und schreibenden Informationstransfer verwendet (Brüggemann 2006). Das Mengenmodell besteht in Anlehnung an die elementare Mengentheorie aus Objekten, Mengen, Tupeln und Relationen sowie darüber hinaus aus sogenannten strukturierten Objekten, in denen auf effiziente Weise Massendaten referenziert werden können. Das Mengenmodell enthält keine weitere fachspezifische Semantik, dadurch ist es besonders für einen einfachen und generalisierten Transfer aller Arten von Ingenieurinformationen geeignet. Der Transfer von Informationen aus externen Fachmodellen in das mengenbasierte Kernmodell und der Transfer von Informationen aus dem mengenbasierten Kernmodell in das Spezialtiefbaumodell wird von Lese- und Schreib-Elementen ausgeführt. Optionale Transformations-Elemente operieren auf den Mengenobjekten innerhalb des Kernmodells. Zwei Schnittstellen dienen der Beschreibung der in das Kernmodell eingehenden und aus dem Kernmodell ausgehenden Mengenobjekte (Reader und Writer). Die Lese- und Schreib-Elemente implementieren jeweils eine dieser Schnittstellen, das Transformations-Element implementiert beide Schnittstellen. Mit diesen Elementen kann eine InformationsTransformations-Kette aufgebaut werden, indem jeweils ein Reader mit einem Writer verknüpft wird. Die Verknüpfbarkeit wird anhand der semantischen Beschreibung der von den Schnittstellen gelieferten bzw. konsumierten Mengenobjekte festgestellt. Die Schnittstellendefinitionen sind sehr einfach gehalten und können mit vertretbarem Aufwand für spezifische Fachmodelle implementiert werden. Managementkomponente Die Managementkomponente verwaltet die Integration der verschiedenartigen (Teil-)Fachmodelle und des Spezialtiefbaumodells in ein einziges Gesamtinformationsmodell unter Einhaltung der Abbildungsprinzipien. Hierzu werden Abhängigkeiten zwischen originalen modellbeschreibenden Elementen und redundanten nicht-modellbeschreibenden Elementen (Kopien) mittels spezieller Verknüpfungsobjekte beschrieben. Innerhalb dieses Gesamtinformationsmodells wird das Spezialtiefbaumodell als ein internes, operationelles Modell angesehen, d.h. es beschreibt die komplette Struktur des Gesamtmodells, dennoch muss es nicht notwendigerweise alle modellbeschreibenden Elemente als Originale selbst enthalten. Aus Praktikabilitäts-

68

Klaus-Peter Holz, Stavros Savidis, Frank Schley, Frank Rackwitz, Marcus Mejstrik

gründen (vereinfachte Darstellung, direktes Bearbeiten) kann es jedoch Kopien von modellbeschreibenden Elementen beinhalten, die sich als Originale in externen Fachmodellen befinden. Um entsprechende Elemente der Transferkomponente auszuwählen, muss die Managementkomponente die Struktur des Spezialtiefbaumodells (und somit die Struktur des Gesamtinformationsmodells) kennen. Das Spezialtiefbaumodell stellt entsprechende Strukturinformationen dynamisch bereit. Diese umfassen Typen und Multiplizitäten von Objektattributen sowie Eigenschaften von Objektassoziationen (Typen der assoziierten Objekte und Multiplizitäten). Anhand dieser Strukturinformationen können die Modellinformationen in Elemente des mengenbasierten Kernmodells überführt und somit passende Schreib- und Lese-Elemente für den Datentransfer vom/zum Spezialtiefbaumodell ausgewählt werden. Fachmodellseitig existieren ähnliche Strukturbeschreibungen, anhand derer passende Lese- bzw. Schreib-Elemente für den Datentransfer von/zu den Fachmodellen ausgewählt werden. Schließlich wird durch den Aufbau einer InformationsTransformations-Kette unter Zwischenschaltung von optionalen TransformationsElementen der Informationsfluß von einem oder mehreren externen Fachmodellen in das Spezialtiefbaumodell initiiert. Die Managementkomponente verfügt über einen Modellmanager (ModelManager), der alle verwalteten Modellelemente (ModelElement) des Spezialtiefbaumodells enthält, d.h. alle Modellbestandteile, die eine entsprechende Repräsentation in einem externen Fachmodell besitzen (s. Abb. 3.6). Ein (verwaltetes) Modellelement hat eine beschreibende (interne oder externe) und mindestens eine nicht beschreibende (externe oder interne) Repräsentation. Die tatsächliche Repräsentation des Modellbestandteils wird durch eine Spezialisierung (InternalMED, ExternalMED) des abstrakten ModelElementDescriptor (MED) gekennzeichnet. Ein InternalMED beschreibt ein Element des Spezialtiefbaumodells (Bauobjekt, Eigenschaft, Aktivität etc.). Ein ExternalMED ist eine generalisierte Beschreibung einer externen Fachmodellquelle (URL, Format etc.). Die Verbindung zur Transferkomponente wird über zum ModelElementDescriptor assoziierte Lese- und Schreib-Elemente (Reader, Writer) hergestellt. Ein optionales Transformations-Element (Transformer) ist direkt an das Modellelement geknüpft. ModelManager

*

ModelElement 1

1

1

1..*

describing

0,1

0,1

non-describing 0,1

<>

ModelElementDescriptor

0,1

Transformer Reader 0,1 0,1

Writer

InternalMED ExternalMED

Abb. 3.6. Elemente der Managementkomponente

Transfer Component

Berücksichtigung von Ausnahmefällen bei Projekten des konstruktiven Tiefbaus

69

CAD

CADPointsReader External Collection points MED StructObject point

CoordinateTransformer …

Writer

…

Reader

Double x Double y …

External Domain Models

…

ExcavationInfoReader External Object depth MED Object name …

ExcavationWriter Internal MED

Object depth Collection points StructObject point Double x Double y Object name …

Information Transfer Model Management

Geotechnical Engineering Information Model

ExcavationModelElement

Abb. 3.7. Prinzip des Modellmanagements und des Informationstransfers

Abbildung 3.7 demonstriert das Funktionsprinzip von Transfer- und Managementkomponente am Beispiel der Instanziierung von Bauobjekten und zugehörigen Bauobjekteigenschaften anhand von Informationen, die bereits in Fachmodellen enthalten sind.

3.5 Implementierung des Prototyps Der entwickelte Informationsmodelltyp für den Spezialtiefbau sowie Werkzeuge zur Präsentation und Bearbeitung des Modells wurden in ihrer Grundfunktionalität vollständig in Java implementiert und exemplarisch verifiziert. Um der Forderung nach einem flexiblen Informationsmanagement und einfacher Navigation innerhalb eines bestehenden Modells gerecht zu werden, sind die modellierten Objektbeziehungen explizit implementiert (Brüggemann 2006). Hierzu wurde ein Assoziationsmanager implementiert, der die im generalisierten Modelltyp definierten Relationen sowie alle Spezialisierungen der abstrakten BauobjektBauobjekt-Assoziation zur Abbildung der Bauobjekttopologien enthält. Die explizite Implementierung von Objektrelationen bietet mehrere Vorteile für das Informationsmanagement: U. a. automatische Konsistenzprüfung, vereinfachte Navigation und Selektion, entkoppelte Klassenimplementierung (Schley et al. 2004). Für Bauobjekte wurde ein allgemeines Werkzeug zur Präsentation und Bearbeitung von typspezifischen und individuellen topologischen Zusammenhängen zwischen einzelnen Bauobjekten, organisatorischen Verantwortlichkeiten sowie objektspezifischen Aktivitäten implementiert. Diesem Werkzeug können modular weitere Werkzeuge für bauobjektspezifische Eigenschaften hinzugefügt werden, z.B. Soll- und Ist-Werte von Pegelganglinien, Bodenschichtungen und für geometrische Eigenschaften von Bauteilen wie Schlitzwänden und Düsenstrahlsohle. Eine weitere Gruppe von Werkzeugen dient der Verfolgung, Steuerung und Bearbeitung des Ausführungsprozesses. Der Planungs- und Ausführungszustand von Aktivitäten kann direkt an den beteiligten Bauobjekten abgelesen werden.

70

Klaus-Peter Holz, Stavros Savidis, Frank Schley, Frank Rackwitz, Marcus Mejstrik

Zwei weitere Werkzeuge erlauben die Navigation innerhalb der Prozessstruktur anhand der zeitlichen Einordnung der Aktivitäten sowie deren VorgängerNachfolger-Beziehungen (Abb. 3.8). Eine vereinfachte Balkenplandarstellung im Aktivitätsdiagramm zeigt die zeitliche Abfolge der Aktivitäten. Über den Aktivitätsgraphen sind die Struktur des Ausführungsprozesses (Reihenfolge der Aktivitäten) erkennbar.

Abb. 3.8. Aktivitätsdiagramm und Aktivitätsgraph

Über jedes dieser Werkzeuge kann der Bezug zu den entsprechenden Bauobjekten und den sie bearbeitenden Organisationen hergestellt werden. Die Bearbeitung der Prozess-Struktur wird vorrangig mit dem Aktivitätsgraphen ermöglicht. Die implementierten Organisationswerkzeuge stellen die Organisationshierarchien übersichtlich dar und ermöglichen deren Bearbeitung. Die Zuordnung von Rollen zu ihren Organisationseinheiten sowie von Rollen zu Akteuren und Aktivitäten wird mit einem einfachen Werkzeug realisiert. Kontaktinformationen lassen sich für Organisationseinheiten, Rollen und Akteure zum Aufbau einer netzbasierten Kommunikation nutzen. Alle genannten Werkzeuge für das modellbasierte Informationsmanagement sind Bestandteil einer netzgestützten Applikation, deren zentrale Komponente der grafische Navigator ist. Er dient der übersichtlichen Darstellung des Bauvorhabens mit seinen Bauobjekten in schematischer Form und ermöglicht dem Nutzer das schnelle Auffinden von Bauobjektinformationen und das Erkennen von räumlichen Zusammenhängen. Die zeitlichen Zusammenhänge werden im Navigator auf Basis der (aktuellen) Modellzeit und einer einstellbaren Präsentationszeit dargestellt. Das Bauvorhaben ist dadurch in jedem beliebigen Planungs- und Fertigstellungszustand mit den jeweils aktuellen Bauobjekt-, Organisations- und Prozessinformationen einsehbar. Beweissicherung und Dokumentation sind somit auf dem Informationsmodell basierende Funktionalitäten des Navigators. Das ressourcenbasierte Informationsmanagementsystem (Hildebrandt 2006) wurde über den Navigator und die Bauobjektwerkzeuge eingebunden. Abb. 3.9 zeigt beispielhaft den grafischen Navigator mit dem Ressourcenmanagement als zentrale Komponenten des hybriden Informationsmanagementsystems.

Berücksichtigung von Ausnahmefällen bei Projekten des konstruktiven Tiefbaus

71

Abb. 3.9. Zentrale Komponenten des hybriden Informationsmanagementsystems

Die für die Verwaltung der Integration verschiedener (Teil-)Fachmodelle und des Spezialtiefbaumodells zuständige Modellmanagement-Komponente wurde in ihrer Grundfunktionalität implementiert. Elemente der Transferkomponente wurden exemplarisch für die Integration der Baugruben- und DüsenstrahlsohlenGeometrie in das Spezialtiefbaumodell umgesetzt. Die eingebundenen Informationen sind in CAD-Zeichnungen enthalten. Die Lese-Elemente (Reader) der Transferkomponente setzen auf der programmierbaren Schnittstelle des CADSystems AutoCAD auf. Sie besitzen ein interaktives Interface, das die teilautomatisierte Auswahl der Geometrieinformationen erlaubt. Die Reader überführen die selektierten Informationen in Mengenelemente des Kernmodells, die wiederum von speziellen Schreib-Elementen (Writer) auf Seiten des Spezialtiefbaumodells in entsprechende Bauobjekte und Bauobjekteigenschaftsobjekte überführt werden.

3.6 Anwendungsbeispiel Das webbasierte hybride Informationsmanagementsystem wurde im Zuge eines großen geotechnischen Bauprojekts im Zentrum von Berlin begleitend getestet. Gegenstand dieses Projekts war die Herstellung einer Tiefen Baugrube mit einer Gesamtfläche von über 22.000 m², die in nur 8 Monaten errichtet werden mußte (Abb. 3.10). Die Baugrube wurde in 4 Baufelder unterteilt, um Sicherheitsansprüchen zu genügen und die Effektivität zu erhöhen und damit dem engen Zeitplan gerecht zu werden. Eines der Hauptprobleme beim Entwurf und bei der Bauausführung von Tiefen Baugruben in Berlin ist der stark durchlässige sandige Baugrund. Der Grundwasserspiegel befindet sich ca. 4 m unterhalb der Geländeoberfläche und eine weitreichende Grundwasserabsenkung ist nicht erlaubt. Daher werden vor allem Trogkonstruktionen für Tiefe Baugruben in

72

Klaus-Peter Holz, Stavros Savidis, Frank Schley, Frank Rackwitz, Marcus Mejstrik

Berlin verwendet. Bei der Herstellung dieser Baugrube kamen rückverankerte Schlitzwände und eine tiefliegende Düsenstrahlsohle zum Einsatz. Die Tiefe der Baugrubensohle in den einzelnen Baufeldern variierte zwischen 14 und 17 m. Mittels Dichtwänden erfolgte die Unterteilung der Baugrube in die einzelnen Baufelder.

Abb. 3.10. Anwendungsbeispiel: Herstellung einer Tiefen Baugrube

Das ressourcenbasierte Informationsmanagementsystem und der webbasierte Grafische Navigator zusammen mit dem vereinfachten Modell ohne die Prozessund Organisationskomponente wurde während der Bauausführung für das Management von Daten und Informationen verwendet. Die Struktur der auf dieses Projekt speziell abgestimmten Ontologie wurde zusammen mit dem Projektmanagement und den Verantwortlichen der Qualitätssicherung der ausführenden Firma entwickelt und diskutiert. Während der Ausführungsphase eines Projektes in der beschriebenen Größenordnung fällt eine enorme Anzahl verschiedener Daten und Dokumente an. Es wurde daher entschieden, von Anfang an die Klassen von Dokumenten innerhalb des Informationssystems auf folgende Typen zu begrenzen: Herstellungsprotokolle für Wände, Sohle, Anker; Pläne; Grundwassermessdaten; Daten und Dokumente verschiedener Messungen aus dem Monitoring während und nach der Herstellung. Eine Gesamtanzahl von mehr als 8.500 Dokumenten wurde mit diesem System verwaltet. Das Informationssystem wurde vom Personal der Bauausführung und Qualitätssicherung verwendet. Gastzugänge wurden für Nachunternehmer und beratende Ingenieure bereitgestellt. Es wurden Fragebögen entwickelt und an die Benutzer des Systems verteilt, um ein Feedback für die Evaluation und ständige Verbesserung des Systems zu erhalten. Die Auswertung der Fragebögen spiegelte die Vorteile der Verwendung des Systems für die Praxis wider. Sie belegen die positive Resonanz und Akzeptanz in der Baupraxis. Nach der Fertigstellung der Baugrube dienen alle Daten nun als Projektarchiv und werden für weitere Auswertungen in Forschung und Praxis verwendet.

Berücksichtigung von Ausnahmefällen bei Projekten des konstruktiven Tiefbaus

73

3.7 Zusammenfassung, Ausblick und Danksagung Im Rahmen des Forschungsprojekts wurde ein internetbasiertes Informationsmanagementsystem für die vernetzt-kooperative Bearbeitung von Projekten des Spezialtiefbaus konzipiert, vollständig in Java implementiert und verifiziert. Die Anforderungen und Randbedingungen für das System ergaben sich aus einer detaillierten Analyse der Prozessabläufe bei Spezialtiefbaumaßnahmen. Besonders während der Bauausführung unterscheiden sich diese Projekte vom übrigen Konstruktiven Ingenieurbau, weil unvorhergesehene Ausnahmesituationen bis hin zu Havariefällen, die häufig geologisch oder hydrogeologisch bedingt sind, eintreten können. Es erwies sich für die Informationsverarbeitung als notwendig, aus dem heterogenen Datenbestand zunächst die Schlüsselinformationen in der erforderlichen Granularität darzustellen und in einem Informationsmodell abzubilden. Das hybride Informationsmanagementsystem besteht zum einen aus der ressourcenbasierten Komponente zur Verwaltung der Informationen mittels Internettechnologien. In der zweiten, modellbasierten Komponente des Systems wird insbesondere das schnelle Auffinden der für Entscheidungsprozesse notwendigen Informationen sowie deren Transparenz unterstützt, sowie Redundanzen aufgezeigt und die Konsistenz der Information gesichert. Von den implementierten Werkzeugen ist der Grafische Navigator hervorzuheben, weil dadurch der Bedarf in der Praxis gedeckt wird, gerade in Ausnahmesituationen ein Gesamtprojekt übersichtlich darzustellen und eine direkte visuell gestützte Verknüpfung mit den Schlüsselinformationen zu ermöglichen. Die erste Praxiserprobung von Teilen des Informationsmanagementsystems belegte dessen prinzipielle Einsetzbarkeit und hohe Akzeptanz bei den Projektbeteiligten. Es zeigte sich, dass weitere Funktionalitäten, wie z.B. die direkte Einbindung von Elementen des Monitorings, nachgefragt werden. Diese und andere Erweiterungen sowie weitergehende Erprobungen des vollständigen Systems in der Spezialtiefbaupraxis sind Gegenstand nachfolgender Forschungsarbeiten, woraus sich abschließend ein praxistaugliches Produkt ergeben soll. An dieser Stelle sei allen Beteiligten aus der Baupraxis, die zum Gelingen der Forschungsarbeiten einen Anteil geleistet haben, gedankt. Hervorzuheben sind die beiden Kooperationspartner Keller Grundbau GmbH und Züblin Spezialtiefbau GmbH, Niederlassung Nord, Berlin. Letzterer gilt besonderer Dank für die engagierte Beteiligung und Unterstützung bei der ersten Praxiserprobung.

Literatur Björk BC (2003) Electronic Document Management in Construction – Research Issues and Results. In: Electronic Journal of Information Technology in Construction 8:105–117 (http://www.itcon.org/2003/9) Brüggemann BM (2006) Informationsmodellierung im Bauwesen. Publications of the Institute für Bauinformatik, BTU Cottbus (in Druck), Zugl.: Cottbus, BTU, Habil., 2006

74

Klaus-Peter Holz, Stavros Savidis, Frank Schley, Frank Rackwitz, Marcus Mejstrik

Froese T, Yu K, Liston K, Fischer M (2000) System Architectures for AEC Interoperability. In: Gudnason (ed) Proceedings of Construction Information Technology 2000, vol 1 Icelandic Building Research Institute, Reykjavik, pp 362–373 Gossow V (1998) Baubetriebspraxis – Leitfaden für die Bauausführung. Springer, Berlin Heidelberg New York, S 35ff Hildebrandt G (2006) A Service Oriented, Collaborative Working Environment for the Support of Modeling Processes in Distributed Civil- and Hydro-Engineering Projects. Publications of the Institute für Bauinformatik, BTU Cottbus (in Druck), Zugl.: Cottbus, BTU, Diss., 2006 International Alliance for Interoperability (IAI) (2004) IFC/ifcXML Specifications (http://www.iai-international.org/Model/IFC(ifcXML)Specs.html) (Stand: 02.02.2006) Jung Y, Chin S, Kim K (2004) Informatization Index for the Construction Industry. In: ASCE, Journal of Computing in Civil Engineering 18(3):267–276 Nicklisch F, Weick G (2001) VOB Verdingungsordnung für Bauleistungen Teil B. Beck, München Schley F, Mejstrik M, Holz KP, Savidis SA (2004) Network Based Co-operation Platform for Geotechnical Engineering. In: Beucke K et al. (eds) Xth International Conference on Computing in Civil and Building Engineering, Weimar Schley F, Brüggemann BM, Holz KP, Rackwitz F, Savidis SA (2006) Multilevel Information Management between diverse Domain Models in Geotechnical Engineering. In: Rivard H, Miresco E, Melhem H (eds) Proceedings of the Joint International Conference on Computing and Decision Making in Civil and Building Engineering, Montreal Spiegl M, Schneider E (2001) Ein alternatives Modellkonzept für Risikoverteilung und Vergütungsregelung bei BOT Modellen mit großem Baugrundrisiko. In: Bauingenieur 76:404–409 Sulankivi K (2004) Benefits of Centralized Digital Information Management in Multipartner Projects. In: Electronic Journal of Information Technology in Construction 9:35– 63 (http://www.itcon.org/2004/3) Tse TK, Wong KA, Wong KF (2005) The Utilization of Building Information Models in nD Modelling: A Study of Data Interfacing and Adoption Barriers. In: Electronic Journal of Information Technology in Construction 10:85–110 (http://www.itcon.org/2005/8)

4 Prozessorientierte Vernetzung von Ingenieurplanungen am Beispiel der Geotechnik

Rolf Katzenbach, Johannes Giere Technische Universität Darmstadt, Institut für Geotechnik {katzenbach | giere}@geotechnik.tu-darmstadt.de

Uwe Rüppel, Armin Wagenknecht, Steffen Greb Technische Universität Darmstadt, Institut für Numerische Methoden und Informatik im Bauwesen {rueppel | wagenknecht | greb}@iib.tu-darmstadt.de

4.1 Einleitung Motivation Die Ingenieurplanung, insbesondere die Planung von geotechnischen Konstruktionen, ist geprägt durch fall- und projektbezogene Arbeitsteilung zwischen Fachplanern und durch eine komplexe Interaktion der Planungsprozesse, die mit den derzeit zur Verfügung stehenden Managementsystemen in vielen Fällen koordinativ nur schwer beherrschbar ist. Mangels der Verfügbarkeit adäquater Systeme zur Koordination der Planungsprozesse kommt es nicht selten zu sicherheits-, qualitäts-, kosten- und terminrelevanten Problemen in der Projektrealisierung. Ziel Ziel des Forschungsprojektes war die Entwicklung einer neuen Kooperationsumgebung zur prozessorientierten Vernetzung von Fachplanungen im Konstruktiven Ingenieurbau in einer heterogenen Rechnerumgebung am Beispiel der Geotechnik. Dieses neu entwickelte System wird als Kooperationsmodell Geotechnik bezeichnet, bei dem die Interaktion zwischen den in lokalen Prozess-Domänen agierenden Fachplanern durch ein globales Prozess-Managementsystem in Verbindung mit

76

Rolf Katzenbach, Uwe Rüppel, Armin Wagenknecht, Johannes Giere, Steffen Greb

der netzwerkgerechten Strukturierung der auszutauschenden Informationen und Verarbeitungsmethoden gesteuert wird. Der iterative Planungsprozess soll durch die vernetzte Kooperation im prozessoptimierten Kooperationsmodell effizienter, kostengünstiger und weniger fehlerempfindlich gestaltet werden. Lösungsansatz Der Ansatz zur Koordination der geotechnischen Planungsprozesse im Computernetz basiert auf der Prozessmodellierung und Laufzeitsteuerung der Prozesse mit Petri-Netzen in Verbindung mit der Auswertung von Metainformationen zur prozessspezifischen Charakterisierung der Produktmodellinformationen. Der methodische Lösungsansatz ist das Kooperationsmodell Geotechnik, das aus den Elementen lokale Prozess-Domänen, Informationspakete, globales Prozess-Managementsystem und bidirektionalen Adaptoren besteht. Abbildung 4.1 stellt den Systementwurf des Kooperationsmodells dar (Katzenbach et al. 2002). Die lokalen Prozess-Domänen (LPD) unterstützen den jeweiligen Fachplaner durch das Abbilden fachspezifischer Prozesse und das Einbinden fachspezifischer Anwendungen. Durch die Ausbildung geeigneter fachspezifischer Adaptoren werden die einzelnen lokalen Prozess-Domänen in den Kommunikationsverbund integriert. Ein weiteres Element des Kooperationsmodells Geotechnik bilden die Informationspakete, dargestellt durch die Symbole in den Informationskanälen (siehe Abb. 4.1). Die Informationspakete bestehen aus zwei Teilen: Zum einen aus den atomaren Fachinformationseinheiten, in denen die fachlichen Produktinformationen (z.B. Geometrie, Statik, Kosten) enthalten sind, und zum anderen aus den Metainformationen, welche die prozessspezifischen Informationen beschreiben und damit für die dynamische Steuerung der Planungsprozesse wesentlich sind.

Globales Prozessmanagement-System

Lokale Prozessdomäne

Informationspaket

Abb. 4.1. Struktur des Kooperationsmodells Geotechnik

Prozessorientierte Vernetzung von Ingenieurplanungen

77

Im Zentrum des Kooperationsmodells steht das globale Prozess-ManagementSystem (GPMS). Es ermöglicht die dynamische Steuerung der Planungsprozesse basierend auf der Bewertung der im Computernetzwerk zwischen den Planungsbeteiligten auszutauschenden Informationen. Diese Steuerungseinheit ist zentrales Element der Kooperationsplattform, die Konzepte aus dem Prozessmanagement, innovative Internet- und Kommunikationstechnologien sowie die Bewertung der prozessspezifischen Informationen des Konstruktiven Ingenieurbaus vereint. Software-Methoden Als Methode zur Prozessbeschreibung bzw. -modellierung (vgl. Kooperationsmatrix Abb. I.1.1) wurden die Petri-Netze mit individuellen Marken verwendet. PetriNetze basieren auf der Graphentheorie und besitzen sowohl eine grafische Repräsentation als auch einen mathematischen Formalismus zur Beschreibung, Analyse und Simulation von Prozessen (Murata 1989; Baumgarten 1990). Insbesondere ermöglicht das Konzept der individuellen Marken (Jensen 1996) die unmittelbare Repräsentation und Auswertung von prozessrelevanten Informationen im Prozessmodell. Die netzwerkgerechte Strukturierung der auszutauschenden Informationen in reine Produktmodellinformationen und prozessrelevante Metainformationen erfolgt auf der Basis der eXtensible Markup Language (XML). Darüber hinaus erfolgt die interne Repräsentation des Petri-Netz-basierten Prozessmodells auf der Basis des XML-Standards im Format der Petri Net Markup Language (PNML). Folglich wurde der XML-Standard zur Integration der Informationen aus Produktund Prozessmodell genutzt (vgl. Kooperationsmatrix Abb. I.1.1). Als informationstechnologische Methoden zur Umsetzung der internetbasierten Kooperationsumgebung werden für den Informationsaustausch zwischen den Planungsbeteiligten WebServices in Verbindung mit dem SOAP/XML-Standard verwendet. Die persistente Datenhaltung der Petri-Netz-basierten Prozessmodelle erfolgt in der nativen XML-Datenbank Xindice.

4.2 Ergebnis- und Erkenntnisbeiträge des Projektes zu den Gesamtzielen des SPP und zu den Zielen der Arbeitsgruppe Das Forschungsprojekt „Prozessorientierte Vernetzung von Ingenieurplanungen am Beispiel der Geotechnik“ leistete zu den Zielen der Arbeitsgruppe „Netzwerkgerechte Prozessmodellierung“ im Rahmen der Gesamtziele des Schwerpunktprogramms folgende Ergebnis- und Erkenntnisbeiträge: 1. Analyse von Planungsprozessen Für die Analyse der Bauplanungsprozesse wurden drei methodisch verschiedene Ansätze gewählt, die als bauteilorientierte, anwendungsorientierte und normbasierte Analyse bezeichnet werden und in Abschnitt 4.3 vorgestellt werden.

78

Rolf Katzenbach, Uwe Rüppel, Armin Wagenknecht, Johannes Giere, Steffen Greb

2. Formale Beschreibung der Planungsprozesse Zunächst wurde eine Analyse und Bewertung von Modellierungsmethoden vor dem Hintergrund der Anforderungen aus der Prozessanalyse durchgeführt. Die Petri-Netze wurden als geeignete formale Prozessmodellierungsmethode gewählt und werden in Abschnitt 4.4.2 in den Phasen Prozessmodellierung, -analyse und -steuerung vorgestellt. Insbesondere wurde das Konzept der individuellen Marken zur Repräsentation prozessrelevanter Metainformationen unmittelbar im Prozessmodell entwickelt. 3. Entwicklung einer vernetzten Kooperationsumgebung Auf der Basis des Kooperationsmodells Geotechnik und der Petri-Netzbasierten Prozessmodellierung wurde eine vernetzte Kooperationsumgebung implementiert. Dabei erfolgt die Koordination des Informationsaustausches zwischen den Planungsbeteiligten und die Bereitstellung verteilter Dienste über die zentrale Steuerungskomponente der Kooperationsumgebung. Hierzu werden die auszutauschenden Informationen mit XML strukturiert und als SOA–Pakete auf der Basis von WebServices versendet. Die Kooperationsumgebung entspricht dem Paradigma einer dienst-orientierten Architektur (engl. Service-Oriented Architecture (SOA)). Verknüpfung mit anderen Forschungsvorhaben des SPP Zwischen diesem Projekt und den Forschungsprojekten „Relationale Prozessmodellierung in kooperativer Gebäudeplanung“ sowie „Berücksichtigung von Ausnahmefällen bei der kooperativen Bearbeitung von Projekten des konstruktiven Tiefbaus“ konnten gemeinsame wissenschaftliche Erkenntnisse und Synergieeffekte realisiert werden. Mit ersterem wurde auf dem Gebiet der formalen Prozessmodellierung und im Speziellen in der Nutzung bipartiter gerichteter Graphen bzw. Petri-Netzen zur Abbildung von Planungsprozessen zusammengearbeitet (Berkhahn et al. 2005). Die Kooperation mit dem zweiten Projekt fokussierte die gemeinsame fachliche Ausrichtung auf die Geotechnik, insbesondere auf die semantische Interpretation prozessrelevanter Daten im Prozessmodell (Katzenbach et al. 2004).

4.3 Prozessanalyse Mit der Analyse der Planungsprozesse im Konstruktiven Ingenieurbau am Beispiel der Geotechnik wurden die grundlegenden Anforderungen identifiziert, die der Realisierung des Kooperationsmodells Geotechnik zugrunde gelegt werden. Für eine umfassende Analyse mussten dazu Informationen aus unstrukturierten und semi-strukturierten Dokumenten eines Referenzprojektes, aus eingesetzten Fachanwendungen der Geotechnik und Regelwerken sowie Normen untersucht und z. T. aufbereitet werden. Darauf aufbauend wurden drei methodisch unterschiedliche Analysen durchgeführt, die im Folgenden kurz vorgestellt werden.

Prozessorientierte Vernetzung von Ingenieurplanungen

79

4.3.1 Bauteilorientierte Analyse von Planungsprozessen Anhand des Bauprojektes Gallileo, einem Hochhaus der Dresdner Bank mit 38 Stockwerken und 30.000 Quadratmetern Bürofläche sowie einem Bauvolumen von 190 Mio. Euro wurde eine bauteilorientierte Analyse der Planungsprozesse durchgeführt. Bei der Durchführung des Gallileo-Bauprojektes wurde ein zentraler Datenserver verwendet, auf dem alle Planungsdokumente abgelegt wurden und zu dem für alle Berechtigten ein internetbasierter Zugang eingerichtet war. Die bauteilorientierte Analyse fokussierte sich auf die an spezifischen Bauteilen durchgeführten Planungsschritte im gesamten Planungsprozess und ermöglichte die Erfassung aller Planungsbeteiligten, der zugehörigen Planungsschritte sowie der Interaktion der Planungsbeteiligten auf Dokumentenbasis. Die Analyse wurde methodisch wie folgt strukturiert:

x x x x

Analyse der Planungszustände Analyse der Tätigkeiten der Planungsbeteiligten Analyse der ausgetauschten Informationen Analyse der vorgenommenen Kommunikationen

Der Schwerpunkt der bauteilorientierten Analyse wurde auf die Planung der Gründung des Bauprojektes gelegt. Sie besteht aus einer kombinierten PfahlPlattengründung (KPP), bei der sowohl die Gründungsplatte als auch die Pfähle zum Lastabtrag herangezogen werden (Katzenbach et al. 2001; Poulos et al. 2001). Die KPP wird messtechnisch überwacht (siehe dazu Abb. 4.2).

überschnittene Bohrpfahlwand Gründungspfähle Rand / Kern Gründungspfähle als Bestandteil des Verbaus

Grundriss aufgehende Konstruktion

Messinstrumentierung (Sohldruckgeber, Porenwasserdruckgeber, Inklinometer)

Abb. 4.2. Schnitt durch das Hochhaus Gallileo und Grundriss der Gründungsplatte

80

Rolf Katzenbach, Uwe Rüppel, Armin Wagenknecht, Johannes Giere, Steffen Greb

Zusätzlich wurden die Gründungspfähle als Energiepfähle zur thermischen Bewirtschaftung des Gebäudes mit einem saisonalen Thermospeicher ausgebildet (Ennigkeit u. Katzenbach 2000). Die Konzentration auf die Gründungskonstruktion erfolgte aus zwei Gründen:

x Erstens stellt die Planung der Gründung eines Bauwerks für den Baugrundsachverständigen eine zentrale Planungsleistung dar und ist insbesondere aufgrund der statischen Interaktion mit der aufgehenden Konstruktion bei Änderungen des Entwurfs häufig iterativ in den Planungsprozess miteingebunden. x Zweitens wurde im Bauprojekt Gallileo die Gründung einer mehrfachen Umplanung unterzogen, die von unterschiedlichen Planungsbeteiligten initiiert wurde. Anhand der Umplanungen konnten die komplexen Wechselwirkungen und Interaktionen zwischen den Planungsbeteiligten studiert werden. 4.3.2 Anwendungsorientierte Analyse von Planungsprozessen Der anwendungsorientierten Analyse der Planungsprozesse in der Geotechnik liegt die Idee zugrunde, auf Grundlage der Eingangs- und Ausgangsparameter typischer Fachanwendungen zur Dimensionierung einer Verbauwand die Interaktionen und die Kommunikation zwischen den Planungsbeteiligten aufzuzeigen. Die Fachanwendungen werden dabei in unterschiedlichen Phasen des Planungsprozesses eingesetzt und repräsentieren somit verschiedene Planungszustände. Als Modellierungsmethode wurde die Unified Modeling Language (UML) (Oestereich 1998) verwendet und insbesondere die zur Beschreibung von Prozessen bevorzugten Diagrammtypen: Anwendungsfalldiagramm, Interaktionsdiagramm und Aktivitätsdiagramm. 4.3.3 Normbasierte Analyse von Planungsprozessen Darüber hinaus wurden zur Analyse von Planungsprozessen geotechnische Normen und technische Regelwerke mit dem Ziel analysiert, prozessrelevante Informationen aus diesen Werken abzuleiten (Rüppel et al. 2004 c). Das in diesen Normen kodierte Prozesswissen wurde abstrahiert und in einem ersten Schritt mit Ereignisgesteuerten Prozessketten (EPKs) modelliert. Am Beispiel der DIN 4020 "Geotechnische Untersuchungen für bautechnische Zwecke", und der Hessischen Bauordnung (HBO) wurden Prozessmodelle auf der Basis der EPKs im Software-Werkzeug ARIS-Toolset entwickelt. Im Dialog mit Ingenieuren, die über langjährige Berufserfahrung in den Fachdomänen Geotechnik und Tragswerksplanung verfügen, wurden diese Prozessmodelle weiterentwickelt. Aufgrund der Einbindung der Fachingenieure in die Modellierung bot sich die Nutzung von EPKs als leicht verständliche aber lediglich semi-formale grafische Modellierungsmethode an. Daraufhin wurden die EPK-basierten Prozessmodelle in einem zweiten Schritt auf der Basis der formalen Transformationsvorschriften von (Aalst 1998 b) in Petri-Netze überführt.

Prozessorientierte Vernetzung von Ingenieurplanungen

81

4.4 Formale Beschreibung von Planungsprozessen Die formale Beschreibung der Planungsprozesse war ein wesentliches Ziel des Forschungsprojekts. Die formale Prozessmodellierung ermöglicht eine ganzheitliche und in Bezug auf die Syntax und die Semantik eindeutige Abbildung der realen Planungsprozesse. Gerade für die rechnergestützte Abbildung und Steuerung der komplexen Planungsprozesse ist eine geeignete formale Modellierungsmethode wesentlich. Diese wurde auf Basis eines entwickelten Anforderungskatalogs, der sich aus den Charakteristika der Bauplanungsprozesse ableiten lässt, ausgewählt. Hierauf wird in den nachfolgenden Abschnitten genauer eingegangen. 4.4.1 Analyse von Methoden zur Prozessmodellierung Als mögliche Methoden zur Prozessmodellierung wurden erstens die im Zuge der objektorientierten Modellierung weit verbreitete Unified Modeling Language (UML) zur Beschreibung von Software-Entwicklungsprozessen, zweitens die in der Baupraxis verwendete Netzplantechnik (Seeling 1996) und drittens PetriNetze (Abel 1990; Baumgarten 1990; Diestel 1996; Jensen 1996; Oberweis 1996; Aalst 1998 a; Desel 1998) untersucht und analytisch gegenübergestellt. Abbildung 4.3 stellt die Charakteristika geotechnischer Planungsprozesse und die daraus abgeleiteten Anforderungen an die Prozessmodellierung einer Bewertung der genannten Modellierungsmethoden gegenüber. Zur Modellierung und Steuerung der Prozesse wurden Petri-Netze mit ihren mathematischen Grundlagen und ihren Spezialisierungen und Erweiterungen hinsichtlich der Datenkonzepte, der Zeitaspekte und der Hierarchiebildung aufgrund der oben genannten Anforderungen als Basis für die Prozessmodellierung und -steuerung gewählt. Anforderungen Konsistenz

Netzpläne

UML

Petri-Netze

+

-

+

+

+

+

-/+

-/+

+

Kontrolle, Steuerung, Simulation

-

-

+

Dynamische Abhängigkeiten

-

-

-/+

Detaillierungsmöglichkeiten Sequenz, Iteration, Nebenläufigkeit

Abb. 4.3. Bewertung der Modellierungsmethoden

4.4.2 Petri-Netze zur Prozessmodellierung Petri-Netze sind eine formale Methode zur Beschreibung, Analyse und Simulation dynamischer Systeme mit nebenläufigen Vorgängen. Petri-Netze sind bipartite gerichtete Graphen, die um das Markenkonzept zur Darstellung von Zuständen er-

82

Rolf Katzenbach, Uwe Rüppel, Armin Wagenknecht, Johannes Giere, Steffen Greb

weitert sind. Sie bieten sowohl eine grafische Repräsentation als auch einen mathematischen Formalismus zur Beschreibung verteilter und asynchroner Prozesse eines diskreten Systems. Dabei ermöglicht der Einsatz der sog. Marken die Modellierung dynamischer Aspekte (Baumgarten 1990). Insbesondere Petri-Netze mit individuellen Marken (höhere Petri-Netze bzw. farbige Petri-Netze, Jensen 1996) ermöglichen die Assoziation zusätzlicher Informationen mit den Marken (siehe Abb. 4.4). Ende der 90er Jahre haben van der Aalst (Aalst 1998 a, 1998 b; Verbeek 2001) und Oberweis (Oberweis 1996, 1997) die Anwendung der Petri-Netze im Bereich der Prozessmodellierung und des Workflow-Managements erstmalig eingeführt.

Abb. 4.4. Grundstruktur eines Petri-Netz-basierten Prozessmodells

Die formale Beschreibung eines Prozesses auf der Basis eines Stellen- bzw. Transitionsnetzes erfolgt durch folgende Mengen und Relationen:

x x x x x

Stellen S Transitionen T Flussrelationen A : ( S u T ) ‰ ( T u S ) Kantengewicht W : A o 1 Anfangsmarkierung M0 : S o 10,  s  S : M0 (s)

Aufgrund dieser Informationen lässt sich die Markierungsgleichung

Mi

M 0i  N ij K j

(4.1)

aufstellen. Hierin sind x Mi der Markierungsvektor, der für jede Stelle si die aktuelle Markierung angibt, x M 0 i der Anfangsmarkierungsvektor, der für jede Stelle si zum Ausgangszeitpunkt der Simulation die Anzahl der Marken angibt, x Kj der Vektor der Schaltungen, der für jede Transition tj angibt, wie oft sie geschaltet wurde, x Nij die Inzidenzmatrix, die eine mathematische Repräsentation des Petri-Netzes darstellt, wobei gilt:

Prozessorientierte Vernetzung von Ingenieurplanungen

­ W ( si , t j ) wenn ( s i , t j )  F ° N ij ®W (t j , s i ) wenn (t j , s i )  F ° 0 sonst ¯

83

(4.2)

Die Markierungen der Systemzustände und die Markierungsgleichung stellt die Grundlage für die Analyse der modellierten Abläufe dar. Ebenso ist sie die Grundlage für die Laufzeitsteuerung, da aufgrund der aktuellen Markierung die möglichen Schaltungen der nachfolgenden Transitionen bestimmt werden (Baumgarten 1990; Desel 1998). 4.4.3 Modellierung und Analyse von Bauprozessen auf der Basis von Petri-Netzen Die Bauprozesse zeichnen sich durch ein hohes Maß an Verteiltheit, Heterogenität, Dynamik und Komplexität aus. Die Beherrschung der Bauprozesse erfordert daher geeignete Modelle und Methoden. Nachfolgend werden die Anwendung und die Weiterentwicklung der Petri-Netze zur Abbildung, Analyse und Steuerung von Bauprozessen aufgezeigt. Abbildung von Zuständen, Aktivitäten, Ressourcen und Ereignissen Für die Abbildung von Planungsprozessen ist es wesentlich, neben den Aktivitäten auch Zustände, Ereignisse und Ressourcen zu erfassen. Um eine konsistente Prozessmodellierung zu unterstützen, müssen diese Elemente in einem Modell erfasst werden. Mit Petri-Netzen können Planungsaktivitäten durch Transitionen und Planungszustände durch Stellen abgebildet werden. Die Flussrelationen stellen Beziehungen zwischen Planungszuständen und Planungsvorgängen her. Die Marken schließlich repräsentieren Planungsressourcen (insbesondere Planungsinformationen) (siehe Tabelle 4.1). Auf der Basis dieser Modellierungselemente ist es möglich, Bedingungen und logische Aussagen zu modellieren und somit Ereignisse abzubilden (Rüppel u. Greb 2002). Tabelle 4.1. Abbildung von Planungsprozessen mit Elementen der Petri-Netze Planungsprozess Planungszustände Planungsaktivitäten Abhängigkeiten Informationen, Objekte

Repräsentation im Petri-Netz Stellen S Transitionen T Flussrelationen F Marken M

Grafische Darstellung

Konsistente Prozessmodellierung Im Kontext der Prozessmodellierung wird grundsätzlich zwischen der Modellierungsphase und der Ausführungsphase unterschieden (Rump 1999). Die Modellierungsphase umfasst die Beschreibung der realen Prozesse in einem Prozessmodell und die Analyse dieses Prozessmodells, während die Ausführungsphase die com-

84

Rolf Katzenbach, Uwe Rüppel, Armin Wagenknecht, Johannes Giere, Steffen Greb

putergestützte Steuerung der realen Prozesse umfasst. Häufig werden in diesen Phasen verschiedene Modelle verwendet, so dass es beim Phasenübergang zu inkonsistenten Modellzuständen kommen kann. Gerade im Bauwesen kommt es häufig vor, dass zum Zeitpunkt der Ausführung aufgrund bestimmter Planungsentscheidungen Veränderungen am Prozessmodell vorgenommen werden müssen. Daher ist es besonders wichtig, die Konsistenz des Prozessmodells über diese Phasen hinweg sicherzustellen. Die Petri-Netze sind eine formale Methode die sowohl zur Modellierung und Analyse als auch zur Laufzeitsteuerung genutzt werden kann und somit die Konsistenz unterstützt. Individuelle Marken zur Repräsentation prozessrelevanter Metainformationen Bei der Modellierung von Bauprozessen müssen Produktmodellinformationen, die für den Prozessablauf relevant sind, berücksichtigt werden. Eine Verzahnung von Prozessmodell und Produktmodell auf der Basis prozessrelevanter Informationen ist daher für die fallspezifische Koordination der Kommunikation zwischen den Planungsbeteiligten wesentlich. Das Konzept der individuellen Marken ermöglicht es, eine Verbindung zwischen dem Prozessmodell und dem Produktmodell herzustellen und stellt die Semantik zur Prozesssteuerung dar (vgl. Kooperationsmatrix Abb. I.1.1). Hierbei werden die Marken des Prozessmodells mit Informationen aus dem Produktmodell assoziiert (siehe Abb. 4.5). Diese Informationen können dann im Prozessmodell zum Beispiel an Entscheidungsknoten ausgewertet werden und den Prozessablauf steuern (Rüppel et al. 2004 b; Katzenbach u. Giere 2005).

Abstraktion prozessrelevanter Informationen

Produktmodell

Repräsentation als individuelle Marke

Prozessrelevante Metainformation

Prozessmodell

Abb. 4.5. Verbindung zwischen Prozess- und Produktmodell auf der Basis prozessrelevanter Metainformationen

Formale Prozessanalyse Ziel der formalen Prozessanalyse ist es, ein Verständnis für die ablaufenden Prozesse zu entwickeln, ausgewählte Kennzahlen für die Prozesse zu ermitteln und insbesondere die modellierten Prozesse auf „formale Richtigkeit“ zu überprüfen. Die Überprüfung der Prozessstruktur und der dynamischen Prozesseigenschaften ist gerade für die im Bauwesen verteilten und komplexen Prozessmodelle wesentlich. Für Petri-Netz-basierte Prozessmodelle können folgende ausgewählte Analysen durchgeführt werden: Die strukturelle Analyse, bei der das Prozessmodell aufgrund der den meisten Modellierungsmethoden zugrunde liegenden Struktur in Form eines gerichteten

Prozessorientierte Vernetzung von Ingenieurplanungen

85

Graphen analysiert wird. Durch Anwendung graphentheoretischer Algorithmen können so beispielsweise Zyklen, der Zusammenhang oder Netzeigenschaften der Prozessstruktur, wie zum Beispiel eindeutige Start- und Endknoten eines Netzes, ermittelt werden (Aalst 1998 a; Pahl u. Damrath 2000; Domschke u. Drexl 2002). Die dynamische Analyse (Erreichbarkeitsanalyse) ermöglicht neben der statischen Analyse der Struktur auch die dynamische Analyse des Verhaltens des Petri-Netz-basierten Prozessmodells. Sie beruht auf der bipartiten Graphenstruktur sowie dem Markenkonzept und ist insbesondere von der initialen Markierung des Netzes abhängig. Wesentliche dynamische Eigenschaften im Kontext der PetriNetz-basierten Prozessmodellierung sind die Lebendigkeit, Beschränktheit und Verklemmungsfreiheit (Aalst 1998 a, 2001; Baumgarten 1990). V.d. Aalst definiert mit dem Soundness-Kriterium (Aalst 1998 a) weitere dynamische Anforderungen, die Petri-Netze zur richtigen Beschreibung von Prozessabläufen erfüllen müssen. Durch das Soundness-Kriterium wird der korrekte Markenfluss im Netz unter drei Aspekten geprüft, die nachfolgend genannt und formal beschrieben sind:

x „Möglichkeit der Terminierung“ (4.3)

* * M : (i  o M ) Ÿ ( M  o o)

x „Saubere Terminierung“ * M : ( M i  o M š M t M t M 0 ) Ÿ (M

M0)

(4.4)

x „Keine tote Transition“ * t t  T : M , M ' : (i  o M  o M ')

(4.5)

Hierin sind:

x M eine beliebige Markierung des Petri-Netzes x i die Anfangsmarkierung des Petri-Netzes mit genau einer Marke in der Ausgangsstelle

x o die Endmarkierung des Petri-Netzes mit genau einer Marke in der Endstelle x t eine beliebige Transition des Petri-Netzes Die Analyse-Methoden des Operations Research (OR) bezeichnen eine Vielzahl mathematischer Methoden zur Entscheidungsvorbereitung bzw. Entscheidungsunterstützung mit dem Ziel, durch die Vorgabe eines Optimierungskriteriums die bestmögliche Lösung zu finden. Die Netzplantechnik ist eine vor allem im Bauwesen weit verbreitete Methode des OR zur Struktur-, Zeit-, Kosten- und Kapazitätsplanung. Dabei unterscheidet man im Wesentlichen zwischen Vorgangsknoten- und Vorgangspfeilplänen. Im Bauwesen hat sich in den letzten Jahren die Metra Potential Method (MPM) als ein Vertreter der Vorgansknotenpläne etabliert (Seeling 1996; Domschke u. Drexl 2002).

86

Rolf Katzenbach, Uwe Rüppel, Armin Wagenknecht, Johannes Giere, Steffen Greb

Die analytische Prozesssimulation (vgl. Kooperationsmatrix Abb. I.1.1) ist eine für die Praxis besonders relevante Analysemethode, da sich viele praktische Problemstellungen nicht als geschlossen lösbares Formalproblem darstellen und lösen lassen. Simulation im Kontext des OR bedeutet das zielgerichtete Experimentieren an Modellen. Gegenüber anderen Analysemöglichkeiten bietet die Simulation den Vorteil, ohne tief greifende mathematische Kenntnisse durch das sukzessive „abarbeiten“ diskreter Systemzustände des Prozessmodells nutzerinteraktiv das Verständnis für die modellierten Prozesse zu fördern, Kennzahlen für die Prozesse zu ermitteln und die Richtigkeit der Prozesse festzustellen (Aalst 1998 a, 2001). Verteilte Modellierung Wesentlicher Aspekt der Prozessmodellierung im Bauwesen ist die Verteiltheit der ablaufenden Fachplanungen aufgrund der hohen Arbeitsteilung. Grundgedanke der „verteilten Prozessmodellierung“ ist daher, dass an zentraler Stelle nur eine grobe Modellierung des gesamten Planungsprozesses erfolgt. In verteilten Prozessmodellen werden durch einzelne am Planungsprozess beteiligte Fachplaner repräsentativ für ihre fachliche Domäne, wie beispielsweise Architektur, Tragwerksplanung und Geotechnik, die fachspezifischen Planungsaktivitäten, Planungszustände und Planungsinformationen erfasst. Die fachspezifischen Prozessmodelle werden unabhängig voneinander generiert und mithilfe definierter Schnittstellen und netzwerkgerechter Kommunikationsmechanismen auf der Basis von WebServices im groben Prozessmodell zusammengeführt. Die Verknüpfung des übergeordneten Prozessmodells und den fachspezifischen Prozessmodellen basiert auf den Ansätzen von Jensen (Jensen 1996) für hierarchische Petri-Netze und der Modellierung spezieller Stellen in den Petri-Netzen, sogenannter "Socket Places" und "Port Places" (Rüppel et al. 2004 a; Katzenbach et al. 2006). Modellierung von Prozessmustern für Bauprozesse Die grundsätzliche Idee der Prozessmuster besteht darin, bestimmte, immer wiederkehrende Planungsabläufe einmalig zu modellieren und diese Prozessmodelle für die Nutzung in vielfältigen Bauprojekten bereitzuhalten. Diese Prozessmuster können beispielsweise aufgrund bauteilspezifischer, planungsspezifischer oder baurechtlicher Rahmenbedingungen entwickelt werden (Rüppel et al. 2003; Katzenbach u. Giere 2003). Bei nachfolgenden Bauprojekten können bei ähnlichen Rahmenbedingungen auf bereits modellierte Prozesse zurückgegriffen und so Erfahrungen bei der Prozessmodellierung genutzt werden. Bei bauteilspezifischen Prozessmustern handelt es sich um Prozessmodelle, die mit einem bestimmten konstruktiven Entwurf assoziiert werden. So sind beispielsweise für eine überschnittene rückverankerte Bohrpfahlwand bestimmte Planungsleistungen zu erbringen, in die bestimmte Planungsbeteiligte einbezogen werden müssen (Katzenbach u. Giere 2003). Unter planungsspezifischen Prozessmustern lassen sich eine Vielzahl von speziellen Rahmenbedingungen eines Bauprojekts, die auf ein anderes Bauprojekt, das unter den gleichen speziellen Rahmenbedingungen zu erstellen ist, zusammenfas-

Prozessorientierte Vernetzung von Ingenieurplanungen

87

sen. Beispielsweise ergibt sich für den Entwurf und die Dimensionierung einer Baugrube bei anstehendem Grundwasser eine erweiterte Prozessstruktur im Vergleich zur Baugrube ohne die Randbedingung Grundwasser (Katzenbach u. Giere 2003). Ein weiteres Beispiel für planungsspezifische Prozessmuster ist die Planung einer Industriehalle für ein Chemiewerk. Hierbei ergeben sich aus der Randbedingung, dass umweltgefährdende Chemikalien gelagert werden müssen, für den Ingenieur beim konstruktiven Entwurf der Bodenplatte zusätzliche Planungserfordernisse und Absprachen mit anderen Planungsbeteiligten. Baurechtliche Prozessmuster tragen dem Sachverhalt Rechnung, dass die Genehmigungsverfahren in den einzelnen Bundesländern durch die jeweiligen Landesbauordnungen geregelt sind. Aus diesen Ordnungen ergeben sich bestimmte verfahrenstechnische Abläufe, die von Bundesland zu Bundesland verschieden sind. Auch hier kann das Vorhalten spezifischer Prozessmuster bei der Erstellung eines Prozessmodells hilfreich sein, indem bundeslandspezifisch auf bereits vorhandene Prozessmodelle zurückgegriffen wird und diese in ein übergeordnetes Prozessmodell integriert werden. Für die formale Modellierung dieser Prozessmuster gelten die gleichen Voraussetzungen wie für das gesamte Prozessmodell (Soundness, v.d. Aalst 1998 a). Prozessmuster können in einer Datenbank vorgehalten und dann durch Substitution in das übergeordnete Prozessmodell integriert werden (Katzenbach und Giere 2004).

4.5 Vernetzte Kooperationsumgebung ProMiSE Auf Grundlage des Systementwurfs des „Kooperationsmodells Geotechnik“ und im Hinblick auf die Anforderungen an die formale Prozessmodellierung im Bauwesen wurde die vernetzte Kooperationsumgebung ProMiSE prototypisch entwickelt (Rüppel et al. 2005). ProMiSE steht für Process Modelling in Structural Engineering und implementiert das Kooperationsmodell Geotechnik wie in Tabelle 4.2 dargestellt. Tabelle 4.2. Umsetzung des Kooperationsmodells Geotechnik in der verteilten Kooperationsumgebung ProMiSE Kooperationsmodell Geotechnik Referenzimplementierung Lokale Prozess-Domäne Geotechnik (LPD) Clientanwendungen, Spundix, GAPP, WebClient, XML-Modellierer, SOAP Client TAM Metainformationen XML/SOPA-basierte Informationen zur Prozesssteuerung auf der Basis von WebServices Globales Prozessmanagement-System Petri-Netz basierter, netzwerkgerechter Ser(GPMS) ver ProMiSE zur Prozessmodellierung, -analyse und -laufzeitsteuerung

88

Rolf Katzenbach, Uwe Rüppel, Armin Wagenknecht, Johannes Giere, Steffen Greb

Abbildung 4.6 stellt die ProMiSE-Systemarchitektur dar. Im Zentrum befindet sich der Petri-Netz-basierte Server ProMiSE mit Methoden zur Prozessmodellierung, -analyse und -steuerung. Er repräsentiert das globale ProzessManagement-System. Zur Interaktion mit Client-Anwendungen ist er mit netzwerkgerechten Kommunikationsmechanismen auf der Basis von WebServices ausgestattet. Darüber hinaus besitzt er für die persistente Datenhaltung von Prozessmodellen, insbesondere den Prozessmustern, Schnittstellen zu einem relationalen und einem XML Datenbankmanagement-System (DBMS). Die Client-Anwendungen repräsentieren die lokalen Prozess-Domänen und dienen zur Integration der verteilten Planungsbeteiligten in den Kommunikationsverbund. Diese Client-Anwendungen umfassen externe Prozessmodellierungswerkzeuge, geotechnische Fachanwendungen, browser-basierte Web-Anwendung mit Funktionalitäten in Anlehnung an ein Projektkommunikationssystem und Standard-Internet-Anwendungen wie beispielsweise eine E-Mail-Anwendung. E-Mail Anwendung

externes ProzessModellierungswerkzeug

WebAnwendung

Petri-Net Server ProMiSE J2EE Anwendungs-Server

relationales DBMS

geotechnische FachAnwendung

XML DBMS

Abb. 4.6. ProMiSE-Systemarchitektur

Die Informationspakete dienen zur Strukturierung der auszutauschenden Informationen. Sie nutzen Standard-Internet-Protokolle sowie den XML/SOAP Standard, um die Informationen in Produktmodell und prozessrelevante Metainformationen zu strukturieren und auf der Basis von WebServices auszutauschen. Nachfolgend wird die Prozessmodellierung, -analyse und -steuerung auf der Basis der entwickelten Kooperationsumgebung ProMiSE vorgestellt Modul zur Prozessmodellierung ProMiSE unterstützt die Modellierung von Bauplanungsprozessen gemäß der Petri-Netz Semantik, d.h. mit den Elementen Stellen, Transitionen, Kanten und Marken. Auf der Basis der Petri-Netze mit individuellen Marken ist eine unmittelbare Repräsentation prozessrelevanter Informationen im Prozessmodell möglich (Oberweis 1996). Darüber hinaus können Entscheidungsverzweigungen (XOR-Split) an bestimmte Bedingungen in Abhängigkeit von Produktmodelldaten geknüpft werden. Ebenso können Synchronisationspunkte (AND-Join) zur Zusammenführung

Prozessorientierte Vernetzung von Ingenieurplanungen

89

divergierender Planungsinformationen abgebildet werden. Abbildung 4.7 stellt die Modellierung eines Entscheidungsknotens mit ProMiSE dar.

Abb. 4.7. Modellierung von Petri-Netzen mit individuellen Marken

Modul zur Prozessanalyse Auf der Basis formaler Beschreibungen und Algorithmen in der Fachliteratur (Baumgarten 1990; Pahl u. Damrath 2000; Aalst 2001; Domschke u. Drexl 2002) wurden verschiedene Analysemöglichkeiten umgesetzt. Hierbei wurden sowohl eigene Implementierungsansätze verfolgt, als auch geeignete, frei verfügbare Java Archive eingebunden und erweitert (Bloom et al. 2003). Die für eine Prozessanalyse relevanten strukturellen Analysemöglichkeiten liefern beispielsweise Informationen über die zyklischen Eigenschaften des Netzes auf der Basis der transitiven Hülle, über den kürzesten Weg durch das Netz gemäß dem Dijkstra-Algorithmus, über die Wohlgeformtheit des Netzes oder testen ein Netz auf bestimmte Workflow-Eigenschaften. Das dynamische Verhalten eines Systems kann aufgrund der Erreichbarkeitsanalyse basierend auf dem Erreichbarkeits- bzw. Überdeckungsgraphen des Petri-Netzes ermittelt werden (Baumgarten 1990; Aalst 2001). Darüber hinaus wurde das von v. d. Aalst definierte Soundness-Kriterium realisiert, um weitere dynamische Anforderungen an das Prozessmodell zu verifizieren (siehe Abb. 4.8).

90

Rolf Katzenbach, Uwe Rüppel, Armin Wagenknecht, Johannes Giere, Steffen Greb

Abb. 4.8. Analyse von Planungsprozessen mit ProMiSE

Modul zur Prozesssteuerung In der verteilten Kooperationsumgebung dient der ProMiSE Server zur Koordination der Kommunikation zwischen den Planungsbeteiligten. Hierzu ist in diesem Modus die ProMiSE-Interaktion mit den Client-Anwendungen auf der Basis von Sockets/WebServices in Verbindung mit XML/SOAP-basierten Informationspaketen umgesetzt worden. Eingehende Informationen werden auf geeignete prozessrelevante Metainformation geprüft und im Netz als individuelle Marken repräsentiert. Durch die Auswertung dieser Marken, insbesondere an Entscheidungsknoten, können fallspezifisch unterschiedliche Prozesspfade eingeschlagen werden. Durch die Verknüpfung der im Prozessmodell hinterlegten Aktivitäten mit den Akteuren in den verschiedenen Prozessdomänen können so prozessspezifisch die Fachplanungen koordiniert werden. Abbildung 4.9 zeigt einen Entscheidungsknoten, der in Abhängigkeit von der geotechnischen Kategorie der Baumaßnahme unterschiedliche Prozesspfade einleitet. In dieser Abbildung modelliert die Transition t11 eine nutzerbasierte Planungsaktivität, bei der die prozessrelevante Metainformation bzgl. der geotechnischen Kategorie generiert wird. Die Transitionen t12, t13 und t14 sind automatisch ablaufende Transitionen, die mit einer Schaltbedingung versehen sind und die Metainformation der „geotechnischen Kategorie“ auswerten. In Abhängigkeit von der Metainformation schaltet eine dieser Transitionen t12, t13 oder t14 und leitet so prozessspezifisch die nachfolgenden Fachplanungen ein.

Prozessorientierte Vernetzung von Ingenieurplanungen

91

Abb. 4.9. ProMiSE im Laufzeitsteuerungsmodus

Die Client-Anwendung GAPP („Geotechnische Anwendung zur Produkt- und Prozessmodellierung“), die im Rahmen der Ausgestaltung der lokalen ProzessDomäne Geotechnik entwickelt wurde, stellt einen mit Qt (Grafikbibliothek von Trolltech) und OpenGL (offener Standard für die plattform- und programmiersprachenunabhängige 3D-Grafik-Entwicklung) implementierten grafischen Modellierer für dreidimensionale geotechnische Konstruktionselemente zur Verfügung. Mithilfe geeigneter Dialog-Boxen kann das geometrische Modell um prozessrelevante Metainformationen erweitert werden (siehe Abb. 4.10).

Abb. 4.10. Geometrische Modellierung und Definition prozessrelevanter Metainformationen

Ein weiterer Client stellt eine Web-Anwendung auf der Basis der Java-ServletAPI dar. Die Anwendung bietet insbesondere die Möglichkeit, beliebige Dateien

92

Rolf Katzenbach, Uwe Rüppel, Armin Wagenknecht, Johannes Giere, Steffen Greb

auf den Server aufzuspielen bzw. herunter zu laden und Metainformationen an den ProMiSE-Server zu senden.

4.6 Validierung am Anwendungsbeispiel: GallileoHochaus der Dresdner-Bank in Frankfurt/Main Zur Validierung der verteilten Kooperationsumgebung ProMiSE wurde diese exemplarisch im Rahmen der geotechnischen Planung für die Gründung des Gallileo-Hochhauses der Dresdner Bank in Frankfurt/Main eingesetzt. Der Einsatz von ProMiSE umfasste die Prozessmodellierung, -analyse und die Laufzeitsteuerung. Im Folgenden wird ein Szenario kurz skizziert. Zunächst wird ein grobes, vorstrukturiertes Netz modelliert, das die planerischen Aspekte des Konstruktiven Ingenieurbaus in Sinne der HOAI-Phasen grob beschreibt und als wieder verwendbares Prozessmuster vorgehalten werden kann. Die fachlichen Detailnetze können nachfolgend von den verantwortlichen Fachplanern erstellt und mit dem groben Planungsnetz assoziiert werden. Als Beispiel für ein solches Detailnetz dient die Vorplanung und Entwurfsplanung der Gründung und des Baugrubenverbaus des Gallileo-Hochhauses. Dieses Prozessnetz wurde in Anlehnung an die DIN 4020 sowie Ingenieurbefragungen entwickelt und ist in Abb. 4.11 dargestellt.

Abb. 4.11. Vor- und Entwurfsplanung sowie Einleitung der Genehmigungsplanung modelliert mit ProMiSE

Unter der Annahme, dass zum Zeitpunkt der „Kontrolle des Gründungsentwurfs durch den Bauherren“ die Planungsänderung auftritt, dass die Bohrpfähle der Gründung als Energiepfähle (zur Nutzung der Erdwärme für die Gebäudekühlung und -heizung) ausgeführt werden sollen, kann das Prozessmuster „Energiepfahl“ geladen und eingebunden werden (siehe Abb. 4.12).

Prozessorientierte Vernetzung von Ingenieurplanungen

A liefert Gebäudemodell

p3 Verteilen der Informationen

p1

t1

p2

t2

t3

p6

TGA ermittelt erf. Wärmestrom

p4

t5

p7

BGS erstellt Baugrundgutachten

p5

t14

t4

BGS entwirft saisonalen Thermospeicher Weiterleiten der p Informationen 10

t6

p9

t7

t8

TGA arbeitet Vor-

p12 und Rückläufe ein

U prüft therm. thermische Belastung Belastung ok des Bodens

p11

p8

T bemisst Pfähle auf therm. Belastung

t9

p16 t13

93

t10

Weiterleiten der Informationen

p14 t11

p15

p13

thermische Belastung nicht ok

p17

t12

Abb. 4.12. Simulation des Petri-Netzes zur Planung eines Energiepfahls

Dieses Prozessmuster wird vor dessen Einbindung analysiert, um mögliche Modellierungsfehler aufzudecken. Die strukturelle Prüfung durch ProMiSE akzeptiert das Prozessmuster, wohingegen die Soundness-Prüfung feststellt, dass das PetriNetz unbeschränkt ist und somit ein Modellierungsfehler vorliegt, der mittels einer nutzerinteraktiven Simulation vom Prozessanalysten lokalisiert und behoben werden kann. In der Simulation ist erkennbar, dass bei einer Planungsiteration aufgrund nicht zulässiger thermischer Belastung des Bodens (t12) die Zahl der Marken der Stelle (p12) unbeschränkt wachsen kann, da die Bemessung der Pfähle auf die Ergebnisse der thermischen Belastung zugreift. Beide Planungsaktivitäten müssen folglich, wie in Abbildung 4.8 dargestellt, synchronisiert werden. Die Laufzeitsteuerung wird anhand eines Szenarios, das die geotechnische Kategorie betrifft, dargestellt. Diese wird anhand der Belastung der Konstruktion, der Gründung, dem Baugrubenverbau sowie der Baugrund- und Grundwasserverhältnisse bestimmt. Das Planungsszenario setzt am Ende der Entwurfsplanung des Gründungsentwurfs nach Freigabe durch den Bauherrn ein (siehe Abb. 4.9). Dieser Zustand wird durch die Markierung der Stelle p13 dargestellt. Aufgrund der Petri-Netz-Logik kann die nachfolgende Planungsaktivität "Überprüfen der geotechnischen Kategorie“, modelliert durch die Transition t11, von ProMiSE ausgehend angestoßen werden. Beim Schalten dieser Transition wird der Baugrundsachverständige aufgrund der Beschreibung der Planungsaktivität und der Information der individuellen Marke fallspezifisch automatisiert per E-Mail benachrichtigt und beginnt mit der Überprüfung der geotechnischen Kategorie. Dazu zieht er das Baugrundgutachten heran und lässt sich den Gründungsentwurf als 3D-Modell im GAPP-Client visualisieren (siehe Abb. 4.10). Innerhalb dieses Clients spezifiziert der Baugrundsachverständige die geotechnische Kategorie (in diesem Fall Kategorie 3). Diese prozessrelevante Information wird in Form einer individuellen Marke an das Prozessmodell übermittelt, auf deren Basis die Transition t14 automatisch schaltet und die nachfolgende Fachplanung („Entwurf des geotechnischen Messprogramms“) eingeleitet werden kann.

94

Rolf Katzenbach, Uwe Rüppel, Armin Wagenknecht, Johannes Giere, Steffen Greb

4.7 Zusammenfassung Im Rahmen der Fachplanung von Projekten im Bauwesen ist ein hohes Maß an Kooperation zwischen den Planungsbeteiligten notwendig. Dies resultiert aus der fall- und projektbezogenen Arbeitsteilung zwischen den Planern, wobei der einzelne Fachplaner oft nicht in der Lage ist, die Auswirkung seiner Planungsentscheidungen in den Kontext der Gesamtplanung einordnen zu können, da ihm der vollständige Überblick über die Zusammenhänge der Planungsprozesse fehlt. Um die Koordination der vernetzten Zusammenarbeit von Architekten, Ingenieuren, Fachplanern, Behörden und Ausführenden in Computernetzen zu unterstützen, wurde eine neue netzwerkgerechte Kooperationsplattform am Beispiel der Geotechnik entwickelt. Diese ermöglicht eine prozessorientierte Vernetzung und Steuerung von Fachplanungen im Konstruktiven Ingenieurbau. Die Kooperationsumgebung basiert auf einer formalen Prozessmodellierung (höhere Petri-Netze) in Verbindung mit der Auswertung prozessrelevanter Fachinformationen, die zwischen den Planungsbeteiligten im Netzverbund ausgetauscht werden, wodurch eine ereignisbasierte Steuerung der Planungsprozesse erreicht wird. Des Weiteren bietet die Kooperationsumgebung durch den Einsatz von Prozessmustern und die Verwendung hierarchischer Petri-Netze eine verteilte Modellierung der Planungsprozesse sowie dynamische Modifikationen des Prozessmodells. Die netzwerkgerechte Kooperationsumgebung wurde in der Referenzimplementierung ProMiSE umgesetzt. Die Tragfähigkeit des Konzeptes wurde schließlich anhand der Modellierung, Analyse und Steuerung von Planungsprozessen des Gallileo-Hochhauses in Frankfurt am Main demonstriert. Die grundsätzliche Übertragbarkeit des vorgestellten Konzeptes ist aufgrund des modularen Aufbaus auf andere Fachdomänen gewährleistet.

4.8 Fazit Um eine konsistente Modellierung der hochkomplexen bauspezifischen Prozesse zu erreichen, hat es sich als notwendig herausgestellt, grundlegende mathematische Prozessmodelle zu erforschen und zu entwickeln, um die verschiedenen Aspekte der Kooperation – wie beispielsweise unterschiedliche Fachdomänen, Verwaltung der Arbeitsmodelle und -methoden, Aspekte der Gestaltung menschlicher Arbeit, Berücksichtigung moderner Kommunikationsmethoden und die Koordination der Planungsvorgänge – beherrschbar zu machen und in einer Prozesssteuerungsumgebung abzubilden. Es hat sich gezeigt, dass formale Methoden der Prozessmodellierung, wie zum Beispiel Petri-Netze, eine geeignete Grundlage darstellen. Allerdings besteht noch erheblicher Forschungs- und Entwicklungsbedarf, die formalen Methoden so ingenieurgerecht weiterzuentwickeln, dass sie in der Baupraxis Anwendung und breitere Akzeptanz finden können. Hierzu werden weitere Ergebnisse und Erkenntnisse in einem an diesem grundlagenorientierten Projekt anschließenden Transferprojekt mit Praxispartnern erarbeitet.

Prozessorientierte Vernetzung von Ingenieurplanungen

95

Literatur v.d. Aalst WMP (1998a) The Application of Petri Nets to Workflow Management. Journal of Circuits, Systems and Computers 8(1):21–66 v.d. Aalst WMP (1998b) Formalization and Verification of Event-driven Process Chains. Computing Science Reports 98/01, University of Technology Eindhoven v.d. Aalst WMP (2001) Diagnosing Workflow Processes using Woflan. The Computer Journal, 4/2001 Abel D (1990) Petri-Netze für Ingenieure. Springer, Berlin u.a. Baumgarten, B (1990) Petri-Netze – Grundlagen und Anwendungen. Spektrum Akademischer-Verlag Berkhahn V, Klinger A, Rüppel U, Meißner UF, Greb S, Wagenknecht A (2005) Process Modelling in Civil Engineering based on Hierarchical Petri Nets. In: Proc. 22nd Conference on Information Technology in Construction CIB-W78, Dresden Bloom J et al. (2003) Platform Independent Petri Net Editor – PIPE (http://petri-net.sourceforge.net) Desel J (1998) Petrinetze, lineare Algebra und lineare Programmierung. Teubner, Stuttgart Domschke W, Drexl A (2002) Einführung in Operations Research. Springer, Berlin Diestel R (1996) Graphentheorie. Springer, Berlin u.a. Ennigkeit A, Katzenbach R (2000) Saisonaler Thermospeicher mit Energiepfählen als Element innovativer, ressourcenschonender Gebäudetechniken. In: Beiträge zum 22. Darmstädter Massivbau-Seminar, Bd 22 Jensen K (1996) Coloured Petri Nets – Basic Concepts, Analysis Methods and Practical Use. Springer, Berlin Katzenbach R, Giere J (2003) Abstraktion von Prozessmustern im geotechnischen Planungsprozess. In: Gürlebeck K, Hempel L, Könke C (Hrsg) Digital Proceedings: Internationales Kolloquium über die Anwendungen der Informatik und der Mathematik in Architektur und Bauwesen (IKM), Weimar Katzenbach R, Giere J (2004) Coordinating Planning Processes in AEC using an Adaptable Process Model. In: Proc. of the Xth International Conference on Computing in Civil and Building Engineering ICCCBE, Weimar Katzenbach R, Giere J (2005) Supporting Geotechnical Design with Petri-Net-Based Process Patterns. In: Proc. 22th Conference on Information Technology in Construction CIB-W78, Dresden Katzenbach R, Kinzel J, El-Mossallamy Y, v. d. Hude N (2001) Besondere Aspekte bei der Gründung des Hochhauses Gallileo in Frankfurt am Main. In: Vorträge zum 8. Darmstädter Geotechnik-Kolloquium am 15. März 2002, Mitt. d. Instituts und der Versuchsanstalt für Geotechnik der Technischen Universität Darmstadt, Bd 56, S 3-20 Katzenbach R, Meißner UF, Rüppel U, Giere J, Greb S (2002) Process-Oriented Networked-Based Collaboration In Geotechnical Engineering. In: Proc. 9th International Conference on Computing in Civil and Building Engineering ICCBE, Department of Civil Engineering, National Taiwan University, Taipei, pp 1063–1068 Katzenbach R, Meissner UF, Rüppel U, Savidis S, Giere J, Greb S, Mejstrik M (2004) Abstraction of Process Relevant Information from Geotechnical Standards and Regulations. In: Proc. of the Xth International Conference on Computing in Civil and Building Engineering ICCCBE, Weimar Katzenbach R, Rüppel U, Meißner UF, Giere J, Wagenknecht A (2006) A Process-Oriented Cooperation Model for Distributed Civil Engineering Construction Works. In: Proc. of the Joint International Conference on Computing and Decision Making in Civil and Building Engineering, Montreal

96

Rolf Katzenbach, Uwe Rüppel, Armin Wagenknecht, Johannes Giere, Steffen Greb

Murata T (1989) Petri Nets: Properties, Analysis and Applications. In: Proc. of the IEEE 77, vol 4, New York, pp 541–580 Oberweis A (1996) Modellierung und Ausführung von Workflows mit Petri-Netzen. Teubner, Stuttgart Oberweis A, Schätzle R, Stucky W, Weitz W, Zimmermann G (1997) Der Einsatz von Petri-Netzen im INCOME/STAR- und INCOME/WF-Projekt. In: Stucky W (Hrsg) PetriNetze zur Modellierung verteilter DV-Systeme, Bericht des Instituts für Angewandte Informatik und Formale Beschreibungsverfahren der Universität Karlsruhe, Bd 350, 41:03, S 6–14 Oestereich B (1998) Objektorientierte Softwareentwicklung – Analyse und Design mit der Unified Modeling Language. Oldenbourg, München Pahl PJ, Damrath R (2000) Mathematische Grundlagen der Ingenieurinformatik. Springer, Berlin u.a. Poulos HG, Carter JP, Small JC (2001) Foundations and Retaining Structures - Research and Practice. In: Proc. of the 15th International Conference on Soil Mechanics and Geotechnical Engineering XV ICCSMGE, Balkema, Rotterdam, pp 2527–2606 Rump FJ (1999) Geschäftsprozeßmanagement auf der Basis ereignisgesteuerter Prozeßketten. Teubner, Stuttgart Rüppel U, Greb S (2002) Process-oriented Co-ordination of Planning Activities in Structural Engineering. In: Proc. of the 9th International Workshop of the European Group for Intelligent Computing in Engineering (EG-ICE), Fortschritt-Bericht, VDI-Verlag, Darmstadt, S 218–227 Rüppel U, Meißner UF, Greb S (2003) Vernetzte Bauprozesssteuerung auf der Basis bauteilspezifischer Prozessmuster für geotechnische Konstruktionselemente. In: Gürlebeck K, Hempel L, Könke C (Hrsg.) Digital Proceedings: Internationales Kolloquium über die Anwendungen der Informatik und der Mathematik in Architektur und Bauwesen (IKM), Weimar Rüppel U, Meißner UF, Greb S (2004a) A Petri Net based Method for Distributed Process Modelling in Structural Engineering. In: Proceedings of the Xth International Conference on Computing in Civil and Building Engineering (ICCCBE-X), Weimar Rüppel U, Meißner UF, Greb S (2004b) Modeling processes and processing product model information based on Petri Nets. In: Proceedings of the 5th European Conference on Product and Process Modelling in the Building and Construction Industry (ECPPM 2004), Istanbul, Balkema, Rotterdam Rüppel U, Meißner UF, Greb S (2004c) Abstraction of Process Relevant Information from Geotechnical Standards and Regulations. In: Beucke K, Firmenich B, Donath D, Fruchter R, Roddis K (eds) Digital Proceedings of the 10th International Conference on Computing in Civil and Building Engineering (ICCCBE-X), Weimar Rüppel, U, Meißner UF, Greb S (2005) Process-orientation based on Petri-Nets for the Coordination of Planning Processes in Civil Engineering. In: Proceedings of the International Conference on Computing in Civil Engineering 2005 (ICCC2005), Cancun Seeling R (1996) Projektsteuerung im Bauwesen. Teubner, Stuttgart Verbeek HMW, Basten T, v. d. Aalst WMP (2001) Diagnosing Workflow Processes using Woflan. The Computer Journal 44:4, pp 246–279

5 Ein prozessorientiertes Kooperationsmodell für eine anforderungsorientierte dynamische Unterstützung der Integralen Bauplanung

Petra von Both, Niklaus Kohler Universität Karlsruhe, Institut für Industrielle Bauproduktion {petra.vonboth | niklaus.kohler}@ifib.uni-karlsruhe.de

5.1 Einleitung Bauprojekte weisen als branchenübergreifende Unikatentwicklungen eine sehr hohe Komplexität und Dynamik auf. Dies resultiert unter anderem aus der starken Vernetzung und Abhängigkeit der unterschiedlichen Planungsaspekte, der Vielzahl an Planungsbeteiligten sowie der Einbeziehung des Auftraggebers und auch zum Teil der Nutzer in den Zielfindungsprozess. Herkömmliche Prozessstrukturen im Bauwesen basieren auf einer sequentiellen Vorgehensweise aller am Planungsprozess beteiligten Akteure. Hier wird die Planung als Problem der sequentiellen Abfolge von Planungsleistungen verstanden, die auf Basis der Netzplantechnik bearbeitet werden. Die Zusammenarbeit der Planungsbeteiligten umfasst dabei hauptsächlich den Austausch isoliert erarbeiteter Teil-Ergebnisse (Jungbluth 1997; Grabowski 2003). Gerade im Kontext räumlich verteilter Zusammenarbeit erscheint dieses rein deterministische Vorgehen als nicht sinnvoll, da es häufig zu Problemen unzureichender fachlicher Abstimmung bzw. Synchronisation und hierdurch zu unzureichend abgestimmte Teillösungen führt (Wörner 1997; Wiegand 1995; Müller 1999). Die Integrale Planung reagiert auf die oben genannten Anforderungen von fachübergreifenden Bauprojekten, indem sie die Planung als integrierte Gesamtleistung unterschiedlicher Fachrichtungen anstatt als Summe von separat zu optimierenden Einzelleistungen sieht (Wiegand 1995; SIA 1996). Der hohen Komplexität von Bauprojekten wird durch eine konsequente Projekt-, Anforderungs- und Ressourcenorientierung im Planungsvorgehen Rechnung getragen.

98

Petra von Both, Niklaus Kohler

Mit dem Aufkommen und der Verbreitung moderner Kommunikations- und Informationssysteme haben sich die technischen Voraussetzungen für ein integrales, teamorientiertes Planungsvorgehen wesentlich verbessert. Zur gezielten Nutzung dieser umfassenden Möglichkeiten müssen allerdings die bisher gewohnten Strukturen und Vorgehensweisen auf ihre gegenwärtige und zukünftige Tauglichkeit in Hinblick auf ein integrales Vorgehen überprüft und auf die sich abzeichnenden Anforderungen und Herausforderungen angepasst werden. Dies beinhaltet vor allem die organisatorischen Modelle innerhalb von Unternehmen und hierbei speziell in miteinander kooperierenden Unternehmen, aber ebenso die Modelle zur Abbildung der bei der Planung ablaufenden Prozesse. Genau an diesem Punkt setzt das Konzept des Prozessorientierten Kooperationsmodells an und bietet in seiner Ausarbeitung die Voraussetzung für die Entwicklung unterstützender, bauspezifischer Werkzeuge zur Unterstützung integraler Planungsprozesse.

5.2 Projektziele Ziel des Projektes ist die Konzeption und prototypische Umsetzung eines Werkzeuges zur Prozessunterstützung, das die Komplexität und den hohen Grad an Dynamik bei Bauprojekten berücksichtigt. Dazu soll eine für dynamische Entwicklungen in netzwerkartigen Kooperationsstrukturen möglichst offene Form der Prozessunterstützung als koordinierendes Instrument entwickelt werden, das in Form eines internetfähigen Systems das verteilte Arbeiten unterstützt.

Abb. 5.1. Kooperative Projektdurchführung

Diese Prozessunterstützung soll den Planerteams möglichst große Freiheiten in der Wahl ihrer Arbeitsmethoden bieten, um den Lösungsraum nicht einzuschränken und Entwicklungsspielräume zu schaffen. So können qualitäts- und effizienzsteigernde Maßnahmen in den Teams selbst initiiert werden, da dort die größte Kompetenz hinsichtlich der Problemlösung und deren Umsetzung (Problemlösungsstrategie) liegt.

Ein prozessorientiertes Kooperationsmodell

99

Der Ansatz versucht, ergänzend zum geeigneten Entwurf von Produktrepräsentationsmodellen, scheinbar nicht formalisierbare "kreative" Planungsprozesse vor allem in frühen Phasen über eine spezielle Methodik in strukturierte, aber anpassbare Prozessmodule zu überführen. Ziel dieses Projektes ist daher die Entwicklung und rechnerische Umsetzung einer dynamischen Prozessunterstützung, die

x eine Prozesskoordination auf Phasen- und Projektebene ermöglicht, x eine effiziente Ziel- und Aufgabensystematik als Grundlage der Ablaufplanung bietet,

x eine prozessbezogene Verwaltung von Informationen ermöglicht, x Transparenz des Projektstandes für alle Planungsbeteiligten bietet, x die phasenübergreifende Integration der Planungsprozesse ermöglicht.

5.3 Grundlagen des Projektes und Bewertung Durch Termin- und Ablaufpläne können die zu leistenden Tätigkeiten und die hierbei geltenden zeitlichen Rahmenbedingungen eines Projektes abgebildet werden. Die in der Praxis bedeutsamsten Methoden sollen nachfolgend kurz vorgestellt werden:

x Balkenpläne (auch Gantt-Diagramme genannt) sind dadurch gekennzeichnet, dass über einer horizontalen Zeitachse Balken so aufgetragen werden, dass ihre Länge maßstabsgerecht einen Zeitbedarf und ihre Lage eine zeitliche Zuordnung der vertikal aufgelisteten Aktivitäten oder Funktionen markiert (Madaus 1990). x Netzpläne (vgl. DIN 69900 Projektmanagement) stellen zusätzlich Abhängigkeiten und Interdependenzen der Aktivitäten dar, allerdings können keine Iterationen abgebildet werden. Netzpläne dienen der frühzeitigen Planung und Koordination von Abläufen mit hohem Verknüpfungsgrad und werden vorwiegend in der Bauphase komplexer Vorhaben eingesetzt (Aggteleky u. Banja 1992). Die bekanntesten Verfahren sind Critical Path Method (CPM), die Program Evaluation and Review Technique (PERT) und die Metra Potential Method (Madaus 1990). x Daneben kommen – gerade für die Planungsphasen – auch Projektstrukturpläne und projektneutrale Entwicklungspläne (Eversheim und Scuh 1996) zum Einsatz. Die Termin- und Ablaufpläne sind in Unternehmen meist EDV-unterstützt und dienen als wichtiges Hilfsmittel der Projektkoordination (Moderierbarkeit) und Projektsteuerung (Controlling), da bei gründlicher Planung in ihr die zeitlich aufeinander abgestimmten Einzeltätigkeiten übersichtlich und kontrollfähig zusammengefasst sind.

100

Petra von Both, Niklaus Kohler

Projektmanagementsysteme (vgl. DIN 96904) haben die erfolgreiche Steuerung der Größen Leistung, Kosten und Zeit zum Ziel (Jungbluth 1997, 1998). Nach (Prinz 2001) ist Projektmanagement aufgrund seiner stark kooperativen Aspekte ein typisches Einsatzgebiet von CSCW (Computer Supported Cooperative Work). Die Theorie stellt mit der Forderung nach einem ganzheitlichen Projektmanagement große Anforderungen an unterstützende Softwareprodukte. Vor allem neuere Entwicklungen in der Projektmanagementwissenschaft, wie das teamorientierte Projektmanagement oder das "Management by Projects" sprechen Bedürfnisse an, welche die vorhandenen Systeme nur bedingt erfüllen können (vgl. Schindler et al.1998; Armbruster 2003). Eine Vielzahl von Problemen der Koordination von Planungsprozessen bzw. der Ablaufplanung in der Praxis entstehen dabei durch den Versuch, Hilfsmittel, die ursprünglich zur Koordination von Ausführungs- bzw. Bauprozessen entwickelt wurden, auch auf unscharfe Planungsprozesse anzuwenden. So sind viele methodische Hilfsmittel, wie z.B. die Netzplantechnik, eher im Hinblick auf die Ausführungsplanung konzipiert (Brandenberger u. Ruosch 1993). Bezogen auf Planungsprozesse besonders in den frühen Projektphasen erweisen sich diese Ansätze und Hilfsmittel allerdings als problematisch. Auch neuere Bestrebungen zur Berücksichtigung einer gewissen Unschärfe und zur Handhabung unvorhersehbarer Ereignisse anhand von Fuzzy-Zahlen (Freund 2003) scheinen nur bedingt geeignet. Spricht man von einer Unterstützung der Ablaufplanung, so scheint es daher notwendig, eine Differenzierung zwischen der Modellierung schwer formalisierbarer Planungsprozesse und der Ablaufplanung für besser abschätzbare und standardisierbare Ausführungs- bzw. Bauprozesse zu treffen. In der Literatur wird das Thema der Ablaufplanung meist nur für die Ausführungsphase betrachtet (vgl. Mellentin et al. 2002; Freund 2003; Trautmann 2003). Sinnvolle Konzepte zur Unterstützung von kreativen, schwer zu formalisierenden Prozessen der Produktplanung sind in der Praxis bisher nicht zu finden. Als ein weiteres Problemfeld der traditionellen Ablaufplanung ist ein sehr frühes und starres Festlegen auf explizite Lösungsmuster zu nennen, was auch wiederum in enger Wechselwirkung mit den eingesetzten inflexiblen Hilfsmitteln zur Koordination der Planungsprozesse steht. Dies gilt besonders für die Übertragung von Ansätzen zur detaillierten Geschäftsprozessmodellierung anhand eines informationsbasierten Workflow-Managements (WFMC) die eigentlich zur Unterstützung gut standardisierbarer und oft durchzuführender informationsverarbeitender Prozesse auf sehr detailliertem Niveau konzipiert wurden (Prinz 2001). Diese Ansätze zur Geschäftsprozessmodellierung geben den Planungsprozess auf einer sehr detaillierten, bereits an konkrete Informationsobjekte gebundenen Tätigkeitsebene verbindlich und damit recht starr vor. Da die Dynamik der sich ändernden Randbedingungen so nur unzureichend erfasst werden kann, scheiden sie daher für die Unterstützung schwer formalisierbarer Primärprozesse der Unikatplanung weitestgehend aus. Zudem setzen diese Ansätze eine starke Standardisierbarkeit der Prozesse voraus, was gerade bei kreativen Entwurfsprozessen nicht sinnvoll realisierbar erscheint.

Ein prozessorientiertes Kooperationsmodell

101

Breitling (Breitling 2003) kommt für den Bereich der Modellierung von Prozessen kundenspezifischer Softwareentwicklungen zu dem Ergebnis, das die heute gängigen Methoden zur Modellierung von Geschäftsprozessen für die gemeinsame Modellierung und abgestimmte Entwicklung nur sehr bedingt geeignet sind. Aufgrund der starken Ausrichtung an objektorientierten Ansätzen zur Formalisierung (wie z.B. UML (Seemann u. Gundenberg 2000)), sind diese aus der Softwareentwicklung stammenden Ansätze nicht direkt auf den Bereich der Bauplanung übertragbar. Will man Planungsprozesse – gerade in den frühen entscheidenden Projektphasen – entsprechend koordinieren, ohne den dort notwendigen planerischen Freiraum durch starre Vorgaben einzuschränken, so wird es deutlich, dass die zur Zeit praktizierten Vorgehensweisen hinterfragt werden müssen und neue Ansätze zu erarbeiten sind, die eine flexiblere Koordination und die Erfassung der Unschärfe kreativer Planungsprozesse erlauben.

5.4 Lösungsansatz Lösungsansatz ist die Erarbeitung einer für dynamische Entwicklungen in verteilten netzwerkartigen Kooperationsstrukturen möglichst offene Form der Prozessunterstützung, das als koordinierendes Instrument:

x einen phasenbezogenen Ansatz zur Prozessmodellierung unterstützt, x einen flexiblen koordinierenden Rahmen für verteilt stattfindende kreative Planungsprozesse bildet,

x den Planerteams dabei möglichst große Freiheit in der Wahl ihrer Arbeitsmethoden bietet,

x die Initiierung von Entscheidungsprozessen zum Zielcontrolling ermöglicht, x die Durchführung von Iterationszyklen als wichtiges Mittel der Optimierung innerhalb der Problemlösungsprozesse unterstützt. Zur Bewerkstelligung des genannten ganzheitlichen Ansatzes soll die Thematik der Prozessmodellierung nicht isoliert betrachtet werden, sondern wird in einen entsprechenden Kooperationskontext eingebunden. So wird eine Berücksichtigung der vielfältigen inhaltlichen Verknüpfungen und Abhängigkeiten der verschiedenen Problemlösungsprozesse ermöglicht. Die inhaltliche Synchronisation der Planungsprozesse wird somit zu einem zentralen Punkt, da inhaltliche Wechselwirkungen alleine aus der ablauflogischen Verknüpfung der Prozesse kaum ablesbar sind. Daher wurde das im Rahmen des Projektes ProKoop entwickelte Prozessmodell als Partialmodell eines übergeordneten Kooperationsmodells konzipiert, das im Rahmen einer Dissertation (Both 2004) am ifib 2004 fertig gestellt wurde. Zum besseren Verständnis des Gesamtzusammenhanges wird dieses Kooperationsmodell im Folgenden kurz erläutert.

102

Petra von Both, Niklaus Kohler

5.4.1 Das systemische Projektmodell Das Projektmodell stellt eine Art „Baukasten“ dar, der die zur Koordination und kooperativen Durchführung eines Projektes notwendigen Elemente und deren Strukturen enthält sowie Regeln über das Zusammenwirken dieser Elemente. Es beschreibt somit die Konzepte und Methoden“ zur Abbildung und Bewerkstelligung eines integralen Vorgehens sowie die Prinzipien des Aufbaus des Projektes, die notwendigen Mechanismen zur Unterstützung und die Handhabung der Elemente bei der Durchführung. Das Modellschema zur Abbildung integrierter Kooperationen setzt sich aus verschiedenen vernetzten Partialmodellen zusammen. Die konzeptionelle Aufteilung des Modellschemas in Partialmodelle und die Kopplung dieser Teilmodelle lässt sich aus dem Zusammenwirken der kooperationsrelevanten Teilsysteme von Projekten ableiten: Die Leistungserfüllung in einem Projekt erfolgt durch das Ausführen von Prozessen (Prozessmodell), welche zwischen ihnen fließende Informationen modifizieren (Informationsflussmodell). Initiiert werden diese Prozesse zur Erfüllung bestimmter Zielsetzungen bzw. zur Lösung bestimmter Problemstellungen (Ziel- und Aufgabenmodell). Alle zielorientiert stattfindenden Planungsprozesse werden durch bereitgestellte Ressourcen ausgeführt und durch entsprechende Stellen koordiniert (Organisationsmodell). Abbildung 5.2 zeigt schematisch das systemische Projektmodell mit seinen Partialmodellen und Wechselwirkungen. Projektmodell Ablaufkoordination

Ziel- und Aufgabenmodell

Einbindung Zielplanung und –bewertung in den Prozess

Prozessmodell Organisationsmodell

Zielsystem

Aufgabenorganisation

Anforderungen

Teamorientierte Organisationsstruktur

Aufgaben

Zuständigkeiten

Zeit- und RessourcenPlanung

Phasen Meilensteine Prozesse

Beteiligte

aufgabenbezogen

organisationsbezogen

Informationslogistik

Informationsfluss-Modell

Kommunikationsmechanismen prozessbezogen

Abb. 5.2. Das systemische Projektmodell

Das Organisationsmodell stellt den zentralen Teil des Kooperationsmodells dar. Es dient als Bindeglied, da über die Zuordnung der Aufgaben zu Personen im

Ein prozessorientiertes Kooperationsmodell

103

Rahmen der Aufgabenkoordination eine ressourcenorientierte Prozessmodellierung ermöglicht wird. Zudem werden hier die Zuständigkeiten und Verantwortlichkeiten für die Elemente der Teilmodelle über organisatorische Rollen geregelt. Auch das Management der Planungsprozesse (Prozessmodell) darf nicht isoliert betrachtet werden, sondern wird in einen entsprechenden teamorientierten Kooperationskontext eingebunden. Die Modellierung von Prozessen wird daher als Teamprozess betrachtet und entsprechend unterstützt. Dies geschieht unter anderem durch Bereitstellung teamorientierter Kommunikationsmechanismen zur Koordination der Erarbeitung, Anpassung und Änderung von Prozessdaten. Eine Verknüpfung der Prozessmodellierung mit dem Ziel- und Aufgabenmodell ermöglicht die Berücksichtigung inhaltlicher Aspekte als Grundlage der Prozessmodellierung. So wird die flexible Steuerung des Projektablaufes entsprechend den inhaltlichen Ergebnissen des Projektes ermöglicht. Eine Kopplung mit der Anforderungsmodellierung schafft bei der Aufgabenbearbeitung zudem Transparenz hinsichtlich der aufgabenübergreifenden inhaltlichen Wechselwirkungen der verschiedenen Problemstellungen. Umgekehrt ermöglicht die Bereitstellung eines entsprechenden Prozessmodells die projektbegleitende Einbindung der Zielentwicklung und Anpassung in den Planungsprozess. Das Informationsflussmodell stellt eine Art „informationstechnische Klammer“ dar. Hier werden die eigentlichen Projekt- und Planungsinhalte als Informationsobjekte verwaltet und deren Informationsfluss koordiniert. Betrachtet man die Planung als einen hauptsächlich informationsverarbeitenden Prozess, so stellen Informationen aus systemtechnischer Sicht eine der grundlegenden Systemgrößen des Projektes dar. Ihre effiziente Handhabung und Transformation zur Generierung von Planungslösungen wird daher durch die Bereitstellung entsprechender informationslogistischer Strukturen unterstützt. Vorgehen bei der Projektplanung mit dem Kooperationsmodell Wie in Abb. 5.3 dargestellt, werden zunächst bei der Zielplanung die ergebnisbezogenen strategischen Zielsetzungen und taktischen Teilziele des Bauherrn in operative Teilziele überführt, die aufgrund ihres Tätigkeitsbezuges nun eindeutig einer Projektphase zugeordnet werden können. Aus diesen phasenbezogenen Teilzielen können Meilensteine abgeleitet werden, die einen groben terminlichen Rahmen für das Projekt bilden. Eine sich anschließende an Produktkomponenten und Produktfunktionen orientierte Zerlegung kann parallel zu den meist funktionsorientierten Projektanforderungen (Andersen et al. 1999) abgeleitet werden. Sie kann als Basis für die Klärung der Erwartungen des Auftraggebers und zur Erstellung der Leistungsbeschreibung des Produktes mit Vorteil verwendet werden. Die so abgeleiteten Teilziele werden schließlich in so genannte Aufgabenkomplexe überführt, die ebenfalls objektorientiert sind. Diese Aufgabenkomplexe beinhalten interdisziplinäre Problemstellungen, die inhaltlich eng verknüpft sind, da sie sich auf dieselbe Produktkomponente oder -funktion beziehen. Sie bilden daher die Bezugseinheit zur Bildung der Organisationsstruktur (Planungsteams) im Projekt. Diese Gliederung der Organisationsstruktur in aufgabenkomplexbezo-

104

Petra von Both, Niklaus Kohler

gene Teams bietet eine hohe Flexibilität, da sie sich aus den aktuellen Problemstellungen heraus ergibt und zu Projektbeginn nicht starr vorausgeplant wird. Z

Zerlegung Projektfunktionen

OTZ

Phasen Objektfunktionen / -komponenten Handlungsträger

TZ Teilziel AK Aufgabenkomplex AP Arbeitspaket A Anforderung T Team P Person

TZ

TZ

TZ

Operat. Teilziel

OTZ

TZ

TZ

TZ

AP

AP

AP

AP

A

A

AP

Team B

Team A

Anforderungen

A

AK

AK AP

Meilenstein

Aufbauorganisation

T

Überführung in Ablauflogik

P

T

T

P

P

Prozess 2 Prozess 1

Prozess 3

Abb. 5.3. Strukturierung des Ziel- und Aufgabensystems

Den Aufgabenkomplexen sind ebenfalls objektorientiert strukturierte Anforderungen zugeordnet. Über diese aufgabenübergeordnete Zuordnung von Anforderungen können funktionale und bauteil- oder raumbezogene Wechselwirkungen deutlich gemacht werden. Eine Strukturierung nach Handlungsträgern (Aufteilung der Arbeitspakete zu den unterschiedlichen Fachdomänen) findet erst auf unterer Ebene innerhalb der Teams statt, um eine ganzheitliche Bearbeitung der Aufgaben zu gewährleisten. Aufbauend auf den inhaltlichen Wechselwirkungen der Aufgabenstellungen wird sodann durch Überführung der Aufgabenpakete in ablauflogisch verknüpfte Prozesse die Basis zur Prozessmodellierung geschaffen. Schema des Projektmodells Die Abbildung des Projektmodells erfordert, wie auch die Unternehmensmodellierung (Sprung et al.1993; Milde 1997; Schmid 1998), eine geeignete Modellierungsmethode. Diese Methode definiert die verfügbaren Elemente (Sprachkonstrukte bzw. Begriffe), aus denen sich ein Modell zusammensetzt, sowie deren Relationen. Die gewählte Darstellung (vgl. Abb. 5.4) ist an die Formalisierung des Entity Relationship Models (ERM) (Chen 1992) angelehnt, so dass die Elemente bzw. Entitäten als Knoten des semantischen Netzes sowie ihre Relationen, welche die Netzkanten darstellen, beschrieben werden können. Abbildung 5.4 beschreibt den Aufbau und die Struktur des Projektmodells. Es zeigt die projektrelevanten Teilmodelle mit den darin enthaltenen Elementen und deren Struktur sowie ihre Einbindung in das gesamte Projektmodell über die Vernetzung mit den übrigen Teilmodellen.

Ein prozessorientiertes Kooperationsmodell

Abb. 5.4. Vereinfachtes ERM des Projektmodells (Both 2004)

105

106

Petra von Both, Niklaus Kohler

Ziel- und Aufgabenmodell: Die Ziele des Projektes und die Projektinhalte werden über das Ziel- und Aufgabenmodell abgebildet. Das ER-Diagramm zeigt das Teilmodell mit den darin enthaltenen Elementen: Ziele, Anforderungen, operative Planungspakete und Aufgaben. Anhand der dargestellten Strukturen werden die Überführungsrelationen der Zielebenen deutlich wie auch die Hierarchie des Aufgabensystems. Das im Rahmen dieser Arbeit entwickelte Zielsystem weist dabei verschiedene Ebenen auf, um eine Überführung von abstrakten Zielformulierungen früher Projektphasen (allgemeine strategische Ziele des Auftraggebers) über taktische Teilziele in operative Aufgaben und konkrete Anforderungen zu ermöglichen. Die strategischen Zielsetzungen des Bauherrn dienen dabei zur Abbildung des Wertesystems der Beteiligten und des Umfeldes. Taktische Ziele definieren hierauf aufbauend den Zweck oder Nutzen des Objektes bzw. Projektes. Beide Zielebenen sind lösungsneutral bzw. ergebnisorientiert formuliert und werden erst im Rahmen der Überführung anhand operativer Aufgabenstellungen tätigkeitsorientiert beschrieben. Die aus den taktischen Zielen abgeleiteten Anforderungen beschreiben als Qualitäts- und Leistungsmerkmale die konkret zu erreichenden SollEigenschaften des Planungsgegenstandes und stellen somit die eigentlichen planungsrelevanten Stellgrößen dar. Die so genannten operativen Planungspakete spezifizieren die zur Erreichung der taktischen Ziele notwendigen Handlungsziele. Aus ihnen werden auf Teamebene so genannte Aufgabenkomplexe und schließlich einzelne personenbezogene Arbeitspakete abgeleitet, welche die operationalisierten Aufgabenstellungen bzw. Tätigkeiten zur Erreichung der Projektziele beschreiben. Die einzelnen Elementklassen weisen eine klasseninterne Struktur auf, über welche die inhaltlichen Wechselwirkungen der Planungsinhalte und Aufgaben sowie mögliche Ziel- und Anforderungskonflikte abgebildet werden können. Die Grafik zeigt außerdem die zur zielorientierten Bewertung der Aufgabenstellungen genutzten Bewertungsdokumente, über die anhand einer Gegenüberstellung von Soll- und Ist-Werten ein anforderungsorientierter Regelmechanismus ermöglicht wird. Eine Validierung der im Rahmen der Aufgabenbearbeitung erstellten Planungslösungen (hier liefern die Inhaltsobjekte des Informationsflussmodells die Ist-Werte) mit den in den Anforderungen spezifizierten Soll-Werten anhand von zugewiesenen Validierungsmethoden ermöglicht eine normierte Beurteilung der Zielerfüllung. Eine aufgabenbezogene Bereitstellung von Werkzeugen und Methoden bietet methodische und technische Hilfestellung bei der eigentlichen Aufgabenbearbeitung und dient zur Sicherstellung der Prozessqualität. Die Verknüpfung mit dem Prozessmodell dient der zeitlichen Koordination der Aufgabenbearbeitung. Über die Spezifikation von Prozessen zur Aufgabenbearbeitung wird zudem die Zuordnung der Aufgabenstellungen zu den zuständigen organisatorischen Einheiten im Organisationsmodell ermöglicht. Diese Zuordnung organisatorischer Rollen ermöglicht zudem die Klärung der Verantwortlichkeiten für die Zielplanung und Bewertung.

Ein prozessorientiertes Kooperationsmodell

107

Organisationsmodell: Das Organisationsmodell dient zur Abbildung der Aufbauorganisation des Projektes. Anhand der Modellstruktur werden die Bestandsrelationen der organisatorischen Ebenen deutlich, welche zur Erfassung der Organisationshierarchie dienen. Die Projektorganisation besteht aus verschiedenen Teams, in welche die einzelnen Personen als Teammitglieder involviert sind. Diese Personen sind zudem über das Projekt hinaus in bestimmte Institutionen eingebunden, wie Planerbüros oder sonstige Unternehmen. Diese Institutionen treten im Rahmen des Projektes als Auftragnehmer auf, wobei ihre projektbezogenen Tätigkeiten und die hierbei geltenden Rahmenbedingungen durch entsprechende Vertragsdokumente festgeschrieben werden. Die Regelung der Managementverantwortlichkeiten erfolgt auf zwei Ebenen (Projekt und Team) anhand von organisatorischen Rollen. Basierend auf dem Ansatz der „koordinierten Selbstorganisation“ liegt das teaminterne Management in Abstimmung mit dem Gesamtprojekt im Verantwortungsbereich des Teams selber. Über diese Managementrollen, welche neben den traditionellen Managementtätigkeiten, wie Planung und Steuerung oder Aufbauorganisation auch explizit die Qualitätssicherung bzw. den Bereich der inhaltlichen Koordination abdecken, werden auch die Zuständigkeiten und Bearbeitungsrechte für die Elemente des Projektmodells bzw. der Teilmodelle geregelt. Belegt eine Person eine fachliche Rolle, die Bereiche der eigentlichen Objektplanung beschreibt, so können ihr als Rollenträger entsprechende planungsbezogene Arbeitspakete im Ziel- und Aufgabenmodell zugeordnet werden. Anhand einer Zuordnung der organisatorischen Einheiten des Organisationsmodells zu entsprechenden Prozessen, die der laufzeitbezogenen Koordination der Aufgabenbearbeitung dienen, wird die konkrete Regelung der Zuständigkeiten und ein Ressourcenmanagement ermöglicht. Prozessmodell: Das Prozessmodell bildet die Ablauforganisation des Projektes ab und dient zur Koordination der Projektdurchführung. Das obige ER-Modell zeigt die Elemente des Teilmodells (Phasen, Meilensteine, Rahmenprozesse und Prozesse) und deren Struktur. Die dargestellten Bestandsrelationen der Prozessebenen dienen zur Repräsentation der Prozesshierarchie. Die Ablaufstruktur des Projektes wird auf Koordinationsebene durch ablauflogisch verknüpfte Planungsphasen abgebildet, denen einzelne Meilensteine zugeordnet werden können. Der einzelne Meilenstein beschreibt durch Verknüpfung mit den in den operativen Planungspaketen beschriebenen Handlungszielen (vgl. Teilmodell Ziele und Aufgaben) einen Zielzustand, an dem das Projekt bzw. die Phase zu einem bestimmten Zeitpunkt sein sollte. Zweck des Meilensteinplanes ist es somit, Überprüfungspunkte zu bieten, welche eine Bewertung bzw. ein Controlling des Projektfortschrittes auf Koordinationsebene ermöglichen. In den einzelnen Phasen finden so genannte Rahmenprozesse statt, die einem Planungsteam zugeordnet werden und zur zeitlichen Koordination der Arbeiten der Teams untereinander dienen. Zur laufzeitbezogenen Koordination der teaminternen Arbeiten dienen so genannte Prozesse, die neben Angaben zum Terminmanagement, wie Start-, Enddatum und Dauer auch eine Verwaltung des Bearbeitungsstatus ermöglichen. Die Ablauflogik der Prozesse mit ihren Anordnungs-

108

Petra von Both, Niklaus Kohler

beziehungen wird über ablauflogische Verknüpfungen verwaltet. Die Beschreibung der im Rahmen der Prozesse zu bearbeitenden Aufgabeninhalte erfolgt durch eine Zuordnung zu den Arbeitspaketen und Aufgabenkomplexen des Ziel- und Aufgabenmodells. Über eine Verknüpfung der Prozesse mit den organisatorischen Rollen des Organisationsmodells wird die Regelung der Zuständigkeiten und ein Ressourcenmanagement ermöglicht. Die Kopplung mit dem Informationsflussmodell dient dem prozessorientierten Terminmanagement sowie der Bereitstellung laufzeitbezogener Kommunikationsmechanismen, wie z.B. Benachrichtigungen bei Statuswechsel der Prozesse. Eine detaillierte Erläuterung erfolgt im folgenden Kapitel (Konzeption des ProKoop-Prozessmodells). Informationsflussmodell: Betrachtet man Planung als einen primär informationsverarbeitenden Prozess, so stellt die Handhabung der Informationsflüsse eine wichtige Grundlage zur erfolgreichen Durchführung von Projekten dar. Das Informationsflussmodell bildet dabei eine Art „informationstechnische Klammer“ zur Vernetzung der Projektinhalte. Es repräsentiert über Inhaltsobjekte das im Rahmen der Prozesse zu transformierende Objektsystem. Die informationslogistischen Strukturen nehmen dabei auf die spezifische Struktur des Planungsgegenstandes Bezug. Das ER-Schema (Abb. 5.4) zeigt die Bereitstellung von personenbezogenen Funktionalitäten zum Informations-, Kommunikations- und Terminmanagement. Das Inhaltsobjekt dient als „Informationsträger“ und wird innerhalb der projektbezogenen Informationsbasis verwaltet, wobei auch Möglichkeiten zur Archivierung bereitgestellt werden. Im Rahmen der Projektdurchführung erstellt und bearbeitet eine Person verschiedene Inhaltsobjekte. Anhand dieser Zuordnung kann ein personenbezogenes Informationsmanagement ermöglicht werden. Durch die Bereitstellung von ad-hoc-Workflow-Funktionalitäten als aktive Verteilungsmechanismen können Referenzen auf entsprechende Inhaltsobjekte über so genannte Newsletter versandt werden. Eine personenbezogene Mailbox ist Grundlage einer situativen Kommunikation im Projekt. Über diese Mailbox werden zudem Benachrichtigungen bei Prozessereignissen versandt. Bei der Kopplung mit dem Prozessmodell dient die Verwaltung von Freigabestati der Inhaltsobjekte zudem zur Koordination der Prozessparallelisierung. Ein persönlicher Terminkalender unterstützt ein personen- und teambezogenes Terminmanagement, welches zudem zur Verwaltung von Start- und Endterminen der für diese Person relevanten Prozesse dient.

5.5 Konzeption des ProKoop-Prozessmodells Um den Problemlösungsprozess „Projekt“ – bestehend aus einem umfangreichen Netz aus Planungsschritten – entsprechend strukturieren und koordinieren zu können, findet im Prozessmodell die Gliederung der Planungsschritte und Regelung der Abläufe auf zwei Ebenen statt:

Ein prozessorientiertes Kooperationsmodell

109

x Die ergebnisorientierte Koordinationsebene dient der übersichtlichen Koordination des Gesamtprojektes.

x In der tätigkeitsorientierten Detailebene finden die planungsrelevanten Teamprozesse statt. MS

Koordinationsebene

Phase

Phase

Detailebene

Abb. 5.5. Die zwei Ebenen der Prozessmodellierung

Diese in Abb. 5.5 dargestellte Differenzierung bietet den Vorteil, dass bei Änderungen in der unteren tätigkeitsorientierten Ebene, z.B. durch Anwendung einer anderen Methode zur Zielereichung, die ergebnisorientierte Koordinationsebene nicht verändert werden muss und für die Planer als verbindliche Vorgabe konsistent bleibt. Phasenbezogene Koordinationsebene: Auf der Koordinationsebene findet die Verwaltung des Planungsprozesses auf Managementebene statt. Die Elemente dieser Ebene sind die Projektphase und der Meilensteinplan und unterstützen die Formulierung des Projektvorgehens auf eher übergeordneter Ebene. Sie dienen der Informationsverdichtung und gewährleisten unter Schaffung einer hohen Transparenz hinsichtlich des aktuellen Projektstandes die Gesamtkoordination aller Planungsbeteiligten. Hierzu findet eine Grobstrukturierung des Projektes durch Phasenbildung statt, die einen groben Überblick über den Ablauf des Gesamtprojektes bieten. Der Planungs- bzw. Entwicklungsprozess wird dabei in verschiedene Projektphasen unterteilt, die den groben Rahmen für ein planungs-methodisches Vorgehen bei der Projektdurchführung schaffen. Die einzelnen Projektphasen sind in verschiedene Teilphasen untergliedert, um eine Durchführung von entscheidungsorientierten Iterationszyklen zu ermöglichen. Eine Phasenüberlappung gewährleistet die Überlagerung der verschiedenen Problemlösungszyklen. Zudem kann über diese Phasenuntergliederung zwischen Teilphasen mit eher strategischen Projektplanungs- und Managementprozessen und Prozessen der eigentlichen Objektplanung unterschieden werden: In der so genannten Metaphase (vgl. Abb. 5.6) findet die strategische Planung der Phase (Sekundärprozesse des Managements) unter Berücksichtigung der aktuellen Rahmenbedingungen und vorliegenden Planungsergebnisse statt. Hier erfolgt die phasenbezogene Anpassung und Detaillierung des Zielsystems, die Ableitung der phasenbezogenen Aufgabenstellungen, die Bildung von aufgabenbezogenen Planungsteams sowie die Erarbeitung der Ablaufstruktur der Phase. Die Ausführung der eigentlichen phasenbezogenen Planungsleistungen (Primärprozesse) erfolgt auf Basis der für diese Phase spezifizierten Aufgabenstellungen in der Syn-

110

Petra von Both, Niklaus Kohler

thesephase. In der Analysephase wird im Rahmen von teamübergreifenden Entscheidungsprozessen überprüft, ob die erarbeiteten Planungsergebnisse ein der Gesamtzielsetzung entsprechendes Gesamtergebnis darstellen und im Sinne einer Referenzkonfiguration als Grundlage der nächsten Phase dienen können. Damit soll sichergestellt werden, dass die nachfolgenden Phasen auf den Ergebnissen der vorangehenden aufbauen und nicht weitere, neue Grundsatzvarianten entstehen. Sind die erarbeiteten Ergebnisse nicht als Grundlage der weiterführenden Arbeiten geeignet, so findet im Rahmen eines Iterationszyklus eine Konzeptanpassung bzw. Zielkonfliktlösung statt. Diese Prozesse der zielorientierten Bewertung von Planungslösungen werden in (Both 2004) detailliert erläutert. Parallel zu dieser Prüfung und Überarbeitung der Planungsergebnisse, in der die offenen Problemstellungen und Zielkonflikte bekannt sind, wird im Rahmen einer Phasenüberlappung bereits damit begonnen, die nächste Projektphase vorzubereiten (Metaphase). Diese Parallelisierung der Problemlösungszyklen gewährleistet einen möglichst hohen Informationsaustausch zwischen Objekt- und Zielplanung und ermöglicht die Integration relevanter aktueller Informationen in den Zielbildungsprozess. Zieldetaillierung und -anpassung Veränderliche Randbedingungen

takt. Ziel

Koordinationsebene

takt. Ziel

M3

OPP OPP

OPP

M2

OPP

Metaphase

OPP

M1

OPP

Synthesephase

Analysephase

Phase i Rahmenprozess AK2

Teamebene

E

AK Rahmenprozess AK1

E

RP

E

Freigabe der Ergebnisse

AP AP AP Rückkopplung

Konzeptanpassung Zielkonfliktlösung

Abb. 5.6. Schema des phasenorientierten Prozessmodells

Nach erfolgter Phasenbildung werden zu jeder Phase aus den so operativen Planungsinhalten (OPP) des Aufgabenmodells Meilensteine (M) abgeleitet, die als Meilensteinplan eine Koordinierung auf Managementebene erlauben. Der einzelne Meilenstein beschreibt dabei einen Zielzustand, an dem das Projekt bzw. die Phase an einem bestimmten Zeitpunkt sein sollte. Zweck des Meilensteinplanes ist es, Überprüfungspunkte zu bieten, welche die Bewertung bzw. ein Controlling des Projektfortschrittes ermöglichen.

Ein prozessorientiertes Kooperationsmodell

111

Die Vorgaben dieser Koordinationsebene sind dabei rein ergebnisorientiert, d.h. lösungsneutral formuliert, um die Vorgabe eines sehr starren Planungsvorgehens von Managementseite aus zu vermeiden und im Sinne des Ansatzes der koordinierten Selbstorganisation (Both 2005) der beteiligten Teams entsprechenden planerischen Freiraum zu schaffen. Die Koordinationsebene gibt so die terminlichen Rahmenbedingungen für die teamorientierte Planung auf Detailebene vor. Teamorientierte Detailebene: Auf Detailebene finden die eigentlichen wertschöpfenden Prozesse statt. Sie können im Sinne eines Ergebnispfades (Andersen et al. 1999) den Meilensteinen zugeordnet werden. Die Elemente dieser Ebene sind der teambezogene Rahmenprozess (RP) und der einzelne arbeitspaketbezogene Prozess, deren Verwaltung in Abstimmung mit der koordinierenden Ebene teamorientiert erfolgt. Die detaillierte Planung der einzelnen Planungsprozesse erfolgt erst im Planungsverlauf vor Beginn der jeweiligen Phase (Metaphase) unter Berücksichtigung des aktuellen Wissenstandes. Hierbei werden, wie ebenfalls aus Abb. 5.6. ersichtlich, die aus den operativen Planungspaketen (OPP) abgeleiteten Aufgabenkomplexe (AK) (vgl. Aufgabenmodell) in interdisziplinär zu bearbeitende Rahmenprozesse (RP) überführt. Sie dienen zum einen zur Koordination der Arbeiten der Teams untereinander und bilden zudem den koordinierenden Rahmen für die einzelnen im Team stattfindenden Planungsprozesse. Diese einzelnen Prozesse stellen die kleinste von außen vorzugebende Einheit dar und werden den einzelnen Fachplanern eigenverantwortlich übergeben, um ihnen möglichst große Freiheit in der Wahl ihrer Methoden zu bieten. So sollen die Kompetenzen und das Wissen der Planer entsprechend in den Problemlösungsprozess integriert werden. Nach Abschluss eines Rahmenprozesses werden teamintern Entscheidungsprozesse (E) initiiert, die eine ganzheitliche Beurteilung der verschiedenen Planungsergebnisse hinsichtlich der Zielsetzungen und Aufgabenstellung ermöglichen. In (Both 2004) werden entsprechende Methoden zur zielund aufgabenorientierten Bewertung der Planungslösungen vorgestellt. 5.5.1 Abhängigkeiten der Planungsprozesse Die ablauflogischen Anordnungsbeziehungen (AOB) der Prozesse stellen nach (DIN 69901) quantifizierbare Abhängigkeiten zwischen Ereignissen oder Vorgängen dar. Die AOB besitzen eine eigene Regel, die mittels eines definierten Zeitabstands zu berücksichtigen ist. In dem hier beschriebenen Prozessmodell werden folgende Anordnungsbeziehungen verwendet:

x Normalfolge (NF): Anordnungsbeziehung vom Ende eines Vorgangs zum Anfang seines Nachfolgers. x Anfangsfolge (AF): Anordnungsbeziehung vom Anfang eines Vorgangs zum Anfang seines Nachfolgers. x Endfolge (EF): Anordnungsbeziehung vom Ende eines Vorgangs zum Ende seines Nachfolgers.

112

Petra von Both, Niklaus Kohler

x Sprungfolge (SF): Anordnungsbeziehung vom Anfang eines Vorgangs zum Ende seines Nachfolgers. Zusätzlich zur Anordnungsbeziehung kann eine Zeitspanne festgelegt werden, welche die Dauer des zeitlichen Versatzes der Prozesse definiert, um eine Teilparallelisierung zu ermöglichen. So können zum Beispiel Verknüpfungen von Prozessen abgebildet werden, welche aufgrund der engen inhaltlichen Wechselwirkungen parallelisiert werden sollen, bei welchen die Bearbeitung des einen Prozesses aber auf Ergebnissen des anderen aufbaut und so eine gewisse Vorlaufzeit erforderlich wird. Eine Kopplung der Prozesslogik an die Bearbeitungsstati der im Prozess erzeugten Informationen erlaubt eine flexible Parallelisierung der Planungsprozesse (vgl. Abschn. 5.1.2): Sobald Informationen, welche als „zur weiteren Bearbeitung“ in einem bestimmten ablauflogisch verknüpften Prozess gekennzeichnet sind, den Bearbeitungsstaus „verwertbares Zwischenergebnis“ erlangen, wird dies als Prozessereignis genutzt, um die Parallelisierung zu initiieren. 5.5.2 Prozesskoordinierung über Statuswechsel Die Koordination der Primärprozesse wird aufbauend auf der projektspezifisch zu erarbeitenden Ablauflogik über die Verwaltung von Prozessstati realisiert. Hierbei wird der laufzeitbezogene Bearbeitungsstatus eines Prozesses verwaltet. Folgende Stati werden verwaltet: Vorbereitung – läuft – unterbrochen – in Überarbeitung – abgeschlossen – freigegeben. Mit der Konzeption der vorgestellten Stati wird die Abbildung eines iterativen Problemlösungszyklus möglich, da über die Einbeziehung von Freigabemechanismen die Integration von Entscheidungsprozessen und Rückkopplung zur Überarbeitung der Planungsergebnisse ermöglicht wird. Der Statuswechsel der Prozesse wird zudem mit entsprechende Kommunikationsstrukturen unterstützt: Durch Statuswechsel initiierte Benachrichtigungen an zuständige Personen unterstützen ergänzend zu termingesteuerten Kommunikationsmechanismen eine kooperative Bearbeitung der Prozesse (vgl. Informationsmodell).

5.6 Konzeptverifikation – Prototypische Umsetzung Die prototypische Umsetzung des Prozessmodells erfolgt als Modul einer übergeordneten internetbasierten Kooperationsumgebung (Both 2005), die auf Grundlage der Groupwareplattform Lotus Domino mit Client/Server-Systemarchitektur entwickelt wurde. Der Zugriff auf die Datenbankfunktionalität erfolgt hierbei plattformunabhängig über WWW-Browser. Die in Abbildung 5.7. dargestellte Benutzeroberfläche ermöglicht unter Bezugnahme auf die verschiedenen Teilmodelle des Projektmodells einen Zugang zu verschiedenen Software-Modulen:

Ein prozessorientiertes Kooperationsmodell

113

Abb. 5.7. Benutzungsoberfläche der Kooperationsumgebung

Im Modul Prozessmanagement findet die Verwaltung der Prozesse auf Koordinations- und auf Detailebene statt. Eine Visualisierung der Prozesse über Balkenpläne bietet hierbei einen einfachen Überblick über die zu bearbeitenden Planungsprozesse (vgl. Abb. 5.8.). Neben einer Verwaltung aller prozessrelevanten Elemente wie Phasen, Meilensteine und Prozesse bietet das Modul zum dynamischen Prozessmanagement auch Unterstützung hinsichtlich einer teamorientierten Vorgehensweise bei der Erarbeitung und Anpassung der Prozesslogik (Organisationsebene). Zur Laufzeit unterstützen entsprechende Kommunikationsmechanismen, wie z.B. Benachrichtigungen bei Terminänderung, die Prozesskoordination. Eine Projektübersicht bietet, wie in Abb. 5.8 dargestellt, auf oberster Ebene eine grafische Aufarbeitung der Projektphasen über den gesamten Zeitraum des Vorhabens in Form eines Gantt-Diagramms. Sie repräsentiert die Gesamtzeitplanung des Projektes sowie den aktuellen terminlichen Stand. Zur besseren Koordination der einzelnen Phasen werden detaillierte Phasenübersichten angeboten. Diese zeigen, ebenfalls als Gantt-Diagramm, die jeweilige Phase mit ihren Meilensteinen und Rahmenprozessen und verdeutlichen über einer Zeitskala deren jeweilige Dauer und Abfolge. Eine zusätzliche listenbasierte Phasenansicht zeigt die einzelnen angelegten Phasendokumente mit ihren Eintragungen über ihren Identifizierungscode, Be-

114

Petra von Both, Niklaus Kohler

zeichnung, Status, Typ, Start- und Endtermin und erlaubt den Zugriff auf die einzelnen Phasendokumente. Analog zur Phasenansicht wird zudem über eine entsprechende Ansicht der Zugriff auf die phasenorientiert verwalteten Meilensteine ermöglicht. Entsprechende Zusatzinformationen, wie Bezeichnung, Status, zuständige Person und Fertigstellungstermin können auch hier direkt aus der Ansicht entnommen werden. Um eine bessere zeitliche Zuordnung der Meilensteine zu ermöglichen, werden diese zusätzlich in einer Kalenderansicht visualisiert.

Abb. 5.8. Modul zum Prozessmanagement

Auf Detailebene werden die teambezogenen Rahmenprozesse und Prozesse in entsprechenden Ansichten analog zur Koordinationsebene mit ihren wichtigsten Informationen aufgelistet und lassen sich an dieser Stelle direkt öffnen. Diese Auflistung der Prozesse nach Starttermin, Bearbeitungsstatus und Zuständigkeit ermöglicht einen schnellen Überblick über die laufenden Arbeiten und deren organisatorische Zuordnung. Die Bereitstellung personenbezogener Filter ermöglicht hier einen effektiven Zugriff auf die für den jeweiligen Nutzer relevanten Prozessdaten. Eine Anzeige der Prozesse nach Bearbeitungsstatus schafft Transparenz bezüglich des aktuellen Stands der Phase. Die laufzeitbezogene Koordination der Prozesse wird durch einen Notes-Agenten unterstützt, der bei Statuswechsel automatisiert eine Benachrichtigung an die für diesen Prozess verantwortliche Person versendet.

Ein prozessorientiertes Kooperationsmodell

115

Verwaltung der Prozesse: Das Prozesselement dient zur laufzeitbezogenen Koordination der Aufgabenbearbeitung. Der aus dem Arbeitspaket abgeleitete Prozess beinhaltet so zum einen Angaben zur ablauflogischen Struktur der Prozessketten, klärt die Prozesszuständigkeit und enthält Informationen zum Terminmanagement und zur statusbezogenen Laufzeitkoordination. Die folgende Abbildung zeigt die Verwaltungsmaske eines Prozesses.

Abb. 5.9. Elementmaske „Prozess“ im Bearbeitungsmodus

Die Elementmaske untergliedert sich in die Kategorien „Allgemeine Angaben“, „Prozesshierarchie“, „Zuständigkeit“, „Terminkoordination“, „Ablauflogik“, „Ressourcen“, „Controlling“ und „Informationen“: Unter den allgemeinen Angaben werden die Bezeichnung und der Identifizierungscode des Prozesses verwaltet. Zudem erfolgt eine Referenz auf das verknüpfte Arbeitspaket, von welchem der Prozess abgeleitet wurde, sowie die Verwaltung des Ausführungsstatus. Die Prozesshierarchie beschreibt die strukturelle Einordnung des Elementes durch Zuordnung des übergeordneten Rahmenprozesses und der zugehörigen Projektphase. Die Prozesszuständigkeit wird durch Zuordnung einer organisatorischen Rolle als Bearbeiter geregelt. Unter dem Menüpunkt Terminkoordination findet die Verwaltung der Startund Endtermine sowie der Prozessdauer statt. Eine Schnittstelle zum Terminmanagement erlaubt es, den Starttermin des jeweiligen Prozesses in die persönliche Termindatenbank des zuständigen Bearbeiters einzutragen. Die Verwaltung der Ablauflogik erfolgt bezugnehmend auf DIN 69901: „Projektmanagement und Ablaufplanung“ (DIN 69901) durch eine Referenzierung auf die verknüpften Prozesse (Identifizierungscode und Bezeichnung), der ablauflogischen Anordnungsbe-

116

Petra von Both, Niklaus Kohler

ziehung (Normalfolge, Anfangsfolge, Endfolge, Sprungfolge) und der eventuell vorhandenen Pufferzeit. Der Punkt Controlling unterstützt das prozessbegleitende Controlling des zeitlichen Fortschritts sowie der Prozesskosten. Durch die Erstellung und Anzeige prozessbezogener Fortschrittsberichte wird der Stand des laufenden Prozesses leicht nachvollziehbar und terminliche Engpässe können frühzeitig behoben werden. Zur Ermöglichung eines prozessbegleitenden Informationsmanagements kann aus dem Prozessdokument heraus direkt auf alle für diesen Prozess notwendigen Informationen zugegriffen werden. Eine Einteilung der Informationen in „Informationsgrundlage“, „Arbeitsinformationen“ und „Ergebnisse“ hilft bei der Koordination der Informationsflüsse zwischen den vernetzten Prozessen.

5.7 Einordnung in den Gesamtzusammenhang des SPP Ausgehend von dem Ziel des Schwerpunktprogramms 1103, die Planungsprozesse des Konstruktiven Ingenieurbaus für die Nutzung verteilter Ressourcen zu gestalten, geeignete Kooperationsmodelle für die Fachplanung im Informationsverbund der Projektbeteiligten zu entwickeln und die kooperative Projektbearbeitung unter Nutzung verteilter Fachmodelle in Netzen zu ermöglichen, wurde im Projekt ProKoop ein prozessorientiertes Kooperationsmodell für eine anforderungsorientierte, dynamische Unterstützung der Integralen Bauplanung entwickelt. Hierbei wurden neue methodische Grundlagen geschaffen, die die aktuell in der Praxis stattfindenden tief greifenden Veränderungen der Arbeits- und Organisationsstrukturen berücksichtigen, so dass eine Verbesserung der Qualität und Effizienz der verteilten Ingenieurplanung und die Weiterentwicklung innovativer Methoden der IuK-Technologie zur Anwendung in der Bauindustrie kommen können. Es wurden neue Grundlagen für kooperative Planungsprozesse zur Erhöhung der Transparenz von Planungsentscheidungen und zur Bewältigung der zunehmenden technischen Komplexität bei verkürzten Planungszeiten entwickelt. Somit wurden im Projekt ProKoop zentrale Themenbereiche des Schwerpunktprogramms untersucht und in diesem Forschungsbereich Modelle und prototypische Umsetzungen erarbeitet, die die strukturelle Grundlage für die effektive Durchführung unternehmensübergreifender Bauprojekte unter Einsatz moderner IuK-Technologie bieten. Die Arbeitsgruppe „Netzwerkgerechte Prozessmodellierung“ hatte ihr wesentliches Ziel in der formalen Beschreibung von Planungsprozessen im Konstruktiven Ingenieurbau. Das Institut für Industrielle Bauproduktion hat in dem hier beschriebenen Projekt ein Prozessmodell entwickelt, welches in ein am Institut entwickeltes integriertes Kooperationsmodell integriert wurde. Dies geschah im ständigen Austausch mit den anderen beteiligten Instituten des Schwerpunktprogramms. Die Teilnahme an der Arbeitsgruppe „Netzwerkgerechte Prozessmodellierung“ im DFG-Schwerpunktprogramm 1103 „Vernetzt-kooperative Planungsprozesse im Konstruktiven Ingenieurbau“ stellte eine wichtige Grundlage zur

Ein prozessorientiertes Kooperationsmodell

117

inhaltlichen Einbindung und Diskussion der am Institut für Industrielle Bauproduktion erarbeiteten Konzepte dar.

5.8 Verknüpfung mit anderen Projekten des SPP Innerhalb der Arbeitsgruppe „Netzwerkgerechte Prozessmodellierung“ fand während der gesamten Projektlaufzeit eine rege inhaltliche Diskussion über die eingeschlagenen Zielrichtungen innerhalb der einzelnen Projekte statt. Unter der koordinierenden Leitung von Prof. R. Damrath (Universität Hannover) wurde intensiv an einer Abstimmung der Begrifflichkeiten gearbeitet. Grundsätzliche, für alle relevanten Themenbereiche wurden von den einzelnen Instituten aufgearbeitet und in Form von Vorträgen in der gesamten Arbeitsgruppe vorgestellt und diskutiert. Das Institut für Industrielle Bauproduktion hat in diesem Rahmen die eingesetzten Begriffe und Definitionen dokumentiert und zur Diskussion gestellt. Außerdem wurde in Vorträgen die entwickelten Ansätze des Prozessmodells vorgestellt sowie die Grundlagen der teamorientierten Organisation von Projekten präsentiert („Arbeiten im Team“). Die Unterlagen hierzu wurden auf der Homepage des DFG-Schwerpunktprogramms 1103 veröffentlicht (Both 2002).

Literatur Andersen ES, Grude K, Haug T (1999) Zielgerichtetes Projektmanagement. Fachverlag Moderne Wirtschaft, Frankfurt a.M. Armbruster M (2003) Prozesscontrolling durch Informationsverdichtung. in: Grabowski H,, Klimesch C (Hrsg.): Informationslogistik und Prozessmanagement – Bausteine für interdiszipliäre Kooperationen, Logos-Verlag, Berlin v. Both, P (2002) Arbeiten im Team. Beitrag zur Arbeitskreissitzung Prozessmodellierung der DFG-SPP (http://www.iib.bauing.tudarmstadt.de/dfgspp1103/itern/ arbeitsgruppen/verteiltesProzessmodell/2/download/Vortrag_Teammanagement.pdf), Aktualisierungsdatum: 30.01.2002 v. Both, P (2004) Ein systemisches Projektmodell für eine kooperative Planung komplexer Unikate. Dissertation, Fakultät für Architektur, Universität Karlsruhe (TH) Brandenberger J, Ruosch E (1991) Projektmanagement im Bauwesen. Zürich, 3. überarbeitete Auflage, Dietikon Breitling H (2004) Integrierte Modellierung von Geschäftsprozessen und Anwendersoftware. in: GI-Softwaretechnik-Trends; Bd 24 Heft 1, 2004/02 (http://wwwpi.informatik.uni-siegen.de/stt/24_1/) Chen P (1991) Der Entity-Relationship-Ansatz zum logischen Systementwurf: Datenbankund Programmentwurf. BI-Wiss.-Verlag, Mannheim Wien Zürich DIN 69901 (1994) Projektmanagement, T. 1, Beuth Verlag Berlin DIN 69904 (1995) Projektmanagementsysteme, Beuth Verlag Berlin Eversheim W, Schuh G (1996) Betriebshütte: Produktion und Management (Teil 1). Springer, Berlin, S 7–53

118

Petra von Both, Niklaus Kohler

Freundt M (2003) Fuzzy Logik und Graphentheorie als Basis einer flexiblen Bauablaufplanung.. In: Kirschke, H. (Hrsg) Digital Proceedings des Internationalen Kolloquiums über Anwendungen der Informatik und Mathematik in Architektur und Bauwesen (IKM), Weimar, Bauhaus-Universität Weimar, ISSN 1611-4086 Jungbluth V (1997) Teamwork – Einführung in die EDV-gestützte Projektplanung – Alles im Griff – Projektmanagementsysteme im Vergleich. In: c’t, 7/97, Heise Verlag, Hannover Jungbluth V (1998) Optimallösung – Krisenmanagement mit Projektplanungssystemen – Perfekt geplant – Projektmanagementsysteme im Vergleich. In: c’t, 4/98, Heise Verlag, Hannover Grabowski H, Klimesch C (2003) Informationslogistik und Prozessmanagement – Bausteine für interdiszipliäre Kooperationen. Logos-Verlag, Berlin Mellentin C, Trautmann N, Wiegand D (2002) Methoden gegen das Chaos – Projektmanagementsoftware im Vergleich. in: c’t Magazin für Computertechnik, Ausgabe 7/2002, Heise Verlag, Hannover Milde P (1997) Ein Beitrag für den Aufbau und die Nutzung von integrierten Unternehmensmodellen. Universität Karlsruhe, Institut für Rechneranwendung in Planung und Konstruktion, Dissertation, Verlag Shaker Müller C (1999) Der virtuelle Projektraum. Universität Karlsruhe, Fakultät für Architektur, Institut für Industrielle Bauproduktion, Dissertation Prinz W (2001) CSCW & Groupware: Konzepte und Systeme zur computergestützten Zusammenarbeit. Vorlesungsskript an der RWTH Aachen, SS 2001: CSCW & Groupware. Gesellschaft für Mathematik und Datenverarbeitung (GMD-FIT) Schindler M, Hilb M, Fausch M (1998) Trends und Technologien im Rahmen der verteilten Projektabwicklung. Institut für Medien- und Kommunikationsmanagement, Universität St. Gallen Schmidt F (2000) The Datamodel Developers Almanac Release 1.0. Datenmodell für Gebäude und Anlagentechnik. Inst. f. Kernenergie und Energiesysteme, Universität Stuttgart (http://www.ike.uni-stuttgart.de/~www_wn/-projects/datenmodell/index.html) Seemann J, von Gundenberg JW (2000) Software-Entwurf mit UML – Objektorientierte Modellierung mit Beispielen in Java. Springer, Berlin Heidelberg New York SIA Schweizerischer Ingenieur- und Architektenverein (1996) Bundesamt für Konjunkturfragen – Rationelle Verwendung von Elektrizität (RAVEL) (Hrsg) LM 95: TOP Teamorientiertes Planen. EDMZ Bestell-Nr. 724.305 d, Bern: Sepp Steibli Sprung G, Mertins K, Jochem R (1993) Integrierte Unternehmensmodellierung. BeuthVerlag, Wien Zürich Trautmann N (2003) Resource Allocation with Standard Software for Project Management. in: Kirschke H (ed) Digital Proceedings des Internationalen Kolloquiums über Anwendungen der Informatik und Mathematik in Architektur und Bauwesen (IKM), Weimar, Bauhaus-Universität Weimar Wiegand J (1995) Leitfaden für das Planen und Bauen mit Hilfe der Wertanalyse. Bauverlag GmbH, Wiesbaden/Berlin Workflow-Management-Coalition (http://www.wfmc.org) Wörner K et al. (1997) Planungsmethoden für dezentrale Entwicklungsteams. Teilprojekt A2, SFB 374, Universität Stuttgart (http://www.sfb374.uni-stuttgart.de)

Teil III Verteilte Produktmodelle

1 Überblick zum Themenbereich Verteilte Produktmodelle

Berthold Firmenich Bauhaus-Universität Weimar, Juniorprofessur CAD in der Bauinformatik [email protected]

Ernst Rank Technische Universität München, Lehrstuhl für Bauinformatik [email protected]

1.1 Ausgangsfragen und Zielsetzung Im Bauwesen reicht das klassische Planungsmaterial von textuellen Beschreibungen und zeichnerischen Darstellungen bis hin zu räumlichen, maßstäblichen Modellen aus geeigneten Materialien. Bei der rechnergestützten Planung wird das Planungsmaterial durch Produktmodelle repräsentiert. Ein Produktmodell ist im Bauwesen ein Datenmodell, mit dem verschiedenste Aspekte eines Bauwerks beschrieben werden. Hierzu gehören beispielsweise geometrische, physikalische oder organisatorische Informationen. Jedes Modell ist immer nur ein mehr oder weniger genaues Abbild eines Ausschnitts der Wirklichkeit. Es wird als Grundlage für die in der jeweiligen Domäne zu treffenden Planungsentscheidungen gewählt. So ist das Modell eines Bauwerks für einen Architekten ganz anders geartet als für den Tragwerksplaner oder den Ingenieur für die Technische Gebäudeausrüstung. Die Integration aller Informationen zur Planung, Erstellung, Verwaltung und zum Rückbau eines Gebäudes in einem einzigen Modell erscheint zwar theoretisch denkbar, praktisch aber kaum sinnvoll zu sein. Vielmehr werden objektorientierte Partialproduktmodelle entwickelt, die die jeweilige Sicht des Fachplaners abbilden können.

122

Berthold Firmenich, Ernst Rank

Mit der unterschiedlichen Modellsicht ist jedoch ein zentrales Problem jeder Planung verbunden, unabhängig davon, ob sie traditionell oder netz- und computergestützt durchgeführt wird. Sobald mehrere Beteiligte an einem Planungsprozess zusammenwirken sind Modelle aufeinander abzubilden, ist also das gemeinsame Planungsziel nur kooperativ zu erreichen. Die Abbildung von Modellen selbst, vielmehr aber noch das iterative Vorgehen bei der Planung ist mit Konflikten und Inkompatibilitäten verbunden. Diese Tatsache wiederum ist ein wesentlicher Grund für Fehler, die oftmals erst in späten Planungsphasen oder gar erst während der Ausführung erkannt werden und dann meist nur durch kostenintensive Maßnahmen behoben werden können. Die Notwendigkeit zur Kooperation und zur Überwindung von Planungskonflikten besteht nicht erst dann, wenn unterschiedliche Modelltypen (z.B. Architekturmodell, Tragwerksmodell) verwendet werden. Auch innerhalb eines Bereichs entsteht durch die Aufteilung und die separate Bearbeitung von Teilmodellen der Zwang zur Kooperation. Wird beispielsweise die Tragwerksplanung auf mehrere Bearbeiter verteilt, so ist unter anderem die Abstimmung und Übernahme der jeweiligen Lasten und die Vereinbarung von Anschlüssen der Tragwerksteile nötig. Fragen zu geeigneten Modellen, deren Konsistenzerhaltung, Integration und Wissensverarbeitung spielen für die Ziele des DFG-Schwerpunktprogramms eine zentrale Rolle. Entsprechende Problemstellungen wurden in der Arbeitsgruppe Verteilte Produktmodelle behandelt und in den zugeordneten Teilprojekten untersucht. Eine neue Qualität gewinnen die zu lösenden Aufgaben durch den Anspruch, mit Hilfe von Computernetzen zu effizienteren Planungsprozessen zu gelangen.

1.2 Durchgeführte Arbeiten Eine ausführliche Beschreibung der Einzelprojekte des Themenschwerpunkts Verteilte Produktmodelle befindet sich in Kap. III.2–III.6 und IV.4. Die Projekte werden nachfolgend kurz beschrieben. Als Projektbezeichner wird die jeweilige Kapitelnummer verwendet:

x Projekt III.2: An der Bauhaus-Universität Weimar (Prof. Beucke) werden die Grundlagen der synchron verteilten Projektbearbeitung im Bauwesen erforscht und eine geeignete Systemarchitektur für objektorientierte Ingenieuranwendungen entworfen. Das Produktmodell wird als Menge von Objektversionen gespeichert. Diese Mengen werden mit Hilfe einer applikationsunabhängigen Mengenalgebra strukturiert. Die Schnittstelle zwischen Prozess und Produktmodell bildet ein fester Satz von Operationen, die die Konsistenz des Produktmodells sicherstellen. Die erarbeiteten Grundlagen werden mit Hilfe eigener CAD-Anwendungen verifiziert. x Projekt III.3: Das Teilprojekt der RWTH Aachen (Prof. Nagl) beschäftigt sich mit der Unterstützung des konzeptuellen Gebäudeentwurfs, der am Beginn des architektonischen Entwurfsprozesses steht. Hier ist die Kenntnis über geometri-

Überblick zum Themenbereich Verteilte Produktmodelle

x

x

x

x

1

sche und physikalische Eigenschaften des Bauwerks weniger wichtig als die Abbildung des Wissens um die Organisation und die Funktionsweise des Gebäudes. Das konzeptuelle Modell wird über einen wissensbasierten Ansatz durch die Entwurfsentscheidungen und das Fachwissen des Entwerfers repräsentiert. Hierbei kann das Fachwissen über eine einfach zu bedienende visuelle Sprache vom Ingenieur definiert werden. Die Möglichkeiten zur Interaktion des Lösungsansatzes mit verfügbarer Planungssoftware werden anhand eigener Entwicklungen verifiziert. Projekt III.4: An der Universität Wuppertal (Prof. Pegels) werden die vernetzt-kooperativen Planungsprozesse aus der Sicht des Komplettbaus untersucht. In der ersten Projektphase werden Produktmodelldaten realer Projekte analysiert und Anforderungen an die Prozesse spezifiziert. In der zweiten Phase werden konkrete Umsetzungskonzepte für die synchron-wechselseitige Kooperation erarbeitet und mithilfe von Entwurfsmustern und UML1 beschrieben. In der dritten Projektphase steht die Gestaltung international verwendbarer Nutzerschnittstellen für vernetzt-kooperative Ingenieuranwendungen im Vordergrund. Projekt III.5: Das Projekt der Technischen Universität Dresden (Prof. Scherer) hat das Ziel, den Planungsprozess auf der Basis einer kooperativen versionierten Datenbasis zu unterstützen. Teilmengen der Datenbasis werden von den Ingenieuren ausgewählt und mit lokalen Applikationen bearbeitet. Vor der Rückführung müssen die Planungsstände aufeinander abgebildet und miteinander verglichen werden. Die ermittelten Unterschiede werden als Änderungen gespeichert. Wesentliches Projektziel ist es, die divergierenden Planungszustände zu identifizieren und einen konsistenten Gesamtzustand wiederherzustellen. Das Datenmodell wird mit Hilfe von EXPRESS2 formuliert. Zur Verifizierung des Lösungsansatzes wird konkret das IFC3-Datenmodell verwendet. Projekt III.6: Das an der Universität Duisburg/Essen (Prof. SchnellenbachHeld) bearbeitete Projekt befasst sich mit der vernetzt-kooperativen Gebäudeplanung mit verteilten, deklarativen Wissensbanken, die eine Formalisierung des Entwurfs-, Nachweis- und Bemessungswissens zum Ziel haben. Es kommt ein eigenes Produktmodell mit Objekten des Massivbaus und der Raumlufttechnik zum Einsatz. Diese Konfiguration erlaubt aufgrund der vorhandenen Objektabhängigkeiten die Erforschung eines praxistauglichen Änderungsmanagements für den Planungsprozess. Aufgrund der vorhandenen Komplexität werden auch Größen mit unscharfen Grenzen formuliert: Auf diese Weise soll die derzeitige zeit- und kostenintensive Erfassung von Konsequenzen von Planungsänderungen erheblich verbessert werden. Projekt IV.4: Die ungebremste Steigerung der Rechen- und Speicherleistung von Arbeitsplatzrechnern sowie neue Konzepte der geometrischen Modellierung und der numerischen Berechnungsverfahren lassen erwarten, dass in we-

Unified Modeling Language EXPRESS ist die Datenbeschreibungssprache des Normenpakets STEP (ISO 10303) 3 Industry Foundation Classes, ein standardisiertes Bauwerksmodell 2

123

124

Berthold Firmenich, Ernst Rank

niger als 10 Jahren ein erheblicher Teil der computergestützten Planung im Konstruktiven Ingenieurbau nicht mehr an dimensionsreduzierten Modellen, sondern an streng volumenorientierten Modellen durchgeführt werden kann. Dies wird weitreichende Folgen für den gesamten Planungsprozess und insbesondere für die Integration der verschiedenen Teilmodelle mit sich bringen. Hierfür werden in diesem Forschungsvorhaben an der TU München (Prof. Rank und Prof. Bungartz) Konzepte entwickelt und deren Leistungsfähigkeit demonstriert. In der ersten Förderphase des Schwerpunkts bestand die Arbeitsgruppe aus den Projekten III.2 und IV.4. Der Schwerpunkt der Arbeitsgruppentätigkeit lag auf dem Austausch von Erfahrungen bezüglich der Methode der Volumenmodellierung (Bröker et al. 2002). In der zweiten Förderphase wurde die Arbeitsgruppe neu gestaltet. Grundlage war die in Abb. 1.1 ausschnittsweise dargestellte Kooperationsmatrix des Schwerpunkts. Das Projekt IV.4 wechselte in die neu gegründete Arbeitsgruppe Verteilte Simulation, die Projekte III.2, III.3, III.4, III.5 und III.6 bildeten ab jetzt die Arbeitsgruppe. Gemäß Kooperationsmatrix sind die wesentlichen Arbeitsschwerpunkte die Verteilung der Produktmodelle sowie deren Konsistenzsicherung. Ein zweiter Schwerpunkt liegt im Bereich der Wissensverarbeitung. Dagegen werden Integrationskonzepte nicht aktiv erforscht, sondern verfügbare Konzepte zur Lösung eigener Aufgabenstellungen verwendet.

Abb. 1.1. Beitrag der Projekte zu den Zielen des Schwerpunktprogramms

Zur Förderung projektübergreifender Ergebnisse hat sich die Arbeitsgruppe an vielen wissenschaftlichen Veranstaltungen beteiligt. Hierzu gehören eigens organisierte Arbeitsgruppensitzungen, Workshops und Vortragsveranstaltungen. Bei diesen Ereignissen waren stets auch Wissenschaftler aus anderen Arbeitsgruppen

Überblick zum Themenbereich Verteilte Produktmodelle

125

und aus anderen Forschungsvorhaben anwesend. Auf den Industrieworkshops des Schwerpunktprogramms wurden die Lösungsansätze diskutiert und den Bedürfnissen der Praxis angepasst. Die Mitglieder der Arbeitsgruppe waren auf vielfältigen wissenschaftlichen Konferenzen vertreten. Dort wurde nicht nur über die Ergebnisse der Einzelprojekte, sondern auch über gemeinsame Erkenntnisse der Arbeitsgruppe berichtet. So hat die Arbeitsgruppe auf der internationalen Konferenz der Bauinformatik ICCCBE-X einen eigenen kohärenten Workshop bestritten (Firmenich 2004).

Abb. 1.2. Beispielhaftes Szenario zur Erprobung der Lösungsansätze der Arbeitsgruppe

Die Lösungskonzepte der Arbeitsgruppe wurden anhand gemeinsam erarbeiteter Szenarios eingehend untersucht. Ein solches Szenario ist in Abb. 1.2 mitsamt einer Positionierung der Bauteile gezeigt: In einem Bürogebäude möchte der Mieter eine Nutzungsänderung des dargestellten Raums R5.11 von Bürofläche in Rechenzentrum durchführen. Der Raum wird begrenzt von den Bauteilen Wand W5.2 und den Stützen S5.12, S5.13 und S5.14. Der Architekt setzt die Nutzungsänderung um. Dies hat Konsequenzen für zwei beteiligte Fachplaner. Der Tragwerksplaner muss die erhöhten lotrechten Verkehrslasten der Decke D4.3 über die darunter liegenden Bauteile W4.2, S4.12, S4.13 und S4.14 abtragen. Der TGA-Planer muss die erhöhte Kühllast bereitstellen: Unter Einhaltung des vorgegebenen Luftraum-

126

Berthold Firmenich, Ernst Rank

maßes der abgehängten Decke AD5.11 ist der Lüftungskanal L5.8 neu zu dimensionieren und durch den Wanddurchbruch WD(L) zu führen. Durch solche vereinheitlichten Szenarios konnten die Lösungsansätze der Einzelprojekte gegenübergestellt und gegeneinander abgegrenzt werden. Die gemeinsamen Grundannahmen sowie die vorhandenen Unterschiede bei den Forschungsschwerpunkten Produktmodellierung, Konsistenzerhaltung und kooperative Bearbeitung wurden herausgearbeitet.

1.3 Ergebnisse und Erkenntnisse Das methodische Vorgehen der Arbeitsgruppe zur Erreichung der Ziele des Schwerpunktprogramms ist in einer dreidimensionalen Kooperationsmatrix (Abb. 1.3) aufgetragen.

Abb. 1.3. Methoden und Techniken zur Erreichung der Ziele des Schwerpunktprogramms

Überblick zum Themenbereich Verteilte Produktmodelle

127

Auf der Würfeloberseite sind die Projekte und deren Beiträge zu den Zielen des Schwerpunktprogramms dargestellt. Die Vorderseite des Würfels zeigt die angewandten Methoden und Techniken und ordnet diese den Zielen des Schwerpunkts zu. Schließlich zeigt die rechte Seite des Würfels den methodischen Ansatz der Projekte für die angestrebten Ziele des Schwerpunktprogramms. Es sind nur Beiträge zu den aktiv erforschten Zielen Verteilte Modelle, Modellkonsistenz und Wissensbanken dargestellt. Zentraler Forschungsschwerpunkt der Arbeitsgruppe ist die verteilte Bearbeitung einer Bauwerksinstanz und deren Konsistenzerhaltung. In allen fünf Einzelprojekten wird für diese Problemstellung an Lösungskonzepten auf der Grundlage eines über ein Netzwerk verteilten Produktmodells gearbeitet. Die Projekte der Arbeitsgruppe akzeptieren das Internet mit den derzeitigen Einschränkungen der relativen Unzuverlässigkeit und der relativ geringen Bandbreite als Netzwerkumgebung für ihre Lösungsansätze. Die Objektorientierung ist allgemein anerkanntes Modellierungskonzept. Verfügbare Single-User-Systeme werden durchgängig zur Unterstützung des vernetzt-kooperativen Planungsprozesses eingebunden und wiederverwendet. 1.3.1 Modellbearbeitung und Modellverteilung In Kap. I.1 wurde die Kooperation bezüglich der Zeit klassifiziert: Gemäß Abb. 1.4 wird unterschieden zwischen synchroner und asynchroner Kooperation. Synchrone Kooperation lässt sich weiter in wechselseitiges und paralleles Arbeiten unterteilen, unter asynchrone Kooperation fällt das sequentielle Arbeiten (Bretschneider 1998). Aus terminlichen Gründen muss im Bauplanungsprozess in der Regel der besonders schwierige Fall der synchron wechselseitigen Kooperation unterstützt werden. Bei dieser Art der Kooperation arbeiten die Teammitglieder gleichzeitig an genau einer Aufgabe, die sich auf denselben Teil des gemeinsamen Arbeitsmaterials bezieht.

Abb. 1.4. Klassifikation von Kooperation nach der Zeit

Voraussetzung für die verteilte Kooperation ist die Erarbeitung eines entsprechenden Konfliktmanagements. Die Arbeitsgruppe stimmt darin überein, dass das von

128

Berthold Firmenich, Ernst Rank

verfügbaren Datenbanken bereitgestellte Konfliktmanagement in der Form von ACID-Transaktionen4 (Date 2000) im Planungsprozess nur bedingt eingesetzt werden kann. Die Begründung hierfür ist, dass infolge der iterativen Bearbeitung von Ingenieurlösungen die Nutzerinteraktion nicht außerhalb der Transaktionen erfolgen kann. Bei den erforderlichen langen Transaktionen ist die Wahrscheinlichkeit eines Konflikts daher sehr hoch. Im ACID-Transaktionsmodell würde ein solcher Konflikt entweder durch lange Wartezeiten oder durch den Abbruch der Transaktion mit Datenverlust behandelt. Da ACID-Transaktionen ausscheiden, haben sich die Projekte III.2, III.4 und III.5 für die Realisierung eigener langer Transaktionen (Kim 1995) auf der Basis einer zusätzlichen lokalen Datenbasis geeinigt (Abb. 1.5). Dieser Ansatz warf zusätzliche Fragestellungen auf. So mussten für die lokale Bearbeitung Teilmengen der gemeinsamen Produktmodellinstanz gebildet und geeignete Synchronisationsmethoden konzipiert werden.

Abb. 1.5. Realisierung langer Transaktionen bei der Modellbearbeitung

1.3.2 Produkt- und Wissensmodellierung Obwohl sich alle fünf Projekte intensiv mit der Produktmodellierung beschäftigen, hat sich kein einziges Projekt auf ein konkretes Produktmodell wie IFC oder STEP5 festgelegt. Wichtige Gründe für die fehlende Akzeptanz sind die Komplexität und Unvollständigkeit bestehender Standards. Konkrete Implementierungen sind von sehr unterschiedlicher Qualität und es werden zu oft neue Versionen veröffentlicht, die eine Installation neuer Softwarewerkzeuge und Umgebungen nach sich ziehen. Drei der fünf Projekte basieren auf proprietären Produktmodellformaten. Das Projekt III.4 integriert bestehende Planungssysteme und fasst deren Produktmodelle zu einem virtuellen verteilten Produktmodell zusammen. Das Projekt III.5 verwendet zwar das IFC-Produktmodell zur Verifizierung: Es ist dennoch unabhängig von einer konkreten Spezifikation, da mit Hilfe einer EXPRESSBeschreibung Transformationen zwischen verschiedenen Produktmodellen möglich sind. Zur Konsistenzerhaltung der Bauwerksinstanzen wird Fachwissen benötigt. Während in den Projekten III.2, III.4 und III.5 dieses Fachwissen in der Applikation vom Programmierer zur Übersetzungszeit bereits vollständig festgelegt ist, be4 5

Atomicity, Consistency, Durability und Isolation Standard for the exchange of product model data, ein Datenformat für Produktmodelle nach ISO 10303

Überblick zum Themenbereich Verteilte Produktmodelle

129

sitzen die Projekte III.3 und III.6 eine separate Komponente zur Wissensverarbeitung, die die Definition und Modifikation von Fachwissen zur Laufzeit des Programms ermöglicht. Auf der Grundlage der über ein Netzwerk verteilten Wissensbanken werden die verschiedenen Bauwerksinstanzen konsistent gehalten. Eine vereinheitlichte Systemarchitektur aller fünf Projekte ist in Abb. 1.6 gezeigt. Die Architektur besteht aus zwei Teilen. Das linke Teilsystem stellt die Produktmodellierung, das rechte Teilsystem die Wissensverarbeitung dar. Verfügbare Ingenieuranwendungen bestehen meistens nur aus dem links dargestellten Teil, da separate Wissenskomponenten derzeit noch relativ selten zu finden sind.

Abb. 1.6. Vereinheitlichte Systemarchitektur

Ausgehend von der Metamodell-Architektur der OMG (OMG 2006) werden vereinheitlichte Begriffe allgemein für die Produktmodellierung und speziell für die Bauwerksmodellierung festgelegt und innerhalb der Arbeitsgruppe durchgängig verwendet. Abb. 1.7 stellt die Metamodell-Architektur dar, die aus vier Ebenen – Layer genannt – besteht. Die Idee des Metamodells besteht darin, die unteren Ebenen durch höhere Ebenen zu beschreiben. So enthält die unterste Ebene M0 die Daten einer konkreten Instanz eines Modells. In der Produktmodellierung heißt es Produktinstanz oder Produkt, bei der Bauwerksmodellierung spricht man von einer Bauwerksinstanz oder einem Bauwerk. Die nächst höhere Ebene M1 enthält das Modell zur Beschreibung der Instanzen der Ebene M0. Man spricht von einem Produktmodell oder einem Bauwerksmodell. Wesentlich ist, dass man mit einem einzigen Modell eine beliebige Anzahl seiner Instanzen beschreiben kann. Die Modelle werden auf der nächst höheren Ebene M2 durch ein Metamodell beschrieben. Metamodelle werden wiederum durch die Meta-Metamodelle von Ebene M3 beschrieben. Da eine weitere „Metaisierung“ nicht als zweckmäßig gilt, beschreiben sich die Meta-Metamodelle auf Ebene M3 selbst. Dies ist vergleichbar mit der deutschen Sprache, deren Grammatik ja auch mit der deutschen Sprache formuliert wird.

130

Berthold Firmenich, Ernst Rank

Abb. 1.7. Begriffsbildung über die Modellebenen

In der Arbeitsgruppe werden zwei unterschiedliche Ansätze zur Wissensmodellierung untersucht: ein objektorientierter und ein graphbasierter. Die beiden Ansätze werden mit Hilfe der Metamodell-Architektur gegenübergestellt (Abb. 1.8):

x In Projekt III.6 wird das Wissen objektorientiert strukturiert. In der Notation der UML (M2) werden Klassendiagramme erstellt. Beispiele für Klassen (M1) sind Regeln, Formeln und Modellzugriffe, mit deren Hilfe auf Objektebene (M0) beispielsweise konkrete Nachweise im Massivbau geführt werden. x In Projekt III.3 kommt eine eigene graphbasierte Modellierung zum Einsatz. Mit Hilfe einer PROGRES (M3) genannten Spezifikation wird das Schema des Graphen (M2) in der Form einer visuellen Sprache generiert. Mit dieser visuellen Sprache können die für den konzeptuellen Entwurf benötigten Knoten- und Kantentypen (M1) auf einfache Art und Weise beschrieben werden. Auf der Instanzebene (M0) schließlich lässt sich der Graph erzeugen und Regeln – etwa für die Raumplanung – formulieren.

Abb. 1.8. Vergleichende Betrachtung von Lösungsansätzen gemäß der Metamodellarchitektur

Drei Projekte verwenden versionierte Produktmodelle, eine Methode, die sich im Planungsprozess mit seinen Revisions- und Freigabeständen in der Praxis bewährt hat. Durch das Einfrieren bestehenden Planungsmaterials bleibt dieses konsistent und verschafft den sich darauf beziehenden Akteuren eine verlässliche Planungsgrundlage. Die Ableitung neuer Versionen macht den Planungsprozess nachvollziehbar und erlaubt eine parallel synchrone Kooperation auch im Fall voneinander abhängiger Objekte und Objektversionen. Eine Bauwerksinstanz wird mathematisch als eine strukturierte Menge von Objekten bzw. Objektversionen gedeutet. In einer verteilten Umgebung müssen von

Überblick zum Themenbereich Verteilte Produktmodelle

131

den beteiligten Planern möglichst flexibel gültige Teilmengen zu bilden und zu bearbeiten sein. Bei einer Bauwerksinstanz mit voneinander abhängigen Objektversionen ist die Teilmengenbildung von den Projekten III.2, III.4 und III.5 als ein zentraler Forschungsgegenstand identifiziert worden. Die Konsistenzerhaltung der verteilten Bauwerksinstanz wird von allen beteiligten Projekten angestrebt. Es werden unterschiedliche Methoden in den Lösungskonzepten der Einzelprojekte angewendet: 1. Explizite Modellierung von Objektabhängigkeiten: Wird ein Objekt geändert, so müssen die davon abhängigen Objekte aktualisiert werden. 2. Formulierung der einzuhaltenden Konsistenzbedingungen bei den Methoden für die verteilte Bearbeitung 3. Verwendung formaler Methoden für konsistente Spezifikationen und Softwareentwürfe 4. Überprüfung der Einhaltung von Normen und Entwurfswissen in der Bauwerksinstanz Die Unterstützung einer synchron-wechselseitigen Kooperation wird in der Arbeitsgruppe unterschiedlich angegangen. Bei den Projekten III.2 und III.5 werden von dem zu bearbeitenden Planungsmaterial Versionen abgeleitet, getrennt bearbeitet und schließlich wieder zusammengeführt. Dagegen soll im Projekt III.4 wegen der Anforderungen im Komplettbau eine synchron-wechselseitige Kooperation auf der Basis einer einzigen Version stattfinden. Die verteilten Wissensbanken der beiden Projekte III.3 und III.6 werden vom Wissensträger – in diesem Fall vom Bauingenieur oder Architekten – bearbeitet und auf einem Server zur Verfügung gestellt; die zugehörigen Produktmodelle erlauben je nach Aufgabenstellung eine asynchron-sequentielle oder synchron-parallele Bearbeitung. 1.3.3 Fazit Eine effiziente Gestaltung der vernetzt-kooperativen Planungsprozesse erfordert verteilte Produktmodelle. Die Ziele des Schwerpunktprogramms wurden von den Projekten der Arbeitsgruppe mit unterschiedlicher Methodik und Akzentuierung angegangen. Die gewonnenen Erkenntnisse schließen sich keineswegs gegenseitig aus, sondern ergänzen sich zum überwiegenden Teil. Im Ergebnis wurde die Basis für eine konsistente, netzverteilte Produktmodellierung gelegt. Bei den verteilten Anwendungen steht der Vorteil des steigenden Nutzens dem Nachteil einer schwierigeren Anwendung gegenüber. Diese Herausforderung müssen verteilte Ingenieurlösungen aufgreifen und durch geeignete Nutzerschnittstellen kompensieren. Eine erfolgreiche Anwendung der neuen Konzepte wird nur durch Ingenieure mit einer fundierten Ausbildung möglich sein.

132

Berthold Firmenich, Ernst Rank

Literatur Bretschneider D (1998) Modellierung rechnerunterstützter, kooperativer Arbeit in der Tragwerksplanung. VDI, Düsseldorf Bröker H, Nübel V, Bernreuther M, Firmenich B (2002) Erfahrungsbericht zur Entwicklung und Anwendung der Methode der Volumenmodellierung. Technische Universität München, Universität Stuttgart, Bauhaus-Universität Weimar Date CJ (2000) An introduction to database systems. 7. Aufl, Addison-Wesley, Reading Firmenich B (2004) Product Models in Network Based Co-operation in Structural Engineering. In: Proceedings of the Tenth International Conference (ICCCBE-X), Bauhaus-Universität, Weimar Kim W (Hrsg) (1995) Modern database systems: the object model, interoperability and beyond. ACM Press, New York OMG (2006) Homepage der Object Management Group (OMG) (www.omg.org)

2 Verteilte Bearbeitung mit versionierten Produktmodellen im Bauwesen

Karl Beucke, Berthold Firmenich, Daniel G. Beer, Torsten Richter Informatik im Bauwesen, Bauhaus-Universität Weimar [email protected] {berthold.firmenich | torsten.richter}@bauing.uni-weimar.de [email protected]

2.1 Einleitung und Zielsetzung Projekte der Bauplanung werden im Allgemeinen durch mehrere Akteure bearbeitet, die auf der Basis eines gemeinsamen Arbeitsmaterials im Hinblick auf ein gemeinsames Ziel kooperieren. Wie in Abb. 2.1 dargestellt sind drei sich zyklisch wiederholende Phasen zu erkennen. In Phase (1) bilden die Akteure Teilmengen des gemeinsamen Arbeitsmaterials für die eigene Bearbeitung. In Phase (2) werden diese Teilmengen synchron oder asynchron bearbeitet. In Phase (3) schließlich werden die Ergebnisse der Bearbeitung im gemeinsamen Arbeitsmaterial gespeichert.

Abb. 2.1. Phasen der kooperativen Bearbeitung

Der Bauplanungsprozess ist durch seinen iterativen Charakter gekennzeichnet. Die endgültige Lösung wird als Folge der Abstimmungsprozesse erst nach häufigen Änderungen der Lösungen in den einzelnen Fachdisziplinen erzielt. Im Abschnitt III.1.3 wird die Klassifikation der Kooperation nach der Zeit beschrieben.

134

Karl Beucke, Berthold Firmenich, Daniel G. Beer, Torsten Richter

Als Zielsetzung für dieses Projekt soll die synchron wechselseitige Kooperation (s. Abb. III.1.4) ermöglicht werden. Verfügbare Planungssysteme unterstützen die Kommunikation der Akteure durch den Austausch von Dokumenten. Das Erkennen der Änderungen zwischen zwei verschiedenen Versionsständen eines Dokuments ist zeitaufwendig und wird durch verfügbare Systeme kaum unterstützt. Kommerzielle Planungssysteme besitzen keinen allgemeinen Lösungsansatz für die Modellierung der Objektbeziehungen im gemeinsamen Arbeitsmaterial: Es ist konzeptionell nicht möglich, dem Bearbeiter eine Hilfestellung bei der Behandlung der Auswirkungen einer Objektänderung zu geben. Die visuelle Beurteilung der Auswirkungen der Änderungen auf die eigene Planung ist fehleranfällig. Das gemeinsame Arbeitsmaterial ist daher fast immer inkonsistent. Gegenstand des Projektes interCAD ist die Entwicklung der Grundlagen, einer Systemarchitektur und einer Pilotimplementierung, die in ihrem Grundsatz alle Phasen der verteilten Bearbeitung und unterschiedliche Arten der Kooperation (sequentiell, parallel, wechselseitig) berücksichtigt und bestehende Anwendungen integriert. Das gemeinsame Arbeitsmaterial der Beteiligten wird nicht als Dokumentenmenge, sondern als Menge von Objekt- und Elementversionen und deren Beziehungen abstrahiert. Elemente erweitern Objekte um applikationsübergreifende Eigenschaften (Features). Für die Bearbeitung einer Aufgabe werden Teilmengen auf Basis der Features gebildet, für deren Elemente neue Versionen abgeleitet und in einen privaten Arbeitsbereich geladen werden. Die Bearbeitung wird auf Operationen zurückgeführt, mit denen das gemeinsame Arbeitsmaterial konsistent zu halten ist. Die Grundlagen und die Systemarchitektur werden formal mit Mitteln der Mathematik beschrieben. Verfügbare Technologie wird beschrieben und deren Einsatz in einem Umsetzungskonzept dargestellt. Die Systemarchitektur ist so ausgelegt, dass relativ einfach, bestehende Applikationen eingebunden und weiter verwendet werden können. Das Umsetzungskonzept wird pilothaft implementiert. Dies erfolgt in der Umgebung des Internet in der Sprache Java unter Verwendung eines Versionsverwaltungswerkzeuges und relationaler Datenbanktechnologie.

2.2 Beitrag des Projekts zu den Gesamtzielen des SPP und der Arbeitsgruppe Das Projekt interCAD liefert vor allem einen Beitrag zu den Themen ‚Verteilung und Konsistenz der Modelle’ und zu den Aspekten ‚Neugestaltung der Planungsprozesse’ bzw. ‚Neukonzeption der Kommunikation’ (s. Abb. III.1.3). Innerhalb der beiden Schwerpunkte wurden folgende wesentlichen Beiträge geleistet:

x Verteilte Bearbeitung einer strukturierten Menge von Objektversionen x Konsistentes Objektversionsmodell x Verwendung beliebiger objektorientierter Produktmodelle

Verteilte Bearbeitung mit versionierten Produktmodellen im Bauwesen

135

x Flexible Teilmengenbildung x Explizite Speicherung von Objektabhängigkeiten x Synchron-wechselseitige Kooperation mit abgeleiteten Versionen, die später wieder zusammenzuführen sind x Einbindung verfügbarer Single-User-Systeme

2.3 Durchgeführte Arbeiten Ziel des Projekts interCAD war es, die verteilte Bearbeitung im Bauplanungsprozess mit CAD-Software zu untersuchen und umzusetzen. Die Schwerpunkte lagen wie in Abb. III.1.1 des Arbeitsgruppenberichts ersichtlich in der Erforschung der Konsistenz der Modelle und der Verteilung der Modelle. Die Vorgehensweise bei der Bearbeitung der Teilprobleme ist in die folgenden drei Schritte gegliedert:

x Analyse des Stands der Technik und der Wissenschaft x Erforschung neuer oder alternativer Konzepte x Verifizierung an Prototypen Bei der Umsetzung eines CAD-Prototypen mit Objekten, die voneinander abhängig sind, wurde sehr schnell deutlich, dass eine sorgfältige systematische Erforschung der verteilten Bearbeitung erforderlich war. Bei diesen Untersuchungen lag der Schwerpunkt auf der verteilten Bearbeitung des gemeinsamen Arbeitsmaterials eines Projekts im Bauplanungsprozess. Es sollte erforscht werden, wie unter den gegebenen Randbedingungen dieses Prozesses die Konsistenz des gemeinsamen Arbeitsmaterials sicherzustellen ist. Zu den untersuchten Themengebieten gehörten die Formulierung der verteilten Operationen mit Methoden der Mengenlehre, das Aufstellen einer Mengenalgebra für die Teilmengenselektion, die Umsetzung von Objektrelationen, die Konzeption einer Systemarchitektur und die Untersuchung von geeigneten Nutzeroberflächen. Während der Projektlaufzeit bestanden Kooperationen mit anderen Teilprojekten und anderen Wissenschaftlern (Holzer, Pahl, Rank). Innerhalb der Arbeitsgruppe Produktmodelle des Schwerpunktprogramms fanden regelmäßig Treffen statt, auf denen zum einen Erfahrungen ausgetauscht und zum anderen Terminologien und die weitere Vorgehensweise abgestimmt wurden. Ein von der Arbeitsgruppe entwickeltes Szenario (s. Abb. III.1.2) diente zur Untersuchung der eigenen Lösungskonzepte. Im Projekt interCAD entstanden verschiedene wissenschaftliche Arbeiten; unter anderem zwei Dissertationen (Firmenich 2002; Beer 2006) und drei Diplomarbeiten (Boukamp 2001; Koch 2004; Schäfer 2006). Es wurde stets darauf Wert gelegt, den wissenschaftlichen Nachwuchs einzubinden. So wurden Studenten als wissenschaftliche Hilfskräfte angestellt und Aufgaben für Bachelor-, Studien- und Diplomarbeiten vergeben. Die gewonnenen Ergebnisse und Erkenntnisse wurden auf den jährlich stattfindenden Kolloquien des Schwerpunktprogramms vorgestellt und diskutiert. Die

136

Karl Beucke, Berthold Firmenich, Daniel G. Beer, Torsten Richter

Ergebnisse wurden weiterhin auf einigen nationalen und internationalen Konferenzen veröffentlicht. Die ICCCBE-XI in Montreal/Kanada diente als abschließende Präsentation des Schwerpunkts 1103 (Beer et al. 2006), (Richter u. Beucke 2006). Die Industrieworkshops wurden genutzt, um die Anforderungen der Praxis in das eigene Lösungskonzept einfließen zu lassen. Die Industriekontakte sollen in Zukunft dazu dienen, in einem Transferprojekt die entwickelten Lösungskonzepte zu verifizieren und zu verbessern. Im Rahmen des Projekts hat die BauhausUniversität Weimar Patente beim Deutschen Patent- und Markenamt angemeldet.

2.4 Erreichte Ergebnisse und deren Bedeutung 2.4.1 Theoretische Grundlagen des Lösungskonzepts Der gewählte Lösungsansatz bietet die Voraussetzungen für ein konsistentes gemeinsames Arbeitsmaterial bei der verteilten Bearbeitung mit CAD im Bauplanungsprozess (Firmenich 2002, 2002a). Die Schlüsselabstraktionen und die Operationen für die verteilte Bearbeitung werden formal mit Hilfe der Mengenlehre beschrieben. Die Konsistenz des Arbeitsmaterials ist bei einer Einhaltung der formulierten Bedingungen sichergestellt. Die Aktualität des Lösungsansatzes wird damit abgekoppelt von der rasanten Entwicklung der Informations- und Kommunikationstechnik. Die Abstützung auf eine Mengenalgebra hat Vorteile gegenüber einer direkten Implementierung. Die klare Semantik der Grundoperationen der Mengenalgebra sorgt für Transparenz, Nachvollziehbarkeit und einen sprachlichen Zugang. Abstraktionen Das Projekt wird auf Mengen und Relationen zurückgeführt, die anschaulich als Graph dargestellt werden. Ein Graph besteht aus Knoten und Kanten: Knoten symbolisieren Elemente aus Mengen und Kanten symbolisieren geordnete Paare aus Relationen. Beispielsweise besteht der in Abb. 2.2 a dargestellte Graph aus zwei Knoten ai und a sowie aus einer gerichteten Kante von ai nach a. Formal ist der Graph des Projekts: P : (:, M , '; Z ,V , B )

(1)

Der Graph P besteht aus den drei Knotenmengen : , M, ' und den drei Kantenmengen Z , V, B. Die Objektmenge : enthält die Objekte des Projekts. Häufig sind die Objekte voneinander abhängig. Wird ein Objekt geändert oder aus der Menge ausgetragen (gelöscht), so müssen aus Konsistenzgründen die Attribute aller davon abhängigen Objekte in geeigneter Art und Weise aktualisiert werden (Pahl, Beucke 2000). Das Planungsmaterial eines Bauprojekts weist jedoch in der Regel eine außerordentlich hohe Komplexität auf. Nach einer Änderung ist es in der Praxis normalerweise nicht möglich, die davon betroffenen Objekte des Planungsmaterials permanent aktuell zu halten. Ein solcher Versuch würde an der

Verteilte Bearbeitung mit versionierten Produktmodellen im Bauwesen

137

fehlenden Kompetenz der Fachplaner bezüglich anderer Disziplinen sowie an der geforderten Datenhoheit der Fachplaner über ihren Teil des gemeinsamen Arbeitsmaterials scheitern.

Abb. 2.2. Kantenmengen des Graphen P

Das bestehende Arbeitsmaterial des Projekts kann konsistent gehalten werden, wenn der Zustand bereits gespeicherter Objekte nachträglich nicht mehr manipulierbar ist. Mit dieser Festlegung wird darüber hinaus denjenigen Planern, die sich auf gespeicherte Objekte beziehen, eine verlässliche Planungsgrundlage geboten. Im Planungsprozess muss jedoch offensichtlich eine Manipulation des gemeinsamen Arbeitsmaterials möglich sein. Das gewählte Lösungskonzept sieht daher die Speicherung mehrerer Versionen eines Objekts – Objektversionen genannt – vor. Soll eine bestehende Objektversion des Projekts geändert werden, so wird von dieser eine neue Objektversion abgeleitet und bearbeitet. Durch die Speicherung der Objektversionen sind darüber hinaus Entwurfsentscheidungen im Planungsprozess nachvollziehbar. Die Objektversionen des Projekts sind in der Objektversionsmenge M gespeichert. Die Objektversionsabbildung Z : M o : ordnet jeder Objektversion genau ein Objekt zu. Die Elemente der Objektversionsabbildung werden im Graphen als strichpunktierte Kanten mit ausgefüllter Pfeilspitze dargestellt (Abb. 2.2 a). Die Menge ' enthält virtuelle Objektversionen, die zur Modellierung der Ursprungsversion sowie der gelöschten Versionen eines Objekts verwendet werden. Die Objektversionsrelation V Ž M ' u M ' mit M ' : M ‰ ' beschreibt die Entwicklung der Objektversionen der Objekte. Die Elemente dieser Relation werden im Graphen als strichlierte Kanten mit ausgefüllter Pfeilspitze dargestellt (Abb. 2.2 b). Die drei maßgebenden Fälle werden nachfolgend beschrieben. Das geordnete Paar (G i , ai )  ' u M kennzeichnet die Ursprungsversion ai des Objekts a . Das Paar ( a j , a k )  M u M bedeutet, dass die Objektversion a k aus der

138

Karl Beucke, Berthold Firmenich, Daniel G. Beer, Torsten Richter

Änderung der Objektversion a j entstanden ist. Das Paar ( al , G l )  M u ' gibt an, dass die Nachfolgerversion a l logisch gelöscht wurde. Im Gegensatz zu einer unversionierten Umgebung muss nämlich in einer versionierten Umgebung der Zustand „ist gelöscht“ explizit modelliert werden. Die Bindungsrelation B Ž M u M (Pahl u. Beucke 2000) beschreibt die Bindungen zwischen den Objektversionen. Bindungen werden graphisch als durchgezogene Kanten mit einer ausgefüllten Pfeilspitze dargestellt (Abb. 2.2 c). Das Paar ( ai , b j )  B bedeutet, dass zur Berechnung der Attribute (Eigenschaften) der gebundenen Objektversion bj die Attribute der bindenden Objektversion ai verwendet werden. Ändern sich Attribute von ai, so sind die Attribute von bj nicht mehr gültig und müssen erneut berechnet werden. Eine Verkettung von Bindungen führt zum Begriff der Abhängigkeit (Pahl u. Beucke 2000). Die transitive Hülle (Turau 1996; Pahl u. Damrath 2000) H(B) der Bindungsrelation B beschreibt die Abhängigkeiten zwischen den Objektversionen. Abhängigkeiten werden graphisch als durchgezogene Kanten mit nicht ausgefüllter Pfeilspitze dargestellt. Beispielsweise ist in Abb. 2.2 d die Objektversion ck an die Objektversion bj gebunden – abhängig ist sie dagegen von den Objektversionen bj und ai. Einzuhaltende Konsistenzbedingungen Ein einfaches Beispiel aus dem Softwareentwicklungsprozess dient zur Einführung. Die Prozedur b() ruft die Prozedur a() an zwei Stellen auf. Die Prozedur b() ist daher abhängig von a(). Die Schnittstelle von a() wird geändert: Die zweite Version von a() besitzt einen zusätzlichen Parameter. Wenn nun die Prozedur b() überarbeitet wird, so kann sie entweder die Originalversion oder die modifizierte Version von a() aufrufen. Offensichtlich ist es aber nicht möglich, beide Versionen von a() in b() zu verwenden. Verfügbare Werkzeuge des Softwareentwicklungsprozesses wie Compiler und Linker sorgen für die Einhaltung dieser Bedingung. Im Planungsprozess sind solche die Konsistenz sichernden Werkzeuge nicht verfügbar. Es ist jedoch möglich, für den Graphen P entsprechende Konsistenzbedingungen zu formulieren. Formal müssen folgende zwei Bedingungen erfüllt sein:    ( ei z e j š ( ei , f i )  H ( B ) š ( e j , f i )  H ( B ) Ÿ Z ( ei ) z Z ( e j ))

ei M e j M fi M



 ( g i z g j š ( g i , g j )  H ( B ) Ÿ Z ( g i ) z Z ( g j ))

g i M g j M

(2) (3)

Bedingung (2) ist erfüllt, wenn keine Objektversion existiert, die von mehr als einer Version eines anderen Objekts abhängt. Bedingung (3) ist erfüllt, wenn keine Objektversion existiert, die von einer anderen Version desselben Objekts abhängt.

Verteilte Bearbeitung mit versionierten Produktmodellen im Bauwesen

139

Zwei ungültige Graphen sind in Abb. 2.3 dargestellt: Der linke Graph verletzt die Bedingung (2) und der rechte Graph verletzt die Bedingung (3).

Abb. 2.3. Ungültige Kantenmengen des Graphen P

Die Erfüllung dieser beiden Bedingungen stellt darüber hinaus sicher, dass das versionierte Planungsmaterial wie ein unversioniertes Planungsmaterial bearbeitet werden kann. Dies reduziert die Komplexität der Bearbeitung entscheidend. Operationen für die verteilte Bearbeitung Die Mengen des Projekts werden in einer verteilten Umgebung bearbeitet. In einer Mehrbenutzer-Umgebung muss ein geeignetes Konfliktmanagement bereitgestellt werden (Abb. 2.4). Die Bearbeitung beginnt mit der Selektion einer konsistenten Teilmenge des Projekts. Für jede selektierte Objektversion wird eine neue Objektversion abgeleitet und in den privaten Arbeitsbereich (engl.: Workspace) geladen. Die daran anschließende interaktive Bearbeitung kann eine beliebig lange Zeit dauern. Sie endet mit der Speicherung der bearbeiteten Objektversionen im Projekt. Die beschriebene Art der Bearbeitung entspricht einer langen Transaktion (engl.: long duration transaction) und ist im Gegensatz zu einer kurzen Transaktion auf der Basis verfügbarer Datenbanktechnik alleine nicht zu handhaben. laden Projekt

Workspace speichern

Abb. 2.4. Konfliktmanagement

Zur Repräsentation des Workspace muss der Graph P erweitert werden. Es ist jedoch ausreichend, einen einzigen Workspace zu betrachten. Dieser Ansatz ist sicher, da voraussetzungsgemäß (a) die strukturierten Mengen des Projekts nicht änderbar sind und (b) keine Relationen zwischen den verschiedenen Workspaces existieren: P : (: , M , ' , : , W ; Z , V , B , Z , V , B )

(4)

Die Knotenmenge : enthält die Objekte und die Knotenmenge W enthält die Objektversionen des Workspace. Die Abbildung Z : W o (: ‰ : ) ordnet jeder Ob-

140

Karl Beucke, Berthold Firmenich, Daniel G. Beer, Torsten Richter

jektversion ai  W des Workspace ein Objekt a  : des Projekts oder ein Objekt a :

des Workspace zu. Die Bearbeitungsrelation V Ž M ' u W' mit M ' : M ‰ ' und W' : W ‰ ' beschreibt die Herkunft und den Bearbeitungszustand der Objektversionen in W. Die Bearbeitungsrelation kann gemäß V V A ‰ V L ‰ V N in drei disjunkte Teilrelationen zerlegt werden. Die Relationen V A Ž M u W und V L Ž M u ' beschreiben aus M geladene Objektversionen. Dabei beschreibt die Relation V L diejenigen Objektversionen, die im Workspace logisch gelöscht wurden. Die Relation V N Ž ' u W beschreibt Objektversionen, die im Workspace W neu erzeugt wurden. Die Bindungsrelation B Ž ( M ‰ W ) u W enthält die Bindungen der Objektversionen in W. Es ist zu beachten, dass Objektversionen in W sowohl an Objektversionen in M als auch in W gebunden sein können. Die verteilte synchrone Bearbeitung wird auf eine feste Menge von Operationen – die Operationen für die verteilte Bearbeitung – zurückgeführt. Jede dieser Operationen hat Auswirkungen auf den Graphen P . Die Auswirkungen können formal mit Hilfe der Mengenlehre so formuliert werden, dass die Konsistenz des Graphen sichergestellt ist. Dies wird nachfolgend für drei ausgewählte Operationen gezeigt. Die Operationen für die verteilte Bearbeitung könnten die Basis für eine neue Sprache zur Unterstützung der Kooperation im Planungsprozess sein. Operation SELEKTIEREN Die Bearbeitung beginnt mit der Selektion einer Teilmenge der Objektversionen des Projekts S Ž M . Jedoch sind beliebige Teilmengen S nicht zulässig. Formal kann eine selektierbare Teilmenge S Ž M wie folgt definiert werden: S ist eine selektierbare Objektversionsmenge :œ  ( mi  M ) š



mi S

(5.1)

  (Z( mi ) Z( x j ) Ÿ mi x j ) š mi S x j S 

(5)

(5.2)

   (( mi , x j )  H ( B ) š Z( x j ) Z( y k ) Ÿ ( mi , y k )  H ( B )) š mi S x j M yk S  (5.3)

   (( x j , mi )  H ( B ) š Z( x j ) Z( y k ) Ÿ x j y k ) mi S x j M yk S  (5.4)

Definition (5) wird anhand des in Abb. 2.5 dargestellten Beispiels erläutert. Es enthält zwei Objektversionen p1 and p2 eines Punkts p und drei Objektversio-

Verteilte Bearbeitung mit versionierten Produktmodellen im Bauwesen

141

nen c1 , c2 und c3 eines Kreises c . Der Kreis hat ein Radius-Attribut r und der Mittelpunkt des Kreises ist an einen Punkt p gebunden:

Abb. 2.5. Beispiel für die Operation SELEKTIEREN

Bedingung (5.1) in Definition (5) stellt sicher, dass nur Objektversionen des Projekts selektierbar sind. Bedingung (5.2) sorgt dafür, dass maximal eine Objektversion eines Objekts selektierbar ist. Beispielsweise ist die Teilmenge S { p1 , p2 , c1 } nicht selektierbar. Bedingung (5.3) definiert die Selektierbarkeit von Objektversionen, die von selektierten Objektversionen abhängig sind: Falls in unserem Beispiel der Punkt p1 selektiert ist, dann darf entweder keine einzige Objektversion des Kreises c oder genau eine der beiden Objektversionen c1 und c2 selektiert sein. Bedingung (5.4) definiert die Selektierbarkeit von Objektversionen, von denen selektierte Objektversionen abhängig sind. Beispielsweise sind die Mengen S {c 2 } und S {c2 , p1} selektierbar. Die Menge S {c 2 , p2 } ist dagegen nicht selektierbar, da die beiden Elemente nicht zusammen gehören.

Operation LADEN Voraussetzungsgemäß darf die selektierte Objektversionsmenge S Ž M nicht direkt manipuliert werden. Stattdessen wird von jeder Objektversion in S eine neue Objektversion abgeleitet und in den Workspace geladen. Formal wird für jede Objektversion ai  S ein Nachfolger a j abgeleitet und folgendermaßen verarbeitet: W : W ‰ {a j }

(6)

V : V ‰ {( ai , a j )  M u W | Nachfolger a j von ai ist geladen}

(7)

Das Laden der Objektversionen alleine reicht jedoch nicht aus. Zusätzlich müssen neue geordnete Paare in die Bindungsrelation B eingetragen werden. Die Berechnung der neu einzutragenden Bindungspaare wird nachfolgend gezeigt. Falls beide Objektversionen der Bindung ( x k , yl )  M u M selektiert sind, so muss gemäß Abb. 2.6 a eine neue Bindung ( x l , y m )  W u W in B eingetragen werden:

142

Karl Beucke, Berthold Firmenich, Daniel G. Beer, Torsten Richter

B : B ‰ {( xl , y m )  W u W |   (( x k , xl ) V š ( yl , y m ) V š ( x k , yl )  B )} (8) x k S yl S

W:

xl

ym

laden M:

xk

yl

a) xk

W:

yl

yl laden

M:

ai

yk

b) ai

W:

yk

xk laden

M:

xj

yk

c) xj

yk

Abb. 2.6. Operation LADEN

Falls nur die gebundene Objektversion y k einer Bindung ( ai , y k )  M u M selektiert ist, so muss – wie in Abb. 2.6 b dargestellt – eine neue Bindung ( ai , yl )  M u W in B eingetragen werden. Die bindende Objektversion ist nicht zu laden, da bei einer Aktualisierung von yl  W die Attribute von ai  M nur gelesen werden müssen: B : B ‰ {( ai , yl )  M u W |   (( ai , a j ) V š ( y k , yl ) V š ( ai , y k )  B )} (9) yk S a j W

Falls nur die bindende Objektversion x j einer Bindung ( x j , y k )  M u M selektiert ist, so bleibt B unverändert (Abb. 2.6 c). Damit ist jedoch die gebundene Objektversion y k überholt. Diese Erkenntnis ist ein wesentlicher Schritt zur Reduktion der Komplexität des Problems.

Verteilte Bearbeitung mit versionierten Produktmodellen im Bauwesen

143

Operation MODERNISIEREN Der in Abb. 2.6 c dargestellte Fall der Operation LADEN führt zu einer überholten Objektversion y k . Überholte Objektversionen müssen im Planungsprozess zumindest zeitweise in Kauf genommen werden. Wegen der vielen Änderungen und der Abhängigkeiten des Planungsmaterials ist es nämlich in der Praxis unmöglich, das Objektmodell ständig aktuell zu halten. In (10) ist eine überholte Objektversion formal definiert. Die Menge der überholten Objektversionen U Ž M ist in (11) definiert: Objektversion ai  M ist überholt :œ 

 (( xi , ai )  B š ( xi , x j ) V )

xi M x j M

U : {ai  M | 

  (( xi , ai )  B š ( xi , x j )  V š ( ai , a j )  V )}

xi M x j M a j M

(10) (11)

Die Auswirkungen der Operation MODERNISIEREN auf die überholte Objektversion y k sind in Abb. 2.7 dargestellt: Die modernisierte Objektversion yl ist nur an Objektversionen ohne Nachfolger gebunden.

Abb. 2.7. Operation MODERNISIEREN

2.4.2 Beschreibung mit einer Mengenalgebra Ergebnis des vorherigen Abschnitts ist eine mengentheoretische Formulierung des Lösungsansatzes. Die dort identifizierten Operationen für die verteilte Bearbeitung werden nun durch die Grundoperationen einer Mengenalgebra formuliert. Durch die klare Semantik der Grundoperationen der Algebra wird die Formulierung der Operationen für die verteilte Bearbeitung transparent und nachvollziehbar. Jede Operation der Mengenalgebra liefert eine Menge zurück. Mit den drei Grundoperatoren für Vereinigung, Durchschnitt und Komplement lassen sich alle übrigen Mengenoperationen formulieren. Ein attributbasierter Lösungsansatz wurde als gemeinsamer Nenner zwischen allen möglichen Anwendungsmodellen ausgewählt. Im Bereich der Wissensrepräsentation hat (Smolka 1992) eine mathematische Theorie mit dem Namen FeatureLogic entwickelt. Die Eignung der Feature-Logic für die Versionierung im Software Configuration Management wurde von (Zeller 1997) gezeigt.

144

Karl Beucke, Berthold Firmenich, Daniel G. Beer, Torsten Richter

Feature-Logic stützt sich auf eine Domäne D I , die alle benutzten Elemente enthält. Die Domäne besteht aus genau zwei disjunkten Untermengen: der Menge der primitiven Elemente oder Atome und der Menge der nicht-primitiven Elemente. Primitive Elemente beinhalten einen einfachen Wert eines einfachen Datentyps wie Ganzzahl oder Text. Alle anderen Elemente sind nicht-primitiv.

Abb. 2.8. Feature-Graph

Ein nicht-primitives Element kann mit einem Element der Domäne über ein beliebiges Feature in Beziehung stehen. Abb. 2.8 zeigt einen einfachen Feature-Graph. Das Objekt o und der Wert v sind als Knoten dargestellt und das Feature f als gerichtete Kante von o nach v. Ein Feature f ist formal definiert: f I : {(o, v )  D I u D I | Objekt o hat ein Feature f mit dem Wert v}

(12)

Es sollen hier nur einige der Basisoperationen der Algebra aufgezeigt werden. Die Operation Selection f:S (13.1) ist die fundamentale Operation der Feature-Logic und bezeichnet die Menge der Objekte, deren Feature f den Wert eines Elements der durch S beschriebenen Menge hat. Die Operation Extraction f(S) (13.2) bezeichnet die Menge der Objekte, die Wert des Features f der durch S beschriebenen Objekte sind. Die Bedeutung von Durchschnitt (13.3), Vereinigung (13.4) und Komplement (13.6) sind allgemein bekannt. Eine vollständige Aufzählung aller Operationen ist in (Smolka 1992) und (Zeller 1997) zu finden. ( f : S ) I : {x  D I |  ( x , s )  f I }

(13.1)

( f ( S )) I : {x  D I |  ( s, x )  f I }

(13.2)

(S ˆ T )I : S I ˆ T I

(13.3)

(S ‰ T )I : S I ‰ T I

(13.4)

(~ S ) I : D I  S I

(13.5)

sS I

sS I

Die Anwendung der Feature-Logic auf den Lösungsansatz ist in (Firmenich 2005) ausführlich beschrieben.

Verteilte Bearbeitung mit versionierten Produktmodellen im Bauwesen

145

2.4.3 Systemarchitektur Das in Abb. 2.4 angedeutete Konfliktmanagement in einer verteilten Umgebung wird in diesem Abschnitt durch die konkrete Ausgestaltung einer Systemarchitektur beschrieben. Als Ansatz wird das gemeinsame Arbeitsmaterial der Beteiligten nicht als Dokumentmenge, sondern als Menge von Elementversionen und Objektversionen und deren Beziehungen abstrahiert. Die Trennung von Objekten und Elementen resultiert aus der applikationsspezifischen Implementierung der Objekteigenschaften (Attribute), über die keine gemeinsame Struktur des Planungsmaterials gebildet werden kann. Mit den Elementeigenschaften (Features) können applikationsübergreifend Bindungen, Versionsbeziehungen sowie spezifische Applikationsund Anwendereigenschaften modelliert und so das Objektmodell ohne Änderung der Klassen erweitert werden. In (Beer 2006) werden weitere Operationen der Mengenalgebra in Verbindung mit der Versionierung und den Bindungen beschrieben sowie ein Konzept für fachspezifische Erweiterungen gezeigt. Die Teilmengenbildung erfolgt mit Hilfe einer Sprache, für die bei vorliegender Grammatik ein Interpreter automatisch erzeugt werden kann. Die Grammatik der Feature-Logic wurde in Backus-NaurForm (BNF) formuliert und in einen entsprechenden Interpreter umgesetzt. Mit diesem können Ausdrücke interpretiert und in eine Sprache übersetzt werden, die auf dem Datenspeicher, der dem persistenten Datenmodell zugrunde liegt, angewendet werden kann. Durch Verwendung von Standards, zum Beispiel SQL oder JDOQL, kann vom konkreten Datenspeicher oder sogar von dem Typ des Datenspeichers abstrahiert werden. Die Bearbeitung wird auf Operationen (Abb. 2.9) zurückgeführt, mit denen das gemeinsame Arbeitsmaterial konsistent gehalten wird. Die Operationen lehnen sich an Versionsverwaltungssysteme aus dem Bereich der Softwareentwicklung an.

Abb. 2.9. Operationen

Der entwickelte Systementwurf beschreibt allgemein den Aufbau eines Softwaresystems für die verteilte Bearbeitung im Bauplanungsprozess. Er besteht aus Komponenten mit Schnittstellen, über die Daten ausgetauscht werden und Opera-

146

Karl Beucke, Berthold Firmenich, Daniel G. Beer, Torsten Richter

tionen, die den Komponenten zugeordnet sind und deren konsistente Bearbeitung sichern. Operationen bearbeiten Modelle und synchronisieren sie untereinander. Es wird ein Ebenenkonzept vorgeschlagen, das die Komponenten vertikal in die Aspekte lokale und zentrale Anwendung sowie horizontal in Anwendung und Modell einteilt (Abb. 2.10). Die lokale Anwendung lässt sich in eine fachliche und eine Verwaltungskomponente, das Modell in eine logische und eine physische Ebene teilen.

Abb. 2.10. Systemarchitektur

Die lokale Fachanwendung ist eine bestehende Ingenieuranwendung, die für die verteilte Bearbeitung erweitert wird. Die lokale Verwaltung übernimmt der Workspace, der die Verteilung durch Kommunikation mit der zentralen Anwendung – dem Projekt – realisiert. Auf Modellebene werden die Daten der Fachapplikation im Objektmodell, die Elemente des Workspace in der Sandbox und die Objekt- und Elementversionen des Projekts im Repository logisch strukturiert. Das zugrunde liegende physische Modell ist der Arbeitsspeicher bzw. ein Datenspeicher. Der Aufbau der Modelle und die Semantik der Operationen wird unabhängig von Technologie formal mit Hilfe der Mengen- und Relationenalgebra beschrieben. Es wird auch vom Systementwurf abstrahiert, so dass dieser modifiziert werden kann. Basis ist jedoch der Ansatz der Versionierung und der Trennung von Objekten und Elementen (Abb. 2.11). Es zeigt sich, dass die applikationsspezifischen Beziehungen zwischen Objekten (Referenzen) nicht zusätzlich zu den Objekteigenschaften als Features zu modellieren sind. Dies liegt vor allem an der Größe und Komplexität von Ingenieurmodellen. Als Lösung werden Teilmodelle vorgeschlagen. Zwischen Objekten verschiedener Teilmodelle dürfen keine Referenzen bestehen. Dies ist vergleichbar mit Dokumenten, jedoch viel flexibler: Bindungen zwischen Elementen verschiedener Teilmodelle sind möglich, so dass applikationsübergreifend Beziehungen modelliert werden können, die auch bei der Selektion berücksichtigt werden. Selektionsmengen sind eine Vereinigung von Teilmodellversionen, da garantiert

Verteilte Bearbeitung mit versionierten Produktmodellen im Bauwesen

147

werden muss, dass alle referenzierten Objekte durch die Selektionsmenge erfasst wurden.

Abb. 2.11. Mathematisches Modell

Für das Umsetzungskonzept (Abb. 2.12) wird eine Kombination von Eigenentwicklung und Nutzung von Standardtechnologie vorgeschlagen. Für die Versionierung der Objekte kommt ein Versionsverwaltungswerkzeug zum Einsatz, das die Änderungen an den Objektversionen sehr effizient über ein Netzwerk überträgt und speichert. Da solche Systeme jedoch keinen geeigneten und performanten Mechanismus zur Teilmengenbildung bieten und keinen allgemeinen Versionsgraphen verwalten, werden parallel dazu die Elementversionen in einer relationalen Datenbank gespeichert. Eine relationale Datenbank wurde gewählt, da sie für die Verwaltung von Massendaten mit einfacher Struktur sehr gut geeignet ist und eine standardisierte Zugriffssprache (Schnittstelle) besitzt. Beides liegt vor: Durch die Versionierung entstehen viele Daten und das Element-Feature-Modell ist sehr einfach und generisch über wenige Mengen und Relationen beschreibbar. Für die Auswahl eines Datenspeichers spielt die Komplexität eine wesentliche Rolle. Diese beschreibt den Zusammenhang zwischen Eingangsdaten und benötigten Ressourcen eines Algorithmus. Eingangsdaten sind im Allgemeinen die Modellgröße, die wichtigsten Ressourcen sind die erforderliche Zeit und der benötigte Arbeitsspeicher. Die Modellgröße wurde an Beispielen für die Sandbox und das Repository abgeschätzt, so dass geeignete Datenspeicher ausgewählt werden können (Beer 2006).

148

Karl Beucke, Berthold Firmenich, Daniel G. Beer, Torsten Richter

Abb. 2.12. Umsetzungskonzept - Systemarchitektur

Die Systemarchitektur wurde pilothaft mit ausgewählter Technologie implementiert. Dies erfolgte in der Umgebung des Internet in der Sprache Java. Als Fachapplikation wurde die CAD-Applikation CADEMIA verwendet, da sie ebenfalls in der Sprache Java implementiert und sehr leicht zu erweitern ist (CADEMIA 2006). 2.4.4 Anwendungsbeispiel Als Beispiel wird das Zusammenspiel zwischen einer Wand mit Öffnungen und Türen in den Öffnungen betrachtet (Abb. 2.13). Die Wand wird durch eine Klasse W, die Öffnung durch eine Klasse O und die Tür durch eine Klasse T abstrahiert. Alle nutzen eine Klasse P für einen Einfügepunkt.

Abb. 2.13. Szenario – Modell

Die genannten Klassen definieren folgende Attribute:

x Wand: Einfügepunkt (ep) vom Typ P, drei atomare Attribute für die Länge (l), Breite (b) und Höhe (h) und ein Feld von Öffnungen (oeffnungen)

x Öffnung: Einfügepunkt (ep) vom Typ P und zwei atomare Attribute für die Länge (l), und Höhe (h). Die Dicke wird nicht als Eigenschaft modelliert, da sie von der Wand, in der sich die Öffnung befindet, übernommen wird.

Verteilte Bearbeitung mit versionierten Produktmodellen im Bauwesen

149

x Tür: Einfügepunkt (ep) vom Typ P und zwei atomare Attribute für die Länge (l), und Höhe (h). Zwischen Öffnung und Tür wird auf Klassenebene die Beziehung, dass beide die gleiche Länge und Höhe haben müssen, nicht abgebildet, da die Klassen zu unterschiedlichen Applikationen gehören. Die Objekte werden um Features erweitert, so dass ihnen gleichnamige Elemente zugeordnet sind. Alle Elemente haben die Features breite und hoehe. Die Wand hat noch eine dicke und eine richtung, die Öffnung eine wand, zu der sie gehört, und eine dicke, die Tür hat zusätzlich das Feature anschlag.

Abb. 2.14. Szenario – Objekte, Elemente und Teilmodelle

Zwischen den Elementen existieren Bindungen, die folgende Zusammenhänge repräsentieren (Abb. 2.14):

x Wand-Öffnung: Die Wand ist abhängig von der Öffnung: Ändert sich die Geometrie der Öffnung, so muss die Wand als Gesamtkörper neu berechnet werden. Ändert sich die Wanddicke, so hat dies keine Auswirkung auf die Öffnung selbst, sondern nur auf deren Wirkung in der Wand. x Tür-Öffnung: Die Tür ist abhängig von der Öffnung: Ändert sich die Geometrie der Öffnung, so muss sich auch die der Tür anpassen. Um Zyklen zu vermeiden, wird von dem Fall, dass sich natürlich auch die Öffnung bezüglich der Tür ändern können muss, abgesehen. Dies müsste über ein spezielles Konnektor-Element realisiert werden, von dem sowohl Öffnung als auch Tür abhängig sind. x Wand-Tür: Die Breite der Türzarge soll unabhängig von der Wanddicke sein (L-Zarge), um das Szenario überschaubar zu halten. Dazu wird der Türrahmen von einer Wandseite ausgehend mit einer feststehenden Breite der Zarge befestigt. Die Wand und die Öffnung gehören zum Teilmodell Rohbau, der durch einen Architekten geplant wird. Die Tür gehört zum Teilmodell Ausbau. Dieser wird von einem Ausbauplaner geplant. Die Teilmodelle spiegeln zwei unterschiedliche Ap-

150

Karl Beucke, Berthold Firmenich, Daniel G. Beer, Torsten Richter

plikationsmodelle wieder, zwischen denen keine Referenzen auf Objektebene bestehen können, so dass nicht alle Zusammenhänge modelliert werden können. Die Konsistenz des Modells lässt sich jedoch durch Erweiterung um Elemente und Bindungen erreichen. Bindungen sind auch zwischen Teilmodellen möglich. Von den oben beschriebenen Klassen werden eine Wand w_1, eine Öffnung o_1 und eine Tür t_1 erzeugt, die zu einem Büroraum gehören. Dieser soll in einen Lagerraum umgenutzt werden. Dazu ist die Tür zu vergrößern und die Wand aufgrund von Brandschutzanforderungen zu verstärken. Das Szenario zeigt die applikationsübergreifende Bearbeitung unterschiedlicher Teilmodelle mit unterschiedlichen Applikationen. Der Architekt erhöht die Dicke der Wand und vergrößert die Öffnung. Der Ausbauplaner vergrößert die Öffnung ebenfalls, aber unabhängig vom Architekten, da beide unterschiedliche Applikationen verwenden und synchron arbeiten. Im Repository befinden sich drei Objektversionen (w_1, o_1 und t_1) und drei gleichnamige Elementversionen. Zwischen den Objektversionen der Wand und der Öffnung besteht eine Referenz, zwischen den Elementversionen der Öffnung und der Wand sowie der Tür existiert eine Bindung (Abb. 2.15).

Abb. 2.15. Repository – Ausgangszustand

Der Architekt möchte das Teilmodell „Ausbau“ bearbeiten und selektiert dieses durch eine entsprechende Anfrage: "in:Ausbau". Der Ausbauplaner möchte die Tür bearbeiten. Er weiß, dass diese als einzige eine Eigenschaft anschlag hat und formuliert deshalb die Anfrage "anschlag:[ ]" 1 Die Elementversion der Öffnung muss zusätzlich schreibgeschützt selektiert werden, da sie von der Türversion abhängig ist, aber nicht zum gleichen Teilmodell gehört. Nach dem Holen der selektierten Element- und Objektversionen werden neue Versionen in der jeweiligen Sandbox der beiden Planer erzeugt. Der Architekt hat je ein Element und ein Objekt für die Wand und die Öffnung in seiner Sandbox. Der Ausbauplaner hat ein Element und ein Objekt für die Tür sowie ein schreibgeschütztes Element für die Öffnung (Abb. 2.16).

Abb. 2.16. Sandbox – Zustand nach dem Holen

1

f:[] steht für die Operation Existence, die die Menge aller Objekte, die ein Feature f besitzen, zurückliefert

Verteilte Bearbeitung mit versionierten Produktmodellen im Bauwesen

151

Der Architekt vergrößert die Dicke der Wand und die Höhe der Öffnung. Der Ausbauplaner ändert unabhängig vom Architekten die Breite der Tür (Abb. 2.17). Der Architekt überträgt seine Ergebnisse ins Repository (Abb. 2.18). Sie werden als Element- bzw. Objektversionen mit dem Index _2 gekennzeichnet. Zwischen den Elementversionen wird die Bearbeitungsgeschichte im Versionsgraphen gespeichert. Das betrifft die Paare (w_1, w_2) und (o_1, o_2).

Abb. 2.17. Szenario – Bearbeitung

Abb. 2.18. Repository mit Ergebnissen des Architekten

Der Ausbauplaner wird über die Ergebnisse des Architekten informiert und aktualisiert seine Ergebnisse. Er entscheidet sich für die Übernahme der Öffnungsmaße des Architekten. Er bekommt eine aktuelle Version seiner schreibgeschützten Elementversion der Öffnung und wählt eine der Öffnung entsprechende Tür aus. Seine Version der Tür ist nun an die aktuelle Version der Öffnung gebunden (Abb. 2.19).

Abb. 2.19. Sandbox – Aktualisierte Ergebnisse des Ausbauplaners

Der Ausbauplaner überträgt seine Ergebnisse ins Repository (Abb. 2.20). Sie werden als Element- bzw. Objektversion mit dem Index _2 gekennzeichnet. Zwischen den Elementversionen wird die Bearbeitungsgeschichte im Versionsgraphen als Paar (t_1, t_2) gespeichert. Zwischen den Objektversionen lässt sich die Bearbeitungsgeschichte nur anhand der gleichnamigen Elementversionen ablesen.

152

Karl Beucke, Berthold Firmenich, Daniel G. Beer, Torsten Richter

Abb. 2.20. Repository mit Ergebnissen beider Planer

2.5 Zusammenfassung und Fazit Innerhalb des Projekts interCAD wurden die Grundlagen der verteilten Bearbeitung für den Bauplanungsprozess erforscht und darauf aufbauend eine Systemarchitektur entwickelt und umgesetzt, die in ihrem Grundsatz alle Phasen der verteilten Bearbeitung und alle Arten der Kooperation berücksichtigt. Bei diesem Ansatz wird das gemeinsame Arbeitsmaterial der Beteiligten nicht als Dokumentmenge, sondern als Menge von Elementversionen und Objektversionen und deren Beziehungen abstrahiert. Mit den Elementeigenschaften (Features) können anwendungsübergreifend Bindungen, Versionsbeziehungen sowie spezifische Applikations- und Anwendereigenschaften modelliert und so das Objektmodell ohne Änderung der Klassen erweitert werden. Die Bearbeitung wird auf Operationen zurückgeführt, mit denen das gemeinsame Arbeitsmaterial konsistent gehalten wird. Die Operationen lehnen sich an Versionsverwaltungssysteme aus dem Bereich der Softwareentwicklung an. Sie sind auf diesem Gebiet Stand der Technik und unterstützen die verteilte Entwicklung von Software auf Basis der Versionierung des Quellcodes in einer Historie. Beim Prozess der Bearbeitung des Planungsmaterials treten Änderungen auf. Diese sind durch die Versionierung nachvollziehbar und können später analysiert werden. Im Bauprozess vorgeschriebene Revisions- und Freigabestände sind abbildbar. Ein Ziel des Schwerpunktprogramms 1103 ist es, die Planungsprozesse des Konstruktiven Ingenieurbaus für die Nutzung verteilter Ressourcen zu gestalten. Mit der im Projekt entwickelten Systemarchitektur können bestehende Ingenieuranwendungen relativ einfach durch eine Erweiterung um die Komponente für das verteilte Bearbeiten integriert werden. Das heißt, die bestehenden Prozesse werden nicht radikal geändert, sondern können evolutionär weiterentwickelt werden. Jedoch erfordert die gestiegene Komplexität des Planungsprozesses eine entsprechende Ausbildung der eingebundenen Fachplaner.

Literatur Beer DG (2006) Systementwurf für verteilte Applikationen und Modelle im Bauplanungsprozess. Dissertation, Bauhaus-Universität Weimar Beer DG, Firmenich B (2003) Freigabestände von strukturierten Objektversionsmengen in Bauprojekten. In: Digital Proceedings des Internationalen Kolloquiums über Anwen-

Verteilte Bearbeitung mit versionierten Produktmodellen im Bauwesen

153

dungen der Informatik und Mathematik in Architektur und Bauwesen (IKM), Bauhaus-Universität Weimar Beer DG, Firmenich B, Beucke K (2006) A system architecture for net-distributed applications in civil engineering. In: Proceedings of the Eleventh International Conference (ICCCBE-XI), Montreal Beucke K (2001) CAE im Planungsprozess. Skript, Bauhaus-Universität Weimar Boukamp F (2001) Bereitstellung von CAD-Funktionalität für Ingenieuranwendungen als Komponenten der Benutzeroberfläche. Diplomarbeit, Bauhaus-Universität Weimar CADEMIA (2006) Open Source Ingenieurplattform (http://www.cademia.org/), Stand 2006 Firmenich B, Beucke K (2006) CAD in Computer Aided Civil Engineering: a Particular Approach for Research and Education. In: International Journal of IT in Architecture, Engineering and Construction (IT-AEC), Millpress, Rotterdam Firmenich B (2002) CAD im Bauplanungsprozess: Verteilte Bearbeitung einer strukturierten Menge von Objektversionen. Dissertation, Shaker, Aachen Firmenich B (2002a) Operations for the distributed synchronous cooperation of a shared versioned data model in the planning process. Computing in Civil and Building Engineering: Proceedings of the Ninth International Conference (ICCCBE-IX), Taipei Firmenich B (2005) Consistency of a Shared Versioned Model for Distributed Cooperation. In: Computer-Aided Civil and Infrastructure Engineering Firmenich B, Koch C, Richter T, Beer DG (2005) Versioning structured object sets using text based Version Control Systems. In: Proceedings of 22nd CIB-W78 Conference on Information Technology in Construction, Institute of Construction Informatics, Dresden, pp 105–112 Koch C (2004) Abhängigkeiten im CAD am Beispiel der Baubemaßung. Diplomarbeit, Bauhaus-Universität Weimar Nour MM, Firmenich B, Richter T, Koch C (2006) A versioned IFC database for multidisciplinary synchronous cooperation. In: Proceedings of the Eleventh International Conference (ICCCBE-XI), Montreal Olbrich M (1998) Relationenorientiertes Modellieren mit Objekten in der Bauinformatik. VDI, Düsseldorf Pahl PJ, Beucke K (2000) Neuere Konzepte des CAD im Bauwesen: Stand und Entwicklungen. Digital proceedings des Internationalen Kolloquiums über Anwendungen der Informatik und Mathematik in Architektur und Bauwesen (IKM), Bauhaus-Universität Weimar Pahl, PJ, Damrath R (2000) Mathematische Grundlagen der Ingenieurinformatik. Springer, Berlin Ramunno E (2005) Vergleich und Zusammenführung unterschiedlicher Planungsstände. Bachelorarbeit, Bauhaus-Universität Weimar Richter T, Beucke K (2006) Diff and Merge For Net-distributed Applications In Civil Engineering. In: Proceedings of the Eleventh International Conference (ICCCBE-XI), Montreal Richter T, Beer DG (2004) Eine grafische Nutzerschnittstelle für versionierte Objektmodelle. In: Forum Bauinformatik 2004. Shaker, Aachen, S 264–271 Richter T, Firmenich B; Beucke K (2003) Ein Java-Paket zur Verarbeitung von Datenstrukturen in beliebigen Datenquellen. In: Tagungsband zum 15. Forum Bauinformatik, Shaker, Aachen, S 136–146 Schäfer S (2006) Vergleichen und Zusammenführen von objektorientierten Ingenieurmodellen. Diplomarbeit, Bauhaus-Universität Weimar Smolka G (1992) Feature constraint logics for unification grammars. The journal of logic programming, New York Turau V (1996) Algorithmische Graphentheorie. Addison-Wesley, Bonn

154

Karl Beucke, Berthold Firmenich, Daniel G. Beer, Torsten Richter

Zeller A (1997) Configuration Management with Version Sets. Dissertation, Technische Universität Braunschweig

3 Graphbasierte Werkzeuge zur Unterstützung des konzeptuellen Gebäudeentwurfs

Bodo Kraft, Manfred Nagl Lehrstuhl für Informatik 3, RWTH Aachen {kraft | nagl}@i3.informatik.rwth-aachen.de

3.1 Einleitung Heutige CAD-Werkzeuge bieten dem Architekten umfassende Unterstützung bei der Planung und Erstellung eines Bauwerks. Die Konstruktion kann in verschiedenen Ansichten und Detaillierungsgraden dargestellt werden, durch die Vergrößerung und Verkleinerung der Ansicht lassen sich sowohl Details angemessen bearbeiten als auch eine Übersicht über das zu planende Bauwerk darstellen. Als Hilfsmittel für die Erstellung eines konstruktiven Entwurfsplans stehen dem Architekten Modellelemente für die wichtigsten Bauteile zur Verfügung. Im Gegensatz zur Unterstützung bei der Erstellung der Konstruktion eines Bauwerks wird der zugrunde liegende konzeptuelle Gebäudeentwurf von den heute aktuellen CAD-Werkzeugen nahezu überhaupt nicht berücksichtigt. Der konzeptuelle Entwurf abstrahiert von der reinen Konstruktion der Zeichnungselemente und stellt deren Funktion in einem Gebäude in den Vordergrund. Damit kann die Funktionsweise und Organisation zunächst unabhängig von einer exakten und vollständigen Konstruktion modelliert werden. Rein konstruktiv ist es durchaus möglich Gebäude zu erstellen, in denen Räume nicht zugänglich sind oder Bauvorschriften verletzt werden. Die Identifikation solcher Entwurfsfehler ist ohne die Kenntnis des Gebäudekonzepts nur schwer möglich. Der Architekt erhält durch das CAD-Werkzeug keine Unterstützung bei Fehlerfindung und -korrektur. Der konzeptuelle Gebäudeentwurf zielt von Beginn an darauf ab, ein möglichst gut funktionierendes Gebäude zu entwerfen, das allen geltenden Forderungen und Einschränkungen entspricht. Mangels der angemessenen Unterstützung während der frühen Entwurfsphase weichen viele Architekten entweder auf einfache Zeichenprogramme oder die klassische Papierskizze aus. In dieser informellen Repräsentation entwirft der Ar-

156

Bodo Kraft, Manfred Nagl

chitekt auf grobem Niveau die Gestalt und Funktionsweise des Gebäudes. Erst in einem zweiten Schritt wird die informelle Skizze in ein CAD-Werkzeug übertragen. Die in der informellen Skizze implizit gespeicherte konzeptuelle Information geht bei dieser Übertragung verloren, da die CAD-Werkzeuge diese nicht abbilden können. Bei Änderungen, Rückschritten und Wiederverwendung der Entwürfe fehlen schließlich die grundlegenden Informationen zur Sicherstellung der Konsistenz eines Bauwerks. Trotz der frühen Entwurfsphase sind bereits umfassende Anforderungen und Restriktionen für die Erstellung des Bauwerks geltend. Ein Großteil dieser Restriktionen ist für die konzeptuelle Entwurfsphase relevant und muss von dem Architekten beachtet werden. Entsprechend der Komplexität und Vielseitigkeit sowie dem interdisziplinären Charakter architektonischer Entwürfe ist Fachwissen aus unterschiedlichen Bereichen zu berücksichtigen. Die Nichtbeachtung des für den konzeptuellen Gebäudeentwurf geltenden Regelwissens stellt eine Gefährdung des gesamten Projekterfolgs dar, zumindest verursachen konzeptuelle Fehlentscheidungen erhebliche Mehrkosten durch die nötige Korrektur in den späteren Phasen. Die hier vorgestellten Konzepte untermauern die Notwendigkeit für eine Unterstützung des konzeptuellen Entwurfs. Das Projekt „Neue Software-Werkzeuge zur Unterstützung des konzeptuellen Gebäudeentwurfs“ hat im Rahmen des DFGSchwerpunktprogramms 1103 „Vernetzt-kooperative Planungsprozesse im Konstruktiven Ingenieurbau“ (Meißner u. Rüppel 2006) diese Thematik in der Zeit von 2002–2006 erforscht. Die Projektergebnisse bieten eine theoretische Basis und validierte Vorschläge für deren Umsetzung in einem CAD-Werkzeug.

3.2 Ziele des Projekts Die Anforderungen für eine Unterstützung des konzeptuellen Entwurfs liegen in zwei Bereichen. Erstens muss die Erstellung und Verarbeitung konzeptueller Entwurfsskizzen durch Software-Werkzeuge ermöglicht werden, sodass der Architekt bei der Lösung eines Entwurfsproblems angemessen unterstützt wird. Die kreative Arbeit, die kein algorithmisches Vorgehen ermöglicht sondern vielmehr stark visuell und experimentell geprägt ist, muss durch einfach und intuitiv zu verwendende Konzepte gefördert werden. Zeitaufwändige Eingaben und Routinearbeiten zur Erstellung von Detaillösungen müssen vermieden werden. Die Eingabe konzeptueller Entwurfsskizzen muss die schnelle Evaluierung mehrerer Alternativen ermöglichen und die Ergebnisse angemessen visualisiert darstellen. Hierdurch lassen sich nicht nur die eigenen Entwürfe prüfen, die Visualisierung ermöglicht zudem die schnelle Rückkopplung mit dem Auftraggeber. Als zweite Anforderung muss die Formalisierung und Verwendung konzeptuellen Fachwissens ermöglicht werden. Die hier zu entwickelnden SoftwareWerkzeuge müssen die Möglichkeit bieten, schnell und einfach das konzeptuell relevante Fachwissen einzugeben, um später darin navigieren und suchen zu können. Die Aussagekraft muss für die Formalisierung der konzeptuell relevanten Vorschriften angemessen sein.

Unterstützung des konzeptuellen Gebäudeentwurfs

157

Als weiterführende Unterstützung soll eine Prüfung der konzeptuellen Entwurfsskizzen gegen das Fachwissen erreicht werden. Fehlende Anforderungen sowie missachtete Verbote sollen dadurch automatisiert identifiziert und visualisiert werden. Die Gefahr, geltende Regeln wegen Unkenntnis oder Unachtsamkeit zu verletzen, wird dadurch stark reduziert. Zur Umsetzung dieser Anforderungen wurden zwei Projekte beantragt. Das erste Projekt hatte das Ziel, eine Unterstützung des konzeptuellen Entwurfs und des zugrunde liegenden Fachwissens zu erarbeiten. Dieses Projekt wurde gefördert und wird im Folgenden beschrieben. In dem zweiten Projekt sollte eine neue Spezifikationsmethodik erarbeitet sowie das PROGRES-System erweitert werden. Das hierfür definierte Arbeitsprogramm konnte mangels einer Förderung nicht bearbeitet werden. Einige der Ziele konnten dennoch erreicht werden. Das Ziel, Unterstützung für die konzeptuelle Entwurfsphase zu erarbeiten sollte durch zwei unterschiedliche Ansätze, Top-Down und Bottom-Up, verfolgt werden. Der Top-Down-Ansatz beschreibt hierbei eine zunächst wissenschaftliche Herangehensweise zur Neukonzeption erweiterter Funktionalität für die konzeptuelle Entwurfsphase. Ein Hauptziel besteht darin, die Struktur und Semantik konzeptuellen Fachwissens, eines konzeptuellen Entwurfsplans sowie der dazwischen liegenden Konsistenzanalyse formal zu modellieren. In diesem grundlagenorientierten Ansatz wird das Graphersetzungssystem PROGRES (Schürr 1991) und das UPGRADE-Rahmenwerk (Böhlen et al. 2002) zur Spezifikation und Ableitung graphbasierter visueller Werkzeuge verwendet. Der Bottom-Up-Ansatz hat das Ziel, durch eine anwendernahe Vorgehensweise und durch direkten Praxisbezug, die Anforderungen für neue Werkzeugfunktionalität zu erarbeiten. Die neu entwickelten Konzepte zur Unterstützung des Architekten sollen in ein existierendes CAD-Werkzeug eingebettet werden. Die umfangreiche bereits existierende Funktionalität der CAD-Werkzeuge soll hierbei verwendet werden, um zeitaufwändige Nachimplementierungen zu vermeiden. Durch den geringen Einarbeitungsaufwand ist eine höhere Anwenderakzeptanz zu erwarten und schnelle Rückkopplung zwischen Werkzeugentwickler und Architekt möglich.

3.3 Geleistete Arbeiten Dieser Abschnitt umfasst die Ergebnisse der Projektbearbeitung. Im ersten Teilabschnitt erfolgt die Definition eines Szenarios, aus dem beide Projektteile sowie deren Zusammenhang hervorgehen. Anschließend stellt der zweite Teilabschnitt die erarbeiteten Konzepte und eine Werkzeugunterstützung für die Erstellung konzeptueller Entwurfspläne vor. Im dritten Teilabschnitt werden die Ergebnisse zur Formalisierung und Verwendung konzeptuellen Fachwissens erläutert. Die Beschreibung der Ergebnisse erfolgt anhand realistischer Beispiele. Die interne Modellierung und Realisierung ist in den jeweils angegebenen Veröffentlichungen zu finden.

158

Bodo Kraft, Manfred Nagl

3.3.1 Szenario Zur Unterstützung des konzeptuellen Entwurfs ist eine umfassende Analyse der frühen Entwurfsphase erforderlich. Entscheidend sind hierbei die Aufgaben und die Lösungsstrategien der beteiligten Akteure sowie deren Zusammenspiel. Die Identifikation von Rollen mit disjunkten Aufgabenbereichen erleichtert als idealisiertes Modell die Gliederung des Projekts und verdeutlicht die jeweiligen Schwerpunkte (Kraft u. Nagl 2003c). Die Systemarchitektur des Projekts besteht aus zwei Hauptteilen. Der erste Projektteil befasst sich mit der Unterstützung bei der Erstellung konzeptueller Entwurfspläne. Im zweiten Projektteil werden neue Methoden und Werkzeuge zur Verarbeitung konzeptuellen Fachwissens erarbeitet. Beide Projektteile stellen für sich bereits einen wertvollen Beitrag zur Unterstützung der konzeptuellen Entwurfsphase dar. Die Integration, die eine Prüfung der konzeptuellen Entwurfspläne gegen das formalisierte Fachwissen ermöglicht, verbindet die neue Funktionalität beider Ansätze und bietet dadurch einen erheblichen Mehrwert. Raum

Fehler !

...

Analyse Warnung ! Zugang

Raum

Architekt

Raum

Rückkopplung Raum ...

Wissensingenieur

Größe ...

Hinweis !

Abb. 3.1. Szenario für die Unterstützung des konzeptuellen Entwurfs

Durch die Möglichkeit der Abstraktion von der vollständigen und korrekten konstruktionsorientierten Darstellung eines Entwurfsplans wird der Architekt in die Lage versetzt, sich zunächst auf die wesentlichen Komponenten eines Gebäudeentwurfs und auf deren Zusammenspiel zu konzentrieren (Schmitt 1993). Die Abstraktion erlaubt die Betrachtung der Organisation und Funktionsweise eines Gebäudes, d. h. es wird im Gegensatz zu der einfachen konstruktionsorientierten Sichtweise eine semantische Betrachtung eines Entwurfsplans ermöglicht. In Abb. 3.1 ist auf der linken Seite die Erstellung eines konzeptuellen Entwurfsplans durch den Architekten schematisch dargestellt. Die rechteckigen Quader symbolisieren die für eine bestimmte Gebäudeklasse verwendeten funktionalen Einheiten. Die funktionalen Einheiten werden, symbolisiert durch Kanten, in Bezug zu einander gesetzt. Die Beziehungen sind von unterschiedlichem Typ und können gerichtet oder ungerichtet sein, um den entsprechenden konzeptuellen Sachverhalt abzubilden. Entsprechend der Vorgehensweise des Architekten werden funktionale Einheiten einfach oder ineinander verschachtelt konstruiert.

Unterstützung des konzeptuellen Gebäudeentwurfs

159

Der zweite Projektteil befasst sich mit der Formalisierung und Interpretation konzeptuellen Fachwissens. Im Rahmen dieses Projektteils wird ein Wissensingenieur in die Lage versetzt, konzeptuell relevantes Fachwissen in grafischer Form formal eingeben zu können. Es besteht die Anforderung, dass der Wissensingenieur ein Domänenexperte ist. Für den konzeptuellen Gebäudeentwurf soll der Wissensingenieur ein erfahrener Architekt bzw. ein Bauingenieur sein. Im Gegensatz zu den klassischen Ansätzen der Wissensverarbeitung ist das Fachwissen nicht durch den Werkzeugentwickler fest in die Applikation eingebettet. Zur Formalisierung des Fachwissens ist zudem keine Programmiererfahrung nötig. Stattdessen wird ein Wissensingenieur – der in der Regel das Anwendungswissen aber keine Kenntnis einer Programmiersprache hat – in die Lage versetzt, sein Fachwissen zu formalisieren. Die entstandenen Werkzeuge implementieren einen parametrischen Ansatz zur Eingabe und Prüfung des Fachwissens (Kraft u. Nagl 2003b). Abgesehen von grundlegendem Domänenwissen für den konzeptuellen Gebäudeentwurf enthalten die Werkzeuge selbst kein Fachwissen. Sie bieten stattdessen eine visuelle Sprache zur Formalisierung konzeptuellen Fachwissens und die nötige Werkzeugfunktionalität zur Eingabe, Navigation, Integration und Konsistenzsicherung. Der vorgestellte Ansatz zur Wissensformalisierung ist zweistufig. In einem ersten Schritt soll der Wissensingenieur die für die Wissensformalisierung relevanten Begriffe, spezifisch für eine Gebäudeklasse in einer Fachontologie (Berners-Lee et al. 2001) definieren und strukturieren. In einem zweiten Schritt verwendet der Wissensingenieur vordefinierte Regeltypen, um die geltenden Anforderungen und Einschränkungen an einen konzeptuellen Entwurf zu formulieren. Zur inhaltlichen Beschreibung der Regeln werden die Ontologieelemente verwendet. Der zweistufige Ansatz zur Wissensformalisierung durch einen Wissensingenieur wird in Abb. 3.1 links verdeutlicht. Im oberen Bereich ist eine durch Vererbung strukturierte Fachontologie dargestellt. Ausgehend von dem vordefinierten Begriff Raum sind weitere Begriffe durch den Wissensingenieur identifiziert und strukturiert. Im unteren Bereich sind zwei Basisregeltypen angedeutet, mit denen der Wissensingenieur eine Forderung nach dem Zugang zwischen zwei Räumen sowie eine Größenbeschränkung ausdrückt. Durch die Konsistenzanalyse werden beide Projektteile verbunden. Das formalisierte Fachwissen wird gegen den konzeptuellen Entwurfsplan geprüft und Regelverletzungen aufgedeckt. Als Hilfestellung werden die gefundenen Fehler innerhalb des Entwurfsplans, annotiert durch eine aussagekräftige Fehlermeldung, visualisiert. Der Architekt hat die Wahl, die Regelverletzung zu ignorieren, den Fehler zu korrigieren oder als Rückkopplung eine Änderung der korrespondierenden Regel zu fordern. Als Anwendungsbeispiel wurde die Gebäudeklasse des Krankenhauses gewählt. Einerseits sind Krankenhäuser hinreichend komplex und vielseitig strukturiert, sodass alle erarbeiteten Entwurfskonzepte anhand eines gemeinsamen und realistischen Beispiels vorgestellt werden können. Andererseits existiert für Krankenhäuser umfassendes Regelwissen, das bereits während der konzeptuellen Entwurfsphase berücksichtigt werden muss. Die Illustration der Ergebnisse erfolgt anhand von Ausschnitten des Aachener Klinikums. Ein Anspruch auf die vollständige Modellierung dieses Krankenhauses existiert nicht.

160

Bodo Kraft, Manfred Nagl

3.3.2 Semantische Modellierung konzeptueller Entwurfspläne Heutige CAD-Werkzeuge bieten umfassende Möglichkeiten, einen vollständigen und exakten Entwurfsplan zu erstellen, der alle zur Ausführung nötigen Details enthält. Keines der am Markt verfügbaren CAD-Werkzeuge bietet allerdings eine angemessene Möglichkeit zur Erstellung eines Gebäudeentwurfs in Form einer groben, konzeptuellen Entwurfsskizze. Zudem bietet keines der CAD-Werkzeuge eine semantische Sichtweise auf einen Gebäudeentwurf, der die Spezifika einer bestimmten Gebäudeklasse abzubilden vermag. Im Folgenden werden die neu entwickelten Konzepte zur Unterstützung des Architekten bei der Erstellung konzeptueller Entwurfspläne zunächst in allgemeiner Form vorgestellt. Anschließend wird deren Umsetzung beschrieben. Die Innovationen sind im Rahmen des grundlagenorientierten Top-Down-Ansatzes durch ein graphbasiertes CAD-Werkzeug prototypisch implementiert. Im praxisnahen Bottom-Up-Ansatz wurde das CAD-Werkzeug ArchiCAD umfassend erweitert. Semantische Entwurfsobjekte und deren Verknüpfung Zur Unterstützung der abstrakten, konzeptuellen Entwurfsmodellierung werden dem Architekten neue semantische Raum- und Bereichselemente angeboten sowie umfassende Funktionalität, diese zu verarbeiten. Die neu eingeführten Entwurfselemente stellen die für eine Gebäudeklasse relevanten funktionalen Einheiten dar, d.h. alle für eine Gebäudeklasse wichtigen Raumtypen wie z.B. Flure, Toiletten, Bäder und die umschließenden funktionalen Bereiche, z.B. Verkehrswege oder die Nutzfläche. Diese neuen Entwurfselemente werden semantische Objekte genannt (Kraft et al. 2002). Der Architekt verwendet semantische Objekte, um die Gebäudestruktur in abstrakter Form zu modellieren. Das Projekt verfolgt nicht das Ziel, gestaltungs- oder konstruktionsorientierte Details abzubilden. Vielmehr soll eine funktionsorientierte Sichtweise als Einstieg in das Entwurfsproblem verfolgt werden (Steinmann 1997). Die funktionalen Einheiten in einem Gebäudeentwurf stehen in Beziehung zueinander. Die wichtigsten Beziehungstypen zwischen zwei funktionalen Einheiten sind Zugang, Nachbarschaft und Sicht. In stark strukturieren Gebäudeklassen, z.B. Krankenhäusern, sind die Beziehungstypen komplexer. So sind z.B. Zutrittsbeschränkungen für Personengruppen definiert oder Wege für Speisen, Waren und Abfälle vorgegeben. Die explizite Abbildung aller relevanten Beziehungen im konzeptuellen Entwurfsplan erfolgt durch getypte Verbindungskanten zwischen den semantischen Objekten. Die Abstraktion von der konstruktionsorientierten Umsetzung einer solchen Beziehung, z.B. durch eine Tür, ermöglicht eine konzeptuelle Sichtweise auf den Gebäudeentwurf und erlaubt die Repräsentation von höherwertiger Information. Der Architekt kann das Gebäudekonzept durch semantische Objekte und deren Beziehungen angemessen erarbeiten und somit explizit und formal festhalten (Kraft 2003b).

Unterstützung des konzeptuellen Gebäudeentwurfs

161

Als weiterführende Funktionalität wird dem Architekt die Möglichkeit geboten, den Entwurfsplan in unterschiedlichen Abstraktionsgraden zu bearbeiten. Diese neue Funktionalität erlaubt die Verfeinerung von semantischen Objekten. Funktionale Bereiche können durch Teilbereiche genauer definiert werden. Durch diese Funktionalität zur Dekomposition eines Entwurfsproblems in kleinere Teile wird die Komplexität deutlich reduziert (Kraft u. Schneider 2005). Ein weiterer Vorteil der hierarchischen Verschachtelung von semantischen Objekten besteht in der Möglichkeit, den Entwurfsplan in unterschiedlichen Sichten darzustellen. Dadurch können die in einem semantischen Objekt enthaltenen Teilentwürfe ausgeblendet werden, um weitere Abstraktion zu erreichen. Der Architekt kann den jeweils relevanten Ausschnitt aus dem Entwurfsplan detailliert bearbeiten, während temporär unwichtige Teile abstrakt dargestellt sind. Konsistenzprüfung konzeptueller Entwürfe Voraussetzung für die Prüfung der Konsistenz eines konzeptuellen Entwurfsplans ist die formale Darstellung konzeptuellen Fachwissens. Diese Thematik wurde im zweiten Projektteil bearbeitet. Im Rahmen der Konsistenzanalyse werden die Eigenschaften und Relationen aller semantischen Objekte überprüft und Inkonsistenzen innerhalb des Entwurfsplans visualisiert. Im graphbasierten Top-DownAnsatz erfolgt die Konsistenzanalyse durch formal spezifizierte, parametrische Graphtransformationen (Kraft u. Retkowitz 2006). Der praxisnahe Bottom-UpAnsatz importiert Fachwissen aus einer XML-Datei in das CAD-Werkzeug ArchiCAD und prüft den Entwurf durch einen iterativen Algorithmus (Kraft u. Schneider 2005). Die Konsistenzanalyse kann zu jeder Zeit und wiederholt durchgeführt werden. Damit dient die Konsistenzanalyse nicht nur der Fehleridentifikation sondern zudem als Informationsquelle für den Architekten. Die automatische Korrektur von Entwurfsfehlern wird, wegen des zu starken Eingriffs in die Arbeit des Architekten, nicht durchgeführt. Modularisierung konzeptueller Teilentwürfe Oftmals werden bestimmte Teile eines konzeptuellen Entwurfsplans mehrfach innerhalb eines Gebäudes benötigt. So ist in einem Krankenhaus z.B. ein Bettenzimmer, bestehend aus einem Vorraum, einer Waschzelle, dem Besucherbereich und dem Bettenbereich, eine häufig verwendete Einheit. Die mehrfache Erstellung solcher Teilentwürfe birgt nicht nur die Gefahr von Fehleingaben, sie ist zudem eine wenig befriedigende Arbeit für den Architekten. Schließlich müssen Änderungen eines konzeptuellen Teilentwurfs an alle betroffenen Stellen manuell übertragen werden. Als Unterstützung des Architekten wurde die Funktionalität realisiert, konzeptuelle Teilentwürfe als semantisches Entwurfsmodul zu speichern bzw. diese in einem Entwurfsplan zu verwenden. Die Entwurfsmodule werden in dem jeweiligen Werkzeug als konzeptueller Teilentwurf visuell erstellt und in einer XMLDatei serialisiert. Zusätzlich zu der industriell bereits vorhandenen Funktionalität

162

Bodo Kraft, Manfred Nagl

zur Auslagerung von Teilentwürfen erhält der Architekt hierbei die Möglichkeit, das Verhalten und die Verwendung eines Entwurfsmoduls detailliert festzulegen. Über eine Schnittstellenbeschreibung werden die Einbettungsmöglichkeiten des semantischen Entwurfsmoduls definiert. Hierdurch ist die Verwendung des Moduls ohne die Kenntnis der internen Realisierung nach Außen dokumentiert und sinnvoll eingeschränkt. Das Verhalten des semantischen Entwurfsmoduls kann eingeschränkt werden, sodass geometrische Transformationen verboten sind oder nur nach bestimmten Regeln erfolgten dürfen. Durch die Beschreibung des Verhaltens kann der Architekt sicherstellen, dass der Teilentwurf in korrekter Form verwendet wird. Für ein Bettenzimmer kann z.B. die Skalierung verboten werden, da die Dimensionen der enthaltenen Teile genau aufeinander abgestimmt sind. Die Spiegelung eines Bettenzimmers kann dagegen erlaubt sein. Integration von konzeptuellem und konstruktivem Entwurf Nach Abschluss der konzeptuellen Entwurfsphase kann der konzeptuelle Entwurfsplan in eine traditionelle Wandstruktur überführt werden. Voraussetzung ist ein konzeptueller Entwurfsplan, der bereits Geometrieinformationen enthält. Das Werkzeug zur automatischen Wandkonstruktion ist daher nur für den Bottom-UpAnsatz realisiert. Neben der Erzeugung der Wandstruktur werden auch die Beziehungen zwischen den semantischen Objekten berücksichtigt. Hierbei wird für jeden Zugang zwischen zwei semantischen Objekten eine Tür als konstruktive Umsetzung in die Wandstruktur eingefügt. Sichtbeziehungen werden automatisiert durch Fenster realisiert. Der konzeptuelle Entwurfsplan bleibt weiter erhalten und dokumentiert als Ergänzung zur konstruktiven Wandstruktur die nicht darstellbaren Konzepte. Die erzeugte Wandstruktur ist als Ausgangspunkt für eine weitere Bearbeitung durch den Architekten zu verstehen. Das Ziel liegt keineswegs darin, den Architekten zu ersetzen. Vielmehr sollen einfache aber zeitaufwändige Routinearbeiten vermieden werden. Werkzeuge für die Erstellung konzeptueller Entwurfspläne Bei der Entwicklung neuer Werkzeugunterstützung wurden – entsprechend der vorab eingeführten Ansätze Top-Down und Bottom-Up – beide Strategien verfolgt. Im Rahmen des Top-Down-Ansatzes wurde ein graphbasiertes CADWerkzeug entwickelt, das die Erstellung konzeptueller Entwurfspläne abstrahiert von jeder Geometrieinformation erlaubt. Der hohe Grad der Abstraktion ermöglicht es dem Architekten, sich vollständig auf die Funktionsweise und Organisation des Gebäudes zu konzentrieren. Als Resultat entstehen konzeptuelle Entwurfspläne, die analog zu Bubble-Diagrammen (Steinmann 1997) die Gebäudestruktur abbilden. Der Prototyp für den graphbasierten konzeptuellen Entwurf realisiert die oben beschriebene Funktionalität. Semantische Objekte können in den Entwurf eingefügt werden. In dem Werkzeug werden diese durch Graphknoten abgebildet. Die

Unterstützung des konzeptuellen Gebäudeentwurfs

163

Beschreibung von Beziehungen zwischen semantischen Objekten erfolgt durch Kanten zwischen den Graphknoten. Durch Attribute werden Eigenschaften eines Raumes oder eines Bereichs definiert. Die Abstraktion von Teilentwürfen wird durch die Enthaltenseinsbeziehung erreicht. Semantische Objekte können dadurch mehrere semantische Objekte und deren Beziehungsgeflecht enthalten. Die Visualisierung der Enthaltenseinsbeziehung kann entweder explizit, in Form einer Kante, oder implizit durch die Gruppierung der enthaltenen Graphknoten und -kanten innerhalb des umschließenden semantischen Objekts erfolgten.

Abb. 3.2. Visuelles Werkzeug für den graphbasierten konzeptuellen Entwurf

Abbildung 3.2 zeigt einen Screenshot des Design-Graph-Editors, dem neu entwickelten graphbasierten CAD-Werkzeug. Der Beispielentwurf in Abb. 3.2 beschreibt einen Teil der Kinderintensivpflegestation des Aachener Universitätsklinikums. Der Stationsflur beinhaltet (in dem Screenshot links oben) einen OPBereich, in dem ein Arztzimmer, der OP-Saal und weitere Räume enthalten sind. In dem Beispiel ist die Zugangsstruktur zwischen den Räumen innerhalb des OPBereichs beschrieben, z.B. kann der OP-Saal nur über den Flur oder den Überwachungsraum erreicht werden. Außerdem ist die Nachbarschaft von Arztzimmer und OP-Raum geplant. Die Positionierung der semantischen Objekte spiegelt in dieser abstrakten Form nicht notwendigerweise die spätere Umsetzung wider. Im Fordergrund steht vielmehr, alle Beziehungen zwischen den semantischen Objekten in übersichtlicher Form zu visualisieren.

164

Bodo Kraft, Manfred Nagl

Als Ergebnis der Konsistenzanalyse wurden in dem Beispielentwurf in Abb. 3.2 einige Entwurfsfehler identifiziert. Hierbei wurde z.B. das Fehlen eines Spielraumes innerhalb des Kinderpflegebereichs (vgl. KhBauVO §32(5)) moniert. Außerdem ist die geforderte Sichtbeziehung zwischen dem Flur und den Bettenzimmern (vgl. KhBauVO §32(1)) in dem Entwurfsplan nicht enthalten. Der Architekt kann für jede Inkonsistenz eine Fehlermeldung abfragen, die nicht nur die Quelle der Regel sondern auch einen Hinweis für die Fehlerbehebung enthält. Der Design-Graph-Editor bietet neben der beschriebenen Funktionalität die Möglichkeit, eine automatisierte Dokumentation des Entwurfsplans zu generieren und diesen in einer XML-Datei zu speichern. Hierdurch ist die Übertragung des Entwurfsplans in weitere Werkzeuge möglich. Im Rahmen des praxisorientierten Bottom-Up-Ansatzes wurde das CADWerkzeug ArchiCAD (GRAPHISOFT 2006) um neue Funktionalitäten erweitert. Unter Verwendung der von GRAPHISOFT angeboten Programmiersprache GDL und der Programmierschnittstelle C-API wurden die erarbeiteten Konzepte zur Unterstützung des konzeptuellen Entwurfs in ArchiCAD eingebettet. Die bereits in ArchiCAD existierende Funktionalität zur Erstellung, Verwaltung und Repräsentation architektonischer Entwurfspläne wurde verwendet. Als grundlegende Erweiterung wurden in ArchiCAD neue semantische Raumund Bereichsobjekte eingefügt. Umfangreiche Funktionalität wurde implementiert, um den Architekten bei der Erstellung konzeptueller Entwurfspläne mit diesen semantischen Objekten zu unterstützen (Kraft u. Schneider 2005). Im Gegensatz zu dem Design-Graph-Editor kann der konzeptuelle Entwurfsplan in ArchiCAD mit Geometrieinformationen erstellt werden. Im Entwurfsprozess hat der Architekt hierbei die Aufgabe, unter Berücksichtung der definierten Einschränkungen, alle semantischen Objekte zu dimensionieren und zu positionieren. Die neu eingeführten Raum- und Bereichsobjekte werden in ArchiCAD spezifisch für eine Gebäudeklasse angelegt und dem Architekten zur Verfügung gestellt. Für den Entwurf eines Krankenhauses stehen innerhalb von ArchiCAD z.B. die Raumobjekte Bettenzimmer, Isolationszimmer und Schwesternzimmer zur Verfügung. Die neuen Entwurfsobjekte haben eine zweidimensionale Repräsentation, die neben dem Typ des semantischen Objekts auch die Größe und Ausdehnung beschreibt. Für die konzeptuelle Entwurfsphase sind diese Angaben relevant und ausreichend. Durch eine dreidimensionale Ansicht kann der Architekt leicht auch vertikale Beziehungen erkennen und die Volumina der semantischen Entwurfsobjekte angemessen abschätzen. Zur Abbildung der relevanten Beziehungen kann der Architekt zwei semantische Objekte verknüpfen. Hierzu wurden in ArchiCAD für eine Gebäudeklasse spezifische Beziehungstypen, z.B. Besucherzugang oder Überwachung, realisiert. Die Darstellung der Beziehungen erfolgt unabhängig von der Position eines semantischen Objekts. Beim Editieren des Entwurfsplans bleiben diese Informationen erhalten. Die Umsetzung der Funktionalität erfolgt unter Verwendung der C-API. Jede Benutzerinteraktion wird über eine Ereignisverwaltung verarbeitet. Die Erweiterungen von ArchiCAD erlauben es, den Entwurfsplan in verschiedenen Abstraktionsstufen zu bearbeiten. Im Gegensatz zu dem Design-GraphEditor muss die Enthaltenseinsbeziehung nicht mehr explizit definiert werden. Ein

Unterstützung des konzeptuellen Gebäudeentwurfs

165

Bereichselement enthält automatisch alle geometrisch darin liegenden semantischen Objekte. Die hierdurch entstehende mehrfache Schachtelung semantischer Objekte kann in jeder Stufe ein- und ausgeblendet werden. Die erweiterte Funktionalität stellt sicher, dass beim Verschieben eines komplex strukturieren Bereichsobjekts alle enthaltenen semantischen Objekte berücksichtigt werden.

Abb. 3.3. Werkzeuge für den konzeptuellen Entwurf integriert in ArchiCAD

Abbildung 3.3 zeigt den vorab eingeführten konzeptuellen Entwurfsplan eines Krankenhausflures in ArchiCAD. In der zweidimensionalen Darstellung sind alle Raumobjekte mit Namen und Größenangaben dargestellt. Ebenso sind die geplanten Beziehungen zwischen den Raumobjekten, symbolisiert durch Pfeile, zu erkennen. In der Abbildung ist der Überwachungsbereich abstrakt dargestellt. Das semantische Objekt ist durch das ausgefüllte Rechteck in der oberen rechten Ecke als komplex gekennzeichnet. Mit Hilfe der neu eingeführten Benutzerschnittstelle kann der Architekt das semantische Objekt beliebig verfeinern oder als weitere Abstraktionsstufe das umschließende semantische Objekt einblenden. Die komplexe Struktur im Inneren belastet den Architekten bei der weiteren Bearbeitung dadurch nicht. Der in Abb. 3.3 gezeigte konzeptuelle Entwurfsplan stellt bereits das Ergebnis der konzeptuellen Entwurfsphase dar. Die Positionierung und Dimensionierung der semantischen Objekte ist bereits erfolgt und abgeschlossen. Im Verlauf der konzeptuellen Entwurfsphase beginnt der Architekt mit einer Sammlung der benötigten semantischen Objekte und fügt diese in einen Entwurfsplan ein. Der Architekt hat in diesem Projektteil die Möglichkeit, den graphbasierten Entwurf aus

166

Bodo Kraft, Manfred Nagl

dem Top-Down-Ansatz zu importieren und durch die Hinzunahme von Geometrieinformation zu vervollständigen. Die Schwierigkeit liegt in dieser Entwurfsphase darin, unter Beachtung der geforderten Größen, alle semantischen Einheiten konsistent zu positionieren und zu arrangieren. Die vorab definierten Relationen müssen beachtet werden. Die explizite Repräsentation eines semantischen Entwurfsobjekts ermöglicht es dem Architekten, zur Erstellung des Gebäudeentwurfs verschiedene Alternativen schnell zu evaluieren. Im Gegensatz zu der impliziten Beschreibung eines Raumes durch eine Wandstruktur hilft das semantische Entwurfsobjekt somit nicht nur durch die problemangemessene Repräsentation sondern auch durch die Möglichkeit zum komfortablen und schnellen Editieren. Die Prüfung des konzeptuellen Entwurfsplans gegen das Fachwissen ist ebenfalls möglich. Die hierzu in ArchiCAD eingebettete Konsistenzanalyse verwendet die hier zur Verfügung stehende Geometrieinformation. Die Analyse umfasst dadurch die abstrakte Struktur und deren Umsetzung in einem ausgearbeiteten konzeptuellen Entwurfsplan. 3.3.3 Formalisierung konzeptuellen Fachwissens Der zweite Teil des Projekts befasst sich mit der Erforschung neuer Konzepte zur Verarbeitung konzeptuell relevanten Fachwissens. Das Fachwissen wird, spezifisch für eine Gebäudeklasse in Form von Regeln, durch einen Wissensingenieur eingegeben. Die Verwaltung des Regelwissens erfolgt in formaler und expliziter Form. Das Regelwissen kann einerseits als Nachschlagewerk für den Architekten dienen. Auf der Basis der formal definierten Semantik können konzeptuelle Gebäudeentwürfe gegen das Regelwissen geprüft werden. Das formalisierte Fachwissen ist spezifisch für eine Gebäudeklasse, z.B. KfzWerkstätten, Bürogebäude oder Krankenhäuser. Der Aufwand zur Formalisierung des Fachwissens lohnt daher besonders, wenn dieses für mehrere Projekte der jeweiligen Gebäudeklasse verwendet wird. Der dynamische Ansatz der Wissensdefinition erlaubt hierbei die fortlaufende Evaluierung, Verfeinerung und Ergänzung des Fachwissens durch den Wissensingenieur. Zur Formalisierung konzeptuellen Fachwissens wurde vorwiegend der grundlagenorientierte Top-Down-Ansatz verfolgt. Hierbei stand die formale Modellierung des Fachwissens, eines konzeptuellen Gebäudeentwurfs sowie der dazwischen liegenden Konsistenzanalyse im Vordergrund. Zu Beginn der Projektbearbeitung wurden im Rahmen des Bottom-Up-Ansatzes das Ontologiewerkzeug Protégé verwendet, um schon frühzeitig die Einbindung konzeptuellen Fachwissens in ArchiCAD zu erproben (Kraft u. Schneider 2005). Diese Arbeiten wurden wegen der geringen Aussagekraft und dem Fehlen domänenspezifischer Unterstützung nicht weiter verfolgt. Der Ansatz zur Wissensdefinition ist zweistufig. Der erste grundlegende Bestandteil jeden Fachwissens ist das zur Beschreibung der geltenden Sachverhalte relevante Fachvokabular. Ein präzises Begriffssystem, indem die zu verwendenden Fachbegriffe definiert sind, muss bereits als Teil der Wissensdefinition angesehen werden. Die Definition dieses Begriffssystems muss somit durch einen Do-

Unterstützung des konzeptuellen Gebäudeentwurfs

167

mänenexperten erfolgen. Als zweiter Teil existiert für die Wissensdefinition eine Regelsprache, die dem Wissensingenieur die nötige Aussagekraft zur Formalisierung des relevanten Fachwissens bietet. Die Verwendung der visuellen Sprache erfordert keine informatischen Vorkenntnisse. In diesem Abschnitt erfolgt die Beschreibung der wichtigsten Ergebnisse, die im Rahmen der Erforschung neuer Verfahren zur Formalisierung und Verwendung konzeptuellen Fachwissens erarbeitet wurden. Nach der Beschreibung der zweistufigen Wissensformalisierung und der zugrunde liegenden formalen Semantik, wird die Umsetzung der Konzepte durch ein visuelles graphbasiertes Werkzeug demonstriert. Fachontologie als formales Begriffssystem Vor der Verwendung eines Begriffs im Rahmen der Wissensformalisierung muss dieser in der Fachontologie definiert werden. Als Grundlage für die zu entwickelnde Fachontologie wird dem Wissensingenieur eine domänenspezifische TopLevel-Ontologie vorgegeben. Diese dient als Ausgangsbasis für die Begriffsdefinition. Die für den konzeptuellen Gebäudeentwurf relevanten semantischen Einheiten, z.B. Etage, Bereich, Raum, Teilbereich, und deren Zusammenhänge sind darin bereits vordefiniert. Zudem sind in der Top-Level-Ontologie die zur Wissensformalisierung grundlegenden Beziehungstypen, z.B. Zugang oder Nachbarschaft, und eine Reihe von Attributen, z.B. zur Beschreibung von Größenangaben, vorgegeben.

Abb. 3.4 Ausschnitt einer Fachontologie für die Gebäudeklasse Krankenhaus

In der Fachontologie können semantische Objekte durch Spezialisierung und Aggregation strukturiert werden. Als Spezialisierung des vordefinierten semantischen Objekts Raum definiert der Wissensingenieur z.B. alle für die zu beschreibende Gebäudeklasse relevanten Räume. Ebenso werden die funktionalen Bereiche, die Relation und Attribute in der Fachontologie spezifisch für eine Gebäudeklasse definiert. Die Modellierung der Fachontologie ist in (Kraft u. Wilhelms 2004; Kraft u. Nagl 2006) dokumentiert.

168

Bodo Kraft, Manfred Nagl

Abbildung 3.4 zeigt einen Ausschnitt einer Fachontologie. Im oberen Bereich der Abbildung ist die vorgegebene Top-Level-Ontologie dargestellt. Im unteren Bereich wurde durch einen Wissensingenieur ein Ausschnitt einer Fachontologie für Krankenhäuser entwickelt. Die Ontologie kann zu jeder Zeit ergänzt und modifiziert werden. Man kann erkennen, dass in der Abbildung das Ontologieelement ROOM in einen Patientenraum spezialisiert wurde. Als direkte Spezialisierung des Patientenraums ist der Pflegeraum definiert, transitiv sind auch Bettenzimmer Spezialisierungen des Patientenraums. Als Spezialisierung des vordefinierten Ontologieelements AREA ist ein Pflegebereich sowie, als Spezialisierung davon, ein Kinderpflegebereich erstellt. Der Pflegebereich ist komplex strukturiert, er besteht aus der (wiederum komplex strukturierten) Pflegeeinheit. Der Kinderpflegebereich enthält zudem einige Räume, z.B. das Säuglingszimmer oder den Spielraum. Wie man erkennen kann, erfordert die Definition und Strukturierung der Fachontologie umfassende Kenntnis der jeweiligen Gebäudeklasse. Die Möglichkeit zur fortlaufenden Überarbeitung der Fachontologie ist eine Grundvoraussetzung für die Anwendbarkeit des Ansatzes. Visuelle Sprache zur Formalisierung konzeptuellen Fachwissens Als zweiten Teil der Formalisierung des geltenden Fachwissens wurde eine visuelle Sprache konzipiert und entwickelt, die dem Wissensingenieur die einfache Eingabe und Pflege der relevanten Forderungen und Restriktionen ermöglicht. Die Aussagekraft der visuellen Sprache umfasst eine beschränke Menge von Regeltypen, die sich bei der Analyse der geltenden Regelwerke als notwendig und ausreichend erwiesen haben. Die Regeltypen erlauben die Formalisierung von Fachwissen, das spezifisch für den konzeptuellen Entwurf ist. Fachwissen aus anderen Bereichen, wie z.B. Statik oder Klimatechnik, die insbesondere die späteren Phasen des Entwurfsprozesses betreffen, sind für den konzeptuellen Entwurf nach dem hier geltenden Verständnis nicht relevant. Drei Basisregeltypen bieten die Grundlage für die visuelle Wissensdefinition. Attributregeln erlauben es, für ein semantisches Objekt Eigenschaften, z.B. eine Größenanforderung oder die Existenz einer bestimmten Ausstattung, zu fordern oder zu verbieten. Als zweiten Basisregeltyp bieten Relationsregeln die Möglichkeit, Beziehungen zwischen zwei semantischen Objekten, z.B. den Zugang, zu fordern oder zu verbieten. Kardinalitätsregeln ermöglichen es dem Wissensingenieur schließlich, die erlaubte und geforderte Anzahl von semantischen Objekten in einem konzeptuellen Entwurfsplan zu beschreiben (Kirchhof u. Kraft 2004). Mit Hilfe der Basisregeltypen kann der Wissensingenieur bereits einfaches konzeptuelles Fachwissen formalisieren. Viele der für eine Gebäudeklasse geltenden Anforderungen und Einschränkungen können damit bereits abgebildet werden. Durch die objektorientiert strukturierte Fachontologie gelten für die spezielleren semantischen Objekte automatisch alle Regeln, die für allgemeinere semantische Objekte definiert wurden. Für komplex strukturierte semantische Objekte, also für die in der Fachontologie definierten Aggregationen, gilt eine erweiterte Semantik (Kraft u. Wilhelms 2005).

Unterstützung des konzeptuellen Gebäudeentwurfs

169

Eine Reihe von Erweiterungen der Basisregeln erhöht deren Aussagekraft. Der Gültigkeitsbereich einer Regel kann z.B. durch die Angabe eines Anwendungsbereichs eingeschränkt werden. Die Regel gilt damit nur für solche semantischen Objekte, die innerhalb des umschließenden Objekts liegen. Durch laufzeitabhängige Ausdrücke kann das Regelwissen in Abhängigkeit zu dem aktuell geprüften Entwurf definiert werden. So kann die Größenforderung eines funktionalen Bereichs z.B. in Abhängigkeit der enthaltenen Teile definiert werden. Eine Erweiterung einfacher Relationsregeln erlaubt die Beschreibung komplexer Pfade innerhalb eines Gebäudes. So kann durch eine Verkettung von semantischen Objekten und Relationen ein strukturierter Weg durch ein Gebäude definiert und als komplexe Relation bei der Regeldefinition verwendet werden. Kinderpflegebereich ContextRelRule

AllRule Bettenzimmer

AndRule

ContextRelRule

Bettenzimmer Bettenzimmer

Sicht Sicht

Flur Schwestern zimmer

Kinderpflegebereich

Abb. 3.5. Forderung einer Sichtbeziehung für Bettenzimmer nach KhBauVO §32(1)

Um das existierende Fachwissen annähernd vollständig abbilden zu können ist es erforderlich, Abhängigkeiten zwischen Regeln definieren zu können. Für die Gültigkeit vieler Forderungen müssen Vorbedingungen erfüllt sein. Oftmals ist es möglich, eine Forderung durch mehrere Alternativen zu erfüllen. Aus diesem Zweck erlaubt die visuelle Sprache die Definition von Regelabhängigkeiten (Kraft u. Retkowitz 2006b). Regeln können durch Boolesche Operatoren (AND, OR, IMPLIES) zu komplexen Regeln verknüpft werden. Durch die Angabe von Quantoren (ALL, EXISTS) kann die Semantik einer Regel je nach Anforderungen verändert werden. Die in Abbildung 3.5 dargestellte komplexe Regel formalisiert eine Anforderung aus der Krankenhausbauverordnung §32 (1). In Fachabteilungen für Kinder müssen die Bettenzimmer vom Flur sowie von den Schwesternzimmern aus einsehbar sein. Die komplexe Regel besteht zunächst aus zwei Relationsregeln, die jeweils eine Sichtbeziehung fordern. Durch die Angabe eines Kontextes, hier des Kinderpflegebereichs, ist der Gültigkeitsbereich eingeschränkt. Da beide Relationsregeln gelten sollen, sind die Teilregeln durch eine binäre AND-Regel miteinander verknüpft. Schließlich definiert die unäre ALL-Regel, dass die Regel für alle Bettenzimmer gelten muss. Formale Semantik der Regelsysteme Die Semantik der visuellen Sprache zur Wissensformalisierung wurde nach einem operationalen Ansatz (Erwig 1998) formal definiert. Charakteristisch für den operationalen Ansatz ist die Definition der syntaktischen Elemente der Sprache als

170

Bodo Kraft, Manfred Nagl

Mengen. Die Semantik wird durch prädikatenlogische Formeln über diesen Mengen definiert. Die Konsistenzbeziehung zwischen dem Regelwissen und einem konzeptuellen Entwurfsplan ist durch die Semantikdefinition der einzelnen Regeltypen beschrieben. Für jeden Regeltyp ist in einer der Prädikatenlogik verwandten Notation eine Konsistenzbedingung angegeben. Die Semantik der komplexen Regeln ergibt sich induktiv aus deren Bestandteilen (Kraft u. Retkowitz 2005). Die formale Semantikdefinition dient als Vorlage für die Spezifikation der Software-Werkzeuge in PROGRES. Der operationale, mengenorientierte Ansatz kann angemessen auf die deklarative Spezifikation von Graphersetzungsregeln übertragen werden. Werkzeugunterstützung zur Wissensformalisierung Für die Erstellung der Werkzeuge wurde die Infrastruktur des Lehrstuhls für Informatik 3 an der RWTH Aachen verwendet. Die Umsetzung der Modellierung erfolgt durch die formale Spezifikation einer Graphgrammatik in dem PROGRESSystem. Die PROGRES-Spezifikation umfasst hierbei die statische Modellierung in Form eines Graphschemas sowie sämtliche Funktionalität zur Veränderungen des Laufzeitgraphen. Die Ausführung der PROGRES-Spezifikation erfolgt in einem graphbasierten visuellen Werkzeug, das von dem UPGRADE-Rahmenwerk abgeleitet wurde. Als Ergebnis entstehen Prototypen, die eine mögliche industrielle Umsetzung demonstrieren (Kraft 2003a; Kraft u. Nagl 2003a).

Abb. 3.6. Graphbasierte Werkzeuge zur Formalisierung konzeptuellen Fachwissens

Unterstützung des konzeptuellen Gebäudeentwurfs

171

Die neu entwickelten Werkzeuge implementieren die visuelle Sprache zur Wissensformalisierung. Die vom Wissensingenieur eingegebene Fachontologie, wie auch die Regeln, werden in Form eines Laufzeitgraphen im Speicher verwaltet. Jede Veränderung an dem Graph, z.B. die Definition einer neuen Regel, ist durch eine Gruppe von Graphtransformationen in PROGRES spezifiziert. Analog dazu wird die Erstellung und Verwaltung konzeptueller Gebäudeentwürfe vollständig durch die PROGRES-Spezifikation beschrieben. Der konzeptuelle Entwurfsplan ist ebenfalls im Laufzeitgraph abgelegt. Die graphbasierte Konsistenzanalyse erfolgt durch den komplexen Vergleich des Regelwissens mit dem konzeptuellen Entwurfsplan. Die Funktionalität zur Prüfung jeder Regel ist jeweils durch eine Gruppe von Graphtransformationen spezifisiert. Da das Fachwissen erst zur Werkzeuglaufzeit durch den Wissensingenieur definiert wird, ist die PROGRES-Spezifikation hochgradig parametrisiert. Die Spezifikation der Ontologiedefinition, der Regeldefinition und auch der Konsistenzanalyse ist unspezifisch in Bezug auf eine Gebäudeklasse. In PROGRES sind parametrische Schablonen für jeden Regeltyp definiert. Für die Auswertung jeder Regel beschreibt ein parametrisches Graphmuster in deklarativer Form eine verbotene Situation. Das PROGRES-Laufzeitsystem sucht nichtdeterministisch und durch Verwendung von Backtracking-Mechanismen die passenden Anwendungsstellen für die Graphmuster (Kraft u. Nagl 2003b; Kraft u. Retkowitz 2006a). Das Werkzeug zur Erstellung konzeptueller Entwurfspläne (siehe Abbildung 3.2) wurde bereits erläutert. Für die Wissensdefinition sind mehrere graphbasierte visuelle Werkzeuge entstanden. Zunächst ermöglicht der Domain Ontology Editor die visuelle Definition der Regelwissenontologie. Der Editor enthält mehrere Sichten, um semantische Objekte durch Vererbung und Aggregation zu strukturieren. Zudem werden in diesem Werkzeug als Teil der Ontologie die benötigten Relationen und Attribute definiert. Zur Eingabe und Pflege der Regeln bietet Domain Knowledge Editor zwei unterschiedliche Repräsentationen. Alle nicht durch Regelabhängigkeiten verknüpften Regeln werden in einer objektbasierten Darstellung übersichtlich und kompakt arrangiert. Anhand dieser Darstellung können die für ein semantisches Objekt geltenden Regeln – unabhängig davon ob sie definiert oder geerbt wurden – erkannt werden. Eine zweite Repräsentation ermöglicht die Erstellung und Visualisierung von Regelabhängigkeiten. Für jede komplexe Regel wird ein Regelbaum aufgebaut, der die Teilregeln enthält. Die Abbildung 3.6 zeigt zwei Screenshots der Werkzeuge zur visuellen Wissensformalisierung. Das Werkzeug zur Ontologiedefinition ist aus Platzgründen nicht dargestellt. Der hintere Screenshot zeigt die objektbasierte Sicht auf das Fachwissen. Für das semantische Objekte Bettenzimmer sind mehrere Attributregeln definiert. Eine Attributregel fordert z.B. die Größe von Bettenzimmern in Abhängigkeit von der Anzahl der dort vorhandenen Betten. Eine weitere Attributregel fordert die Existenz eines Medienanschlusses für Bettenzimmer. Durch eine Relationsregel ist die Sichtbeziehung vom Flur in die Bettenzimmer verboten. Für Isolationszimmer gelten als Spezialisierung zunächst alle Regeln des einfachen Bettenzimmers. Der direkte Zugang ist allerdings verboten. Stattdessen fordert eine komplexe Relationsregel die Existenz eines Schleusenzugangs.

172

Bodo Kraft, Manfred Nagl

Der vordere in Abb. 3.6 dargestellte Screenshot zeigt die regelbasierte Ansicht. Die dort angegebene Regel fordert die Existenz eines Rauchabzugs für notwendige Treppenhäuser, wenn diese innen liegend sind und das Gebäude mehr als sechs Stockwerke hat. Die Vorbedingung der Regel ist durch die Prämisse der IMPLIES-Regel formalisiert, die wiederum komplex durch eine OR-Regel beschrieben ist.

3.4 Umfeld In diesem Abschnitt ist das wissenschaftliche und das industrielle Umfeld des Projekts beschrieben. Zunächst erfolgt die Erläuterung, inwieweit die Ergebnisse dieses Projekts zu den Zielen des SPP 1103 beitragen. Anschließend wird die industrielle Verwertbarkeit sowie der Beitrag der Kooperationspartner und die Förderung des wissenschaftlichen Nachwuchs darstellt. 3.4.1 Beitrag zu den Zielen des Schwerpunktprogramms Zur Fokussierung der Zielpunkte des SPP 1103 wurden vier Arbeitsgruppen eingerichtet. Die inhaltlich verwandten Projekte konnten dadurch stärker vernetzt werden. Das vorliegende Projekt ist der Arbeitsgruppe Verteilte Produktmodellierung zugeordnet. Wegen der inhaltlichen Verwandtschaft wurden zudem die Treffen der Arbeitsgruppe Verteilte Prozessmodellierung besucht. Die Kooperation der Projekte innerhalb der Arbeitsgruppen hat maßgeblich zur Projektentwicklung beigetragen. Das vorliegende Projekt hat durch die theoretischen und praktischen Kenntnisse aus dem Bereich des Bauwesens profitiert, die die anderen Arbeitsgruppenteilnehmer aufgrund ihrer Ausbildung einbringen konnten. Als eigenen Beitrag hat dieses Projekt weiterführende Kenntnisse der informatischen Grundlagen und deren Anwendung eingebracht. Der Austausch erfolgte hierbei vorwiegend durch kritische Diskussionen, aus denen z.B. eine vereinheitlichte Systemarchitektur sowie ein gemeinsames Szenario entwickelt wurden. Eine generalisierte Metamodellierung ermöglichte es, die verschiedenen Projekte in einem gemeinsamen Modell darzustellen (Kap. III.1). Zu den Zielen des SPP 1103 trägt dieses Projekt in mehreren Teilen bei. Im Rahmen der Neugestaltung der Planungsprozesse wird die Berücksichtigung der frühen Phase des architektonischen Entwurfsprozesses – integriert in den Gesamtentwicklungsprozess – gefordert und ermöglicht. Hierzu wurden formale Modelle auf der Basis von Graphtransformationen erarbeitet sowie eine anwendernahe, exemplarische Implementierung in dem CAD-Werkzeug ArchiCAD realisiert. Der Beitrag zur Erforschung neuer Möglichkeiten zur Interaktion der heute industriell verwendeten Fachsoftware liegt in der umfangreichen Erweiterung von ArchiCAD. Unter Verwendung der existierenden Möglichkeiten konnte sowohl die Daten- als auch die Kontroll- und Benutzerschnittstellenintegration realisiert werden. Die entstandenen Software-Prototypen ermöglichen die Beherrschung der

Unterstützung des konzeptuellen Gebäudeentwurfs

173

Komplexität bei der Erstellung konzeptueller Entwurfsskizzen durch Abstraktionskonzepte und Konsistenzsicherung. Die Anwendbarkeit ist dadurch verifiziert. Ein Schwerpunkt der Arbeit liegt in der Bereitstellung neuer Verfahren zur Verarbeitung von Fachwissen. Der Beitrag zu diesem Ziel besteht in der Identifikation, Konzeption und Implementierung einer visuellen Sprache zur Definition konzeptuell relevanten Fachwissens. Mithilfe dieser Sprache kann Fachwissen zur Werkzeuglaufzeit durch einen Domänenexperten eingeben, evaluiert und zur Konsistenzsicherung verwendet werden. 3.4.2 Projektpartner und wissenschaftliche Nachwuchsförderung Die Grundlagen für das bearbeitete Projekt stammen aus einer deutsch-polnischen Forschungskooperation zwischen der RWTH Aachen (Prof. M. Nagl), der TU Darmstadt (Prof. A. Schürr) und den polnischen Universitäten Polish Academy of Sciences Warsaw (Prof. A. Borkowski) und der Jagiellonian University Cracow (Dr. E. Grabska). Im Rahmen des durch die Alexander von Humboldt-Stiftung geförderten Forschungsprojekts Graph-based Tools for Conceptual Design in Civil Engineering wurden erste Grundlagen erforscht, die Anwendungsdomäne gemeinsam erschlossen sowie unterschiedliche Lösungsstrategien evaluiert. In einem Kooperationsprojekt der Universitäten Darmstadt und Warschau wurde eine verwandte Thematik mit anderer Zielsetzung verfolgt (Szuba 2005). Zur Sicherstellung der industriellen Relevanz ist das Projekt in verschiedene Kooperationen eingebettet. Auf der Seite der Werkzeughersteller konnte das ungarische Softwarehaus GRAPHISOFT, Entwickler des verbreiteten CADWerkzeugs ArchiCAD, als Projektpartner gewonnen werden. Durch mehrere Arbeitstreffen wurde hier der aktuelle Stand des Forschungsprojekts bewertet und neue Anforderungen eingebracht. Zudem haben zwei professionelle Anwender von ArchiCAD sich schon während der frühen Projektphase zum fortlaufenden Testen und Evaluieren der entstandenen Werkzeuge bereit erklärt. Hierdurch sind wertvolle Anwendererfahrungen in das Projekt zurückgeflossen. Der interdisziplinäre Charakter der Arbeit wurde ebenso durch die Vernetzung innerhalb der RWTH Aachen untermauert. Im Rahmen einer gemeinsam mit dem Lehrstuhl für CAAD (Prof. J. Russel) betreuten Studienarbeit konnte wertvolles Domänenwissen gewonnen und verwertet werden. Die Förderung des wissenschaftlichen Nachwuchses erfolgte durch die Einbindung von Studenten in die Projektbearbeitung. Insgesamt wurden fünf Diplombzw. Masterarbeiten in der Projektzeit betreut. Zwei der Bearbeiter konnten nach Abschluss ihres Studiums als wissenschaftliche Mitarbeiter gewonnen werden. Zudem wurden in mehreren Lehrveranstaltungen insgesamt 23 Seminararbeiten zu thematisch verwandten Forschungsansätzen betreut.

174

Bodo Kraft, Manfred Nagl

3.4.3 Industrielle Verwertbarkeit der Ergebnisse Die in dieser Arbeit vorgestellten Konzepte sind für den architektonischen Entwurf entwickelt und optimiert. Dennoch beschränken sich die Grundkonzepte nicht nur auf die Architektur. Der konzeptuelle Entwurf spielt in nahezu jeder Ingenieurdisziplin eine entscheidende Rolle. Die Abstraktion von einer vollständigen und detaillieren Sichtweise hin zu einer zunächst ganzheitlichen Betrachtung des zu lösenden Sachverhalts erleichtert den Einstieg in das Entwurfsproblem. Die Abstraktion fördert die Kreativität und bietet kognitive Entlastung. Auch wenn diese frühe Entwurfsphase nur selten als vorhanden erkannt und explizit eingeplant wird, findet ein konzeptueller Entwurf in jedem Fall statt. Durch das mangelnde Bewusstsein der Werkzeughersteller für die Wichtigkeit des konzeptuellen Entwurfs und die fehlende Bereitschaft diesen angemessen zu unterstützen, bleiben grundlegende Bereiche des architektonischen Entwicklungsprozesses unberücksichtigt, wichtige Kundensegmente werden vernachlässigt. Der in dieser Branche elementar entscheidende Innovationsvorsprung wird verpasst. Die stattdessen fortlaufende Erweiterung der konstruktiven Funktionalität spricht nur einen geringen Nutzerkreis an und stellt für den Großteil der Kunden, die ohnehin nur einen Teilbereich der Funktionalität (Meißner et al. 1992) verwenden, keinen nennenswerten Mehrwert dar. Auch die zum Teil erheblichen Anstrengungen der Werkzeugentwickler zur Verbreitung standardisierter Datenaustauschformate werden durch die Praxisrelevanz keineswegs gerechtfertigt. Die in diesem Dissertationsprojekt entwickelten Konzepte, sowohl zur Formalisierung konzeptuellen Fachwissens als auch für die Erstellung konzeptueller Entwurfspläne demonstrieren, wie eine Unterstützung der frühen Entwurfsphasen erfolgen kann. Im Rahmen des Projekts wurden die dazu nötigen Grundlagen erarbeitet. Durch die Entwicklung von Software-Werkzeugen wurde zudem in beiden Bereichen die Durchführbarkeit bewiesen und eine mögliche Umsetzung demonstriert. Der Einsatz der ArchiCAD-Erweiterungen bei der Otto-Nussbaum GmbH (Nussbaum 2006) belegt die Tauglichkeit der Werkzeuge im täglichen Projektgeschäft.

3.5 Zusammenfassung Die vorliegende Arbeit betrachtet die semantische Unterstützung der frühen Phasen des architektonischen Gebäudeentwurfs. Die Anwendungsdomäne der Architektur, insbesondere zu Beginn des Entwurfsprozesses, stellt für die Informatik eine Herausforderung dar. Der duale Charakter der Architektur – als Ingenieurwissenschaft einerseits sowie als hochkreativer und künstlerischer Prozess andererseits – erfordert eine angemessene Berücksichtigung. Der konzeptuelle Gebäudeentwurf beschreibt die Projektphase zu Beginn des architektonischen Entwurfsprozesses. Für den konzeptuellen Gebäudeentwurf sind exakte Dimensionen und Materialdefinitionen weniger wichtig als die Darstellung und das Verständnis der Organisation und Funktionsweise eines Gebäudes im

Unterstützung des konzeptuellen Gebäudeentwurfs

175

Ganzen. Die Bedeutung der einzelnen Gebäudeteile und deren Zusammenhang repräsentieren in einem konzeptuellen Entwurf die Summe der Entwurfsentscheidungen und das eingebrachte Fachwissen des Entwerfers. Trotz der frühen Projektphase und des naturgemäß noch hohen Abstraktionsgrads stellt der konzeptuelle Entwurf die Grundlage für alle folgenden Entwurfsphasen dar. Die Weiterentwicklung und Ausrichtung eines Bauprojekts hängt maßgeblich von der frühen Betrachtung aller Entwurfsalternativen und den daraus resultierenden Entscheidungen ab. Aktuelle CAD-Werkzeuge bieten nur wenig Unterstützung für den konzeptuellen Entwurf. Der Schwerpunkt dieser Werkzeuge liegt darin, die Erstellung eines exakten und detaillierten Entwurfsplans zu ermöglichen, der von den am Bau beteiligten Gewerken verstanden und umgesetzt werden kann. Mangels der adäquaten Werkzeugunterstützung weichen viele Architekten bei der Erstellung ihre konzeptuellen Entwürfe z.B. auf einfache Zeichenprogramme aus, die weder domänenspezifische Unterstützung bieten noch in der Lage sind, die semantische Information abzubilden. Bei der späteren Übertragung der konzeptuellen Entwurfsskizze gehen diese wertvollen Informationen verloren. Als Grundlage für die Unterstützung der konzeptuellen Entwurfsphase behandelt dieses Projekt zwei Schwerpunkte. Zunächst wird der Architekt bei der Erstellung konzeptueller Entwurfsskizzen durch innovative Konzepte und angemessene Software-Werkzeuge gefördert. Die entstandenen Werkzeuge ermöglichen, sowohl allein stehend als auch integriert in ein kommerzielles CAD-Werkzeug, die semantische Modellierung konzeptueller Entwurfspläne. Als zweiter Schwerpunkt des Projekts wird die Formalisierung von konzeptuell relevantem Fachwissen durch einen Domänenexperten unterstützt und die automatisierte Prüfung der konzeptuellen Entwurfsskizzen gegen dieses Fachwissen ermöglicht. Hierzu wurde eine formale visuelle Sprache definiert und im Rahmen der entstandenen Werkzeuge implementiert.

Literatur Berners-Lee T, Hendler J, Lassila O (2001) The Semantic Web. Scientific American, 284(5), pp 34–43 Böhlen B, Jäger D, Schleicher A, Westfechtel B (2002) UPGRADE: A Framework for Building Graph-Based Interactive Tools. In: Corradini A et al. (eds) Proc. 1st Intl. Conf. on Graph Transformation, LNCS 2505, Springer, Heidelberg, pp 270–285 Erwig M (1998) Abstract Syntax and Semantics of Visual Languages. Journal of Visual Languages and Computing, 9(5), pp 461–483 Firmenich B (2004) Product Models in Network Based Co-operation in Structural Engineering. In: Beucke K et al. (eds) Proc. of the 10th Intl. Conf. on Computing in Civil and Building Engineering, Bauhaus Universität Weimar, Universitätsverlag (CDROM), pp 1–10 GRAPHISOFT (2006) ArchiCAD (http://www.graphisoft.com/products/archicad) Kirchhof M, Kraft B (2004) UML-based Modeling of Architectural Knowledge and Design. In: Dosch W, Debnath N (eds) Proc. of the 13th Intl. Conf. on Intelligent and Adaptive Systems and Software Engineering, ISCA, Nizza, France, pp 245–250

176

Bodo Kraft, Manfred Nagl

Kraft B (2003a) Conceptual Design Tools in Civil Engineering. In: Pfalz J et al. (eds) Proc. of the Intl. Workshop on Applications of Graph Transformation with Industrial Relevance, LNCS 3072, Springer, Heidelberg, pp 434–439 Kraft B (2003b) Konzeptueller Gebäude-Entwurf in ArchiCAD. In: GRAPHISOFT.NEWS (3), GRAPHISOFT Deutschland GmbH, München, Germany Kraft B, Nagl M (2003a) Support For Conceptual Design in Civil Engineering by Graphbased Tools. In: Grabska E (ed) Proc. of the 1st Workshop on Graph Transformation and Design, Jagiellonian Universität Krakau, Poland, pp 6–7 Kraft B, Nagl M (2003b) Parameterized Specification of Conceptual Design Tools in Civil Engineering. In Pfalz J et al. (eds) Proc. of the Intl. Workshop on Applications of Graph Transformation with Industrial Relevance, LNCS 3072, Springer, pp 90–105 Kraft B, Nagl M (2003c) Semantic Tool Support for Conceptual Design. In: Flood I (ed) Proc. of the 4th Intl. Symp. Information Technology in Civil Engineering, ASCE (CDROM), Nashville, USA, pp 1–12 Kraft B, Nagl M (2006) Visual Knowledge Specification for Conceptual Design: Definition and Tool Support. Advanced Engineering Informatics, pp 1–24 Kraft B, Retkowitz D (2005) Operationale Semantikdefinition für konzeptuelles Regelwissen. In: Weber L, Schley F (Hrsg) Forum Bauinformatik 2005, Lehrstuhl Bauinformatik, BTU Cottbus, Cottbus, S 1–10 Kraft B, Retkowitz D (2006a) Graph Transformations for Dynamic Knowledge Processing. In: Robichaud E (ed) Proc. of the 39th Hawaii Intl. Conf. on System Sciences, Kauai, Hawaii, IEEE Press (CD-ROM), pp 1–10 Kraft B, Retkowitz D (2006b) Rule-Dependencies for Visual Knowledge Specification in Conceptual Design. In: Rivard H (ed) Proc. of the 11th Intl. Conf. on Computing in Civil and Building Engineering, ACSE (CD-ROM), Montreal, Canada, pp 1–12 Kraft B, Schneider G (2005) Semantic Roomobjects for Conceptual Design Support: A Knowledge-based Approach. In: Brown A, Martens B (eds) Proc. of the 11th Intl. CAAD Futures Conf. 2005, Springer, Vienna, Austria, pp 207–216 Kraft B, Wilhelms N (2004) Interactive distributed Knowledge Support for Conceptual Building Design. In: Beucke K et al. (eds) Proc. of the 10th Intl. Conf. on Computing in Civil and Building Engineering, Bauhaus Universität Weimar, Universitätsverlag (CD-ROM), pp 1–14 Kraft B, Wilhelms N (2005) Visual Knowledge Specification for Conceptual Design. In: Soibelman L, Pena-Mora F (eds) Proc. of the 2005 ASCE Intl. Conf. on Computing in Civil Engineering, ASCE (CD-ROM), Cancun, Mexico, pp 1–14 Kraft B, Meyer O, Nagl M (2002) Graph Technology Support For Conceptual Design in Civil Engineering. In: Schellenbach-Held M, Denk H (eds) Proc. of the Intl. Workshop of the European Group for Intelligent Computing in Engineering, VDI Fortschritt Berichte (180), VDI-Verlag, Darmstadt, pp 1–35 Meißner U, von Mitschke-Collande P, Nitsche G (1992) (Hrsg) CAD im Bauwesen. Springer, Heidelberg Otto Nussbaum GmbH & Co KG (2006) CarSatellite (http://www.car-satellite.de) Schmitt G (1993) Architectura et Machina – Computer Aided Architecural Design und Virtuelle Architektur. Vieweg, Wiesbaden Schürr A (1991) Operationales Spezifizieren mit programmierten Graphersetzungssystemen. Dissertation, RWTH Aachen, DUV Wiesbaden Steinmann F (1997) Modellbildung und computergestütztes Modellieren in frühen Phasen des architektonischen Entwurfs. Dissertation, Universität Weimar Szuba J (2005) Graphs and Graph Transformations in Design in Engineering. Dissertation, TU Darmstadt

4 Allgemeingültige Benutzungsoberfläche für rechnergestützt koordinierte,vernetztkooperative Planungsprozesse

Georg Pegels, Torsten Weckmann Bergische Universität Wuppertal, Institut für theoretische Methoden und angewandte Informatik {pegels | weckmann}@uni-wuppertal.de

178

Georg Pegels, Torsten Weckmann

4.1 Vorbemerkungen Die Berufserfahrungen der Bearbeiter des Wuppertaler Teilvorhabens sind geprägt durch langjährige Tätigkeit in Ingenieurbüros und Bausoftware-Unternehmen, in denen mit frühen, noch rudimentären Ansätzen vernetzt-kooperativ gearbeitet wurde. An der Front der Entwicklung in der Baupraxis waren bisher bei der Alltagsarbeit grundsätzliche, methodische Lücken bei vernetzt-kooperativer Planung festzustellen, zu deren Lösung die nachfolgend dokumentierte Grundlagenforschung diente. Die Folgen der unzulänglichen methodischen Ansätze bei konventionellen Kooperationen belasten die Baubranche sehr, die in Deutschland seit 10 Jahren stark schrumpft und sich wesentlich verändert. Immer häufiger arbeiten an einem Bauauftrag gleichzeitig mehrere Planungsund Ingenieurbüros aus verschiedenen Ländern an verschiedenen Standorten mit unterschiedlichen Sprachen und Kulturen. Auch die Fertigung und Montage wird global. Die Koordination länderübergreifender Projektteams an vielen Standorten gleichzeitig übersteigt nicht zuletzt durch diese global verteilte Arbeitsweise das menschliche Leistungsvermögen. Dadurch sind Planungsmängel mit strafbewehrten Termin- und Kostenüberschreitungen im Bauwesen leider alltäglich geworden. Die gewohnte Arbeitsweise war in vielen Fällen nicht mehr wettbewerbsfähig. Neue, innovative Ansätze waren deshalb zu erforschen, die Menschen nicht mehr überfordern, sondern die Problematik verteilt-kooperativer Planungsprozesse rechnergestützt koordiniert lösen. Die Benutzungsoberfläche als Schnittstelle zwischen Mensch und Maschine hat dabei zentrale Bedeutung. Sie macht den Leistungsumfang zugänglich, der von den Mitgliedern vernetzt-kooperativer Planung nutzbar ist. Die Benutzungsoberfläche ist deshalb eine Querschnittsaufgabe, die große Praxiserfahrung des „echten Lebens“ im Bauwesen voraussetzt. Die Grundsatzprobleme globaler, international verteilter Kooperation sind weltweit kaum erforscht, geschweige denn praxisreif gelöst. Die Chance ist erkennbar, hier in der Forschung wegweisend zu werden. Dabei stellt bezüglich der Kooperationsmerkmale der Komplettbau besonders umfassende Anforderungen vieler Baugewerke. Besonders weit kann die rechnergestützte Koordination für die stringente Behandlung aller Teilprozesse bei industrieller Planung und Fertigung getrieben werden, die im Stahl-, Holz-, Metall- und Glasbau vorherrschen. Demgegenüber sind die Koordinationsanforderungen einer Baustellenfertigung weniger homogen. Im Bauwesen werden die meisten Informationen durch Bauzeichnungen ausgetauscht. Ingenieure weltweit lesen und verstehen diese Zeichnungen weitgehend ohne Übersetzung in lokale Sprachen und Schriften. Dies bietet im Bauwesen die spezielle Chance, für verteilt-kooperative Planungsprozesse eine auf Zeichnungen aufbauende, möglichst sprach- und textfreie Benutzungsoberfläche für Bausoftware zu konzipieren. Die Erkenntnisse der nachfolgend dokumentierten Grundlagenforschung greifen die maßgeblichen Entwicklungsfirmen für Bausoftware auf, um der globali-

Rechnergestützt koordinierte,vernetzt-kooperative Planungsprozesse

179

sierten Arbeitswelt im Bauwesen in allen Ländern, auch Entwicklungsländern, eine gleichartige Benutzungsoberfläche für Planungsteams zur Verfügung zu stellen. Im relevanten Software-Marktsegment sind dies (in alphabetischer Reihenfolge) die als Marktführer weltweit tätigen Firmen Autodesk, bocad und TEKLA.

4.2 Einleitung und Zielsetzung Die Benutzungsoberfläche von Bausoftware ist die entscheidende Stelle, an der die Leistungen einer Software definiert und zugänglich gemacht werden. Sowohl die Entwickler von Bausoftware als auch die späteren Anwender haben in der Definition der Benutzungsoberfläche die zentrale, gemeinsame Verständigungsbasis. Über die Benutzungsoberfläche sind daher auch in der Grundlagenforschung am konkretesten und allseits verständlich die Leistungen von Bausoftware für vernetzt-kooperative Planungsprozesse zu definieren. Das Teilprojekt verfolgte vor diesem Hintergrund folgende Zielsetzungen: 1. Definition praxistauglicher Programmleistungen von Bausoftware beim Einsatz für vernetzt-kooperative Planungsprozesse einschließlich der spezifischen Anforderungen des industrialisierten Komplettbaus mit Stahl-, Metall-, Holz-, und Glasbau 2. Globale Verständlichkeit von Benutzungsoberflächen bei der gemeinsamen Programmnutzung durch vernetzt-kooperativ arbeitende Ingenieure, die international an vielen Standorten gleichzeitig an einem Planungsobjekt arbeiten 3. Rechnergestützte Koordination vernetzt-kooperativer Planungsprozesse, wenn menschliche Leistungsfähigkeit nicht ausreicht Insgesamt wird angestrebt, grundlegende Erkenntnisse mit international normativer Wirkung als Vorgabe zur Weiterentwicklung von Bausoftware für vernetztkooperative Planungsprozesse zu erarbeiten.

4.3 Beitrag des Projekts zu den Gesamtzielen des SPP und den Zielen der Arbeitsgruppe Im Laufe des Schwerpunktprogramms wurden die oben genannten drei Teilziele deutlich, die als Querschnittsaufgaben der Grundlagenforschung Beiträge des Teilprojekts zu den Gesamtzielen des SPP und den Zielen der Arbeitsgruppe liefern.

180

Georg Pegels, Torsten Weckmann

4.3.1 Definition vernetzt-kooperativer Planungsprozesse für Stahl-, Metall-, Holz- und Glasbau Die Beispiele wurden aus dem Fundus der langjährigen praktischen Berufserfahrung der Bearbeiter des Teilprojekts gewählt, damit neben dem Massivbau auch die andersartigen Produktspektren des Komplettbaus in Stahl-, Metall-, Holz- und Glasbauweise im SPP angemessen berücksichtigt werden. Insbesondere wurden die der Berechnung und Bemessung nachgelagerten, arbeitsintensiven Planungsprozesse des Konstruierens und Detaillierens sowie der Erstellung sämtlicher Fertigungsunterlagen einbezogen. In der ersten Phase des Teilvorhabens wurde zudem als Querschnittsaufgabe des SPP und der Arbeitsgruppe an realen Bauobjekten untersucht, welche spezifischen grundsätzlichen Probleme durch die sehr umfangreichen Produktmodelldaten realer Bauobjekte aufgeworfen werden. Für die beabsichtigte Nutzung der Forschungserkenntnisse im Bauwesen wurden hierfür vor allem in der zweiten Phase des Teilvorhabens Lösungskonzepte vorgeschlagen. 4.3.2 Globale Verständlichkeit von Benutzungsoberflächen vernetztkooperativer Planungsprozesse „Vernetzt-kooperative Planungsprozesse im Konstruktiven Ingenieurbau“ sind in Europa und weltweit globale Prozesse geworden. Konkret bedeutet dies, dass Planungsbüros und Baufirmen aus vielen unterschiedlichen Ländern mit unterschiedlichen Sprachen und zum Teil unterschiedlichen Schriften gemeinsam an Bauvorhaben arbeiten. Sprach- und Schrifthürden können aber bei Planungsprozessen, die auf viele Länder verteilt sind, zumindest für Bausoftware prohibitiv wirken. Während die sprachliche Anpassung eines weltweit millionenfach eingesetzten Betriebssystems an jedes einzelne Land wirtschaftlich lohnend durchführbar ist, trifft dies für Branchensoftware mit wesentlich geringeren Stückzahlen nicht zu. Selbst in der Europäischen Union ist die Sprachenvielfalt zu groß, als dass alle vertretenen Sprachen bei Entwicklung, Wartung und Pflege von Bausoftware wirtschaftlich sinnvoll berücksichtigt werden könnten. Gleichzeitig erscheint es nicht realistisch, dass bis hin zu den Entwicklungsländern mit großem Baubedarf die an vernetzt-kooperativen Planungsprozessen beteiligten Partner sich auf eine Sprache, etwa Englisch, einigen und alle Partner diese Sprache dann auch in dem für Planungsprozesse erforderlichen Maß beherrschen. Was so zunächst als grundsätzliches Dilemma erscheint, kann durch einen konsequenten Forschungsansatz einer allgemeingültigen, also von Landessprachen und Landesschriften möglichst freien Benutzungsoberfläche im Bauingenieurwesen erfolgreicher und vorbildlicher gelöst werden, als in vielen anderen Branchen. Das Bauingenieurwesen ist nämlich dadurch charakterisiert, dass der Informationsaustausch in der Praxis hauptsächlich über Bauzeichnungen erfolgt, die in jedem Land verstanden werden. Technische Zeichnungen sind von Natur aus (bis auf relativ geringe Anteile von textförmigen Bemerkungen) weltweit allgemeingültig verständlich.

Rechnergestützt koordinierte,vernetzt-kooperative Planungsprozesse

181

Die spezifisch sich bietende Chance des Bauwesens durch Zeichnungen die prohibitiven Hürden von unterschiedlichen Landessprachen und Schriften zu überwinden, wurde daher im Teilprojekt als methodische Querschnittsaufgabe angegangen. Naturgemäß führt diese Grundlagenforschung zu Erkenntnissen auf dem Gebiet der Benutzungsoberflächen von Bausoftware. So wurde eine für die übrigen Teilprojekte nützliche Methodik zur Konzeption von Benutzungsoberflächen entwickelt. An praxisrelevanten Beispielen hoher Nutzungshäufigkeit wurden normative Vorschläge unterbreitet, um experimentell im Komplettbau die Machbarkeit des ambitionierten Ansatzes zu verifizieren. 4.3.3 Rechnergestützte Koordination vernetzt-kooperativer Planungsprozesse Als Querschnittsaufgabe zugunsten der Gesamtziele des SPP wurde der Aspekt erforscht, vernetzt-kooperative Planungsprozesse rechnergestützt überwacht zu koordinieren. In der Baupraxis scheitert das Bauingenieurwesen methodisch an den Unzulänglichkeiten konventioneller Koordination durch überforderte Bearbeiter. Menschliches Leistungsvermögen reicht bei räumlich, an verschiedenen Standorten verteilten, kooperativen Planungsprozessen nicht aus. Bei globaler Verteilung wird dieses Problem nochmals verschärft. Dies gilt nicht nur für die Schnittstellen zwischen Tragwerksplanung und Konstruktion, sondern für sämtliche am Herstellprozess von Bauobjekten beteiligten Partner und die entsprechenden Schnittstellen. Aufgrund der umfangreichen praktischen Berufserfahrungen in Ingenieurbüros des Stahlbaus und Komplettbaus, zum Teil auch als Pilotanwender von Bausoftware, konnten die Bearbeiter des Teilvorhabens aus konkreten Fällen die Bedarfsspektren rechnergestützter Koordination vernetzt-kooperativer Planungsprozesse herleiten und beispielhaft Lösungsvorschläge konzipieren.

4.4 Erkenntnisse zu Benutzungsoberflächen für überwacht koordinierte, vernetzt-kooperative Planungsprozesse Die Auswertung der Alltagsarbeit in technologisch führenden Planungs- und Ingenieurbüros hat zu folgenden Erkenntnissen geführt: 1. Über den gesamten Planungs- und Herstellprozess eines Bauwerks arbeiten auch heute schon sehr viele unterschiedlich spezialisierte Büros und Firmen zusammen, die an mehreren Standorten z. T. in Ländern mit verschiedenen Sprachen verteilt sind. 2. Vernetzt-kooperative Arbeitsweise läuft nicht nach funktionalen Gesichtspunkten sequentiell ab, sondern überlappend oder gar gleichzeitig mit Rekursion durch Änderungen.

182

Georg Pegels, Torsten Weckmann

3. Die spezifischen Anforderungen der einzelnen Baugewerke, insbesondere im Komplettbau, werden derzeit nur von CAD-Hochleistungssystemen genügend erfüllt, die auch für Großbauwerke ausreichend ein zentrales, die Gewerke übergreifendes, Produktmodell verwenden. 4. Vernetzt-kooperative Prozesse werden auch von führenden CADHochleistungssystemen nur elementar und fehleranfällig unterstützt. Rechnergestützt überwachte Koordination fehlt. 5. Vernetzt-kooperative Arbeitsweise mit konventionellen Mitteln überschreitet bei mittleren und großen Planungsobjekten regelmäßig das menschliche Leistungsvermögen. 6. Die Benutzungsoberflächen auch von CAD-Hochleistungssystemen sind bisher in starkem Maße abhängig von Landessprachen, Text und Schriftzeichen. Sie behindern globale Kooperation über Sprachgrenzen hinweg, obwohl hier der größte Baubedarf herrscht, z.B. Wohnungsbau in Ländern mit großem Bevölkerungswachstum. Aus diesen Erkenntnissen wird gefolgert, dass eine inhaltlich auch für den Komplettbau bedarfsdeckende, möglichst textfreie Benutzungsoberfläche zu konzipieren ist, die alle am Planungs- und Herstellprozess Beteiligten gemeinsam und einheitlich nutzen. Diese Benutzungsoberfläche muss alle Funktionen für rechnergestützt überwachte Kooperation enthalten. Erkenntnisse, Merkmale und Lösungen für eine global verständliche Benutzungsoberfläche für vernetzt-kooperativ eingesetzte CAD-Hochleistungssysteme in der Planung und Fertigung werden im folgenden Kapitel vorgestellt. Daran schließt sich die Darstellung der für rechnergestützt überwachte Kooperation erforderlichen Funktionen und ihre Benutzungsoberfläche an. 4.4.1 Allgemeingültigkeit (Internationalität) von Benutzungsoberflächen für vernetzt-kooperativ eingesetzte CADHochleistungssysteme Im Bauingenieurwesen erfolgt der Informationsaustausch in der Praxis hauptsächlich über Bauzeichnungen. Diese technischen Zeichnungen sind von Natur aus bis auf relativ geringe Anteile von textförmigen Bemerkungen weltweit allgemeingültig verständlich. Die spezifisch sich bietende Chance des Bauwesens durch Zeichnungen die prohibitiven Hürden von unterschiedlichen Landessprachen und Schriften zu überwinden, wurde daher im Teilprojekt als methodische Querschnittsaufgabe angegangen. Die Problematik wurde bereits einführend in Vorarbeiten der Verfasser untersucht, die in (Chang 2002) dokumentiert wurden. Nachfolgend werden auszugsweise gestalterische Grundsätze und typische Erkenntnisse anhand kurzer Beispiele vorgestellt.

x Allgemein bekannte oder selbsterklärende Elemente ohne Schulungsbedarf verwenden

Rechnergestützt koordinierte,vernetzt-kooperative Planungsprozesse

183

x Passive, aktive und/oder dynamische Grafik sprachübergreifend verständlich gestalten

x Direkte, kontextabhängige Aktionen mit selbsterklärenden Griffen am Objekt anbieten (anstelle tiefer Menüverschachtelungen oder Symbolanhäufungen am Fensterrand) x Analoge Aktionen gleich gestalten mit Wiedererkennungsnutzen x Grafisch informieren statt sprachlich-textlich x Nur jeweils die Aktionsmöglichkeiten auf dem Bildschirm darstellen, die im aktuellen Kontext sinnvoll sind, um Überfrachtung zu vermeiden. Die allgemeine Bekanntheit eines Prinzips hilft bei neuartigen, komplexen Aufgabenstellungen, Schulungsaufwand und Verständnisprobleme zu verringern. Weltweit bekannte Programme der Textverarbeitung und grafischen Präsentation wie Winword, Corel Draw oder Paintbrush verwenden zunehmend ähnliche Basiselemente für ihre Benutzungsoberflächen. Kennt man eines dieser Programme, kann man viele der Funktionen anderer Programme mit gleichen Elementen sofort ohne Schulung nutzen. Das Verhalten dieser Basiselemente darf für Ingenieure weltweit ohne zusätzliche Schulung als bekannt vorausgesetzt werden, z.B. die Eingabeanforderung eines Winkels:

Abb. 4.1. Winkeleingabe, textfrei mit Sinnbild, Eingabefeld und Drehfeld

Links vor dem Eingabefeld wird ein Sinnbild angeordnet, das unabhängig von Sprachen anzeigt, wozu der in das Eingabefeld eingegebene Wert dient. Die linke Position ist gewählt, da in den meisten Sprachen Zahlen von links nach rechts gelesen werden. Selbst in der persischen Schrift (Farsi), in der von rechts nach links gelesen wird, werden die Zahlen von links nach rechts gelesen. Das Drehfeld rechts vom Eingabefeld verhindert Schreibfehler, wenn programmgestützt nur aus dem Vorrat konkret existierender, logisch sinnvoller Möglichkeiten gewählt werden kann. Mit dem Sinnbild ist über die F1-Taste eine kontextsensitive OnlineHilfe verbunden. Jede Eingabe hat sofortige Wirkung auf das Objekt, d.h. die Eingabe ist nicht modal und erfordert keine zusätzliche, abschließende Bestätigung durch eine OK-Schaltfläche. Ein vorangestelltes Erklärungssymbol entfällt ersatzlos, wenn ein Eingabefeld ohnehin eine selbsterklärende Voreinstellung enthält, z.B. eine international genormte Werkstoffbezeichnung oder bei Grafik die Auswahl einer Strichart, s. Abb. 4.2.

Abb. 4.2. Listenfeld mit Strichart, textfrei

Mit diesem Grundprinzip können nun, weltweit allgemein verständlich, textfreie Zeichnungen für Konstruktionsaufgaben konzipiert werden, die als Leitbilder

184

Georg Pegels, Torsten Weckmann

gleichzeitig Dokumentation und Eingabeformular in sich vereinen. Diese neue Form textfreier Leitbilder für globale Kooperationsteams zeigt Abb. 4.3 anhand eines Konstruktionsprinzips für Rahmenecken. Dateneingaben werden direkt in der Grafik vorgenommen, z.B. über Eingabefelder als Maßzahlen einer Bemaßung. Die eingegebenen Maße sind dadurch eindeutig und ohne Möglichkeit von Fehlinterpretation klar zugeordnet. Die in bisherigen CAD-Systemen üblichen Dialogfelder mit einer Kombination aus statischer Grafik und daneben angeordneter Liste von benannten Eingabefeldern leisten dies nicht. Die mangelhafte Zuordnung der Benennung eines Eingabefelds zur zugehörigen Funktion in der Grafik lässt Spielraum für Fehlinterpretationen, abgesehen vom Übersetzungsaufwand. Abbildung 4.3 verdeutlicht die Funktionsweise und den Nutzen derartiger Leitbilder anhand einer noch nicht vollständig textfreien Version.

Abb. 4.3. Leitbild „Rahmenecke Bauart Grafbau“

Leitbilder fassen Information, Dokumentation und Dateneingabe mit Hilfe von statischer, gestaltkonstanter Grafik und Eingabefeldern an selbsterklärender, eindeutiger Position zusammen. Bei statischer Grafik kann der Entwickler des Leitbildes die Form der Objekte durch Übertreibungen so gestalten, dass die Lesbarkeit der Zeichnung bis ins Detail gut bleibt. Gerade im Stahl-, Holz- und Glasbau könnten sonst Details sehr kleingliedrig und somit wegen Überfrachtung schlecht lesbar sein. Die Kombination statischer, nicht naturgetreuer Grafik mit aktiver Grafik in Form von integrierten Eingabefeldern bietet die für den Anwender einfachste Eingabemöglichkeiten. Ergänzende dynamische Grafik, die in Abhängigkeit von jedem eingegebenen Wert sofort die entsprechende Wirkung durch dynamische, maßstäbliche Veränderung der Grafik anzeigt, verbessert zusätzlich die Verständlichkeit.

Rechnergestützt koordinierte,vernetzt-kooperative Planungsprozesse

185

In international weit verbreiteten Programmen sind elementare Funktionsgriffe (auch Anfasser genannt) üblich geworden, z.B. zum Verschieben oder Kopieren von Objekten. Das Funktionsgriffen zugrunde liegende Prinzip ist besonders geeignet für eine direkte, selbsterklärende Benutzungsoberfläche hoher Effizienz. Abbildung 4.4 zeigt die Vereinfachung durch derartige selbsterklärende „Griffe“ an CAD-Objekten.

Abb. 4.4. Griffe für Verlängern, Profiländern, Verschieben, Kopieren

Griffe werden also unmittelbar an intelligent reagierenden CAD-Objekten angebracht und vereinfachen die Bedienung wie folgt: Das Verlängern bzw. Verkürzen des Objekts „Profilstab“ geschieht durch Ziehen des entsprechenden Griffs direkt an der gewählten Stirnseite, bis das gewünschte Verlängerungsmaß erreicht ist. Das Maß wird als Statuszeile laufend angezeigt. Der Profilstab reagiert anschaulich mitlaufend, kombiniert mit der Funktion „Einrasten“. Gestaltet man die Verlängerungs-Griffe verschiebbar von der Stirnseite an einen anderen Ort auf der Stabachse, an dem Dehnen oder Stauchen erwünscht ist, steigt der Leistungsumfang sogar ohne zusätzliche Symbole. Zieht man den Profilgriff quer zur Stabachse, wird das bisherige Profil gegen das jeweils nächste Profil der gleichen Profilreihe ersetzt. Dabei werden die ursprünglichen Lageparameter des Trägers automatisch beachtet, d.h. ein bündig verlegter Träger bleibt bündig. Auch die logischen, konstruktiven Konsequenzen der Aktion werden beachtet: An einen Hauptträger über Doppelwinkel oder Kopfplatten angeschlossene Nebenträger bieten an, den Anschluss und die Schraubenanordnung automatisch der so geänderten Profilgröße anzupassen. Es werden also nicht nur die bautechnischen Schlussfolgerungen gezogen, dass ein Profil nur in diskreten, lieferbaren Profilsprüngen geändert werden kann, sondern auch die we-

186

Georg Pegels, Torsten Weckmann

sentlich komplexeren Schlussfolgerungen, welche Konsequenzen die Änderung auf die umgebenden Teile hat. Dies erfordert erhebliche Bauingenieurintelligenz der CAD-Objekte, wie im Projekt vorgeschlagen. 4.4.2 Benutzungsoberfläche für die rechnergestützte Koordination vernetzt-kooperativer Planung Die Pilotanwendungen der Phasen I und II ergaben konkrete Forderungen an das Systemverhalten und die Benutzungsoberfläche. Die an ausgesuchten Planungsaufträgen kooperierenden Ingenieurbüros waren überfordert, um allein mit menschlichen Mitteln die lückenlose Überwachung und Koordination paralleler, örtlich verteilter Arbeit sicherzustellen. Statt menschlicher Kontrolle ist deshalb lückenlos rechnergestützte Koordination erforderlich, insbesondere wenn mehrere CAD-Bauingenieure und Planer am gleichen Objekt von unterschiedlichen Standorten aus gleichzeitig arbeiten. Durch die zunehmende Internationalisierung der Bearbeitungsteams und die gleichzeitige Bearbeitung an verschiedenen Standorten auf der Welt ist hierfür eine Benutzungsoberfläche zu schaffen, die barrierefrei eine zeichnungsorientierte Benutzungsoberfläche bietet. Die eigenen Untersuchungen mit langjährig erfahrenen CAD-Ingenieuren aus Deutschland und aus Entwicklungsländern haben ergeben, dass die spezifische Benutzungsoberfläche zur rechnergestützten Überwachung und Koordination den Anwender bei der produktiven Arbeit am Bildschirm nicht unerwünscht stören oder unterbrechen darf. Auch Überfrachtung der Darstellungen auf dem Bildschirm durch Komponenten anderer Kooperationspartner wird nicht akzeptiert. Sinnvoll ist eine farbige Abgrenzung nach Verantwortungsbereichen. Still mitlaufende, rechnergestützte Konsistenzprüfungen, Statuskontrollen und Benachrichtigungen sollen grundsätzlich nur gesammelt zu einem Zeitpunkt auf dem Bildschirm erscheinen, den der einzelne Bearbeiter selbst bestimmt. In der Konstruktion bietet sich zur rechnergestützt gesicherten Koordination spätestens der Zeitpunkt einer Zeichnungsfreigabe an. Für die Einhaltung qualitätsgesicherter Prozesse ist es sinnvoll, die Konsistenzprüfungen und Statuskontrollen an den traditionell vorhandenen Schnittstellen zu Nachbarbauteilen zum frühestmöglichen Zeitpunkt durch den Bearbeiter durchführen zu lassen. Unter allen Umständen darf eine Freigabe von Zeichnungen ohne die o. a. Prüfungen nicht möglich sein. Für die unterschiedlichen Freigabeprozeduren werden zunächst folgende Symbole vorgeschlagen, bis geklärt ist, ob das deutsche Verkehrszeichen „Freie Fahrt“ international ohne Erläuterung verständlich ist: -

Freigabe ist bisher noch nicht erfolgt

-

Freigabe begonnen, jedoch noch nicht abgeschlossen

Rechnergestützt koordinierte,vernetzt-kooperative Planungsprozesse

187

Freigabe erfolgt und fertig gestellt

-

Grundsätzlich sind zwei Freigabeszenarien zu unterscheiden: 1. Freigabe in planerischer Hinsicht mit folgenden Statusstufen, die bei internationalen Projekten üblich sind: IFI: IDC: RFI: RFF: RFE:

issued for information issued for interdisciplinary check request for information ready for fabrication ready for erection

2. Freigabe in fertigungs- und montagetechnischer Hinsicht mit folgenden Kontrollen: -

Übereinstimmung der Profilbezeichnungen mit dem Warenwirtschaftssystem des Fertigungsbetriebes, insbesondere bei ungenormten Zukaufteilen Überprüfung des verwendeten Materials auf Übereinstimmung mit Lagermaterial und/oder bestelltem Material Überprüfung der verwendeten Schrauben, Bolzen, Dübel etc. auf Konformität mit den Unterlagen des Fertigungsbetriebes Überprüfung der Zeichnungen in schweißtechnischer Sicht (Ausführbarkeit der Nähte, zweifelsfreie Anordnung der Schweißnähte, ...) Vollständigkeit der Montageunterlagen

Anwender vernetzt-kooperativer Planungssoftware fordern weiterhin, dass CADIngenieure stillschweigend die von ihnen selbst konstruierten Bauteile an fremde Bauteile des gemeinsamen Produktmodells im Netz anschließen dürfen, für deren Konstruktion andere Ingenieure verantwortlich sind. Der verantwortliche CADIngenieur soll in der Benutzungsoberfläche also keine Echtzeit-Nachrichten auf dem Bildschirm erhalten, wenn Kollegen seine Komponenten schreibend verändern. So soll eine Flut von Zwischengenehmigungen ersetzt werden durch eine einzige, abschließende Genehmigung von Fremdänderungen, spätestens zum Zeitpunkt der Zeichnungsfreigabe. Die Baupraxis stellt also eine kombinierte Forderung an die Benutzungsoberfläche: Automatische Überwachung und Koordination der verteilt-kooperativen Planungsprozesse, jedoch ungestörtes, kontinuierliches Arbeiten am Bildschirm mit Koordinationspunkten nach eigener Entscheidung oder zwangsweise nur an den Koordinationspunkten zwischen den Prozessphasen bei Zeichnungsfreigabe. Nur temporär bestehende Pseudokonflikte filtert dieser Ansatz bis zum Freigabezeitpunkt ohne Störung parallel arbeitender Kooperationspartner aus, d. h. die Benutzungsoberfläche bleibt hiervon unbelastet. Zum Freigabezeitpunkt bietet sich eine automatische Qualitätssicherung an, die z.B. Träger auf dem Bildschirm als „verdächtig“ farblich kennzeichnet, die nicht an beiden Enden detailliert und mit Anschlüssen versehen sind. Auch Körper-Körper-Kollisionen ab einer unzulässigen Eindringtiefe können so zur Entscheidung vorgelegt werden. Durch mul-

188

Georg Pegels, Torsten Weckmann

timediale Hilfen der Benutzungsoberfläche, wie Blinken und automatisches Heranzoomen, wird die Beseitigung des Konflikts zum gewünschten Koordinationszeitpunkt systematisch erzwungen. Auch im konventionellen Planungsprozess sind Statusinformationen einzelner realer oder abstrakter Bauobjekte, wie Kantbleche, Träger, Verbindungsmittel, Anschlüsse, Nachforderungen, Baugenehmigungen etc. entscheidende Auslöser für Überwachungs- und Koordinationsaktionen mit spezifischen Vorlaufzeiten für einzelne Planungsphasen. Um Überwachung und Koordination vernetztkooperativer Planungsprozesse zu automatisieren, sind Statusinformationen das entscheidende Schlüsselkriterium der Benutzungsoberfläche. Darüber hinaus war zu erforschen, wie die Statusinformationen von Bauobjekten durch Vernetzung z.B. mit der kaufmännischen Unternehmenssoftware möglichst ohne zusätzliche zeitliche Belastung der Partner des verteilt-kooperativen Prozesses automatisch aktualisiert werden können. Material-Statusinformationen werden z.B. benötigt für die Ereignisse „Bestellt“, „Eingetroffen“ und „Qualitätsgeprüft“, jeweils mit Werten für „Erledigt“, „Beleg“ und „Datum“. Sie würden den Konstrukteur und Projektleiter überlasten, wenn sie interaktiv zu pflegen wären, wie die im Vorprojekt erfasste heutige Baupraxis zeigt. Über den Objektstatus ist die lückenlose Organisation und Dokumentation der jeweiligen Verantwortlichkeit sicherzustellen, die auch bei rascher Änderungsfolge nicht wegen menschlicher Überforderung abbricht. Der Status „Statisch nicht genehmigt“ oder „Material nicht gesichert“ führt bei der automatischen Überwachung und Koordination über die Benutzungsoberfläche zu Aktionen in der Kette der Verantwortlichkeiten. Das rechnergestützte, den Verantwortlichkeiten folgende Management des Planungsprozesses über Statusinformationen, sei an zwei exemplarischen Beispielen vorgestellt: Der Tragwerksplaner ist im Planungsprozess für die Phase der statischen Berechnung und Bemessung des Tragwerks (oder kooperativ eines Teiles davon) verantwortlich. Er verantwortet die Profilabmessungen und die Lage der Rohstäbe des Tragwerks, also den Objektstatus „Statisch genehmigt“. Der mit diesen Vorgaben konstruierende Ingenieur ist in vielen Baufirmen auch verantwortlich für die rechtzeitige Materialsicherung, also den Status „Material gesichert“. Er detailliert nach der Materialsicherung die Anschlüsse der Stäbe miteinander und verantwortet dabei mit fortschreitendem Detaillierungsgrad funktionale Restriktionen, z.B. Kollisionen mit bauseitig vorhandenen Komponenten, wie Rohrleitungen, Apparate, Fluchtwege oder einzuhaltende Kontaktflächen zur Bauwerkshülle. Dies kann zu Konflikten führen, die nur durch wesentliche Änderung der Lage oder der Profilabmessungen zu lösen sind. Auch mangelnde Verfügbarkeit eines Profils kann zu diesem Konflikt führen. Da der konstruierende Ingenieur zu Profil- oder Lageänderungen von Tragwerksstäben nicht autorisiert ist, ändert der Konflikt im gemeinsamen Produktmodell durch seine Aktion automatisch den Objektstatus der veränderten Objekte auf „Statisch nicht genehmigt“ zurück. Die Änderung legt er dem verantwortlichen Tragwerkplaner netzgestützt über die Benutzungsoberfläche in interaktiv-grafischer Form mit Signalfarbdarstellung des betroffenen Tragwerksbereichs zur Genehmigung vor. Zwischenzeit-

Rechnergestützt koordinierte,vernetzt-kooperative Planungsprozesse

189

lich kann er anderweitig sinnvoll weiterarbeiten. Ändert der Tragwerkplaner nicht binnen einer Frist den Status auf „Statisch genehmigt“, erhält der Konstrukteur automatisch eine interaktiv-grafische Terminwarnung zum Status. Die Genehmigung des Tragwerkplaners durch die Änderung in „Statisch genehmigt“ ändert den Revisionsstand des betroffenen Objekts und dokumentiert die Änderung, z.B. für Nachträge und überprüft den Status „Materialsicherung“. Neben diesem Fallbeispiel der Überwachung von abhängigen Kooperationen zwischen verschiedenen Phasen des Planungsprozesses ist auch der Fall gleichzeitiger, verteilter Arbeit in ein und derselben Phase über Statusinformationen überwachbar mit Interaktion über die Benutzungsoberfläche. Konsistenzüberwachung und -sicherung ist erforderlich, wenn zwei Ingenieure gleichzeitig an demselben Bauwerk konstruieren und ihre Bauobjekte zumindest teilweise in gemeinsamen Kontaktzonen liegen. Der Konstrukteur eines Treppenturms muss seine Treppen an Bühnen anschließen, für die andere Konstrukteure verantwortlich sind. Die Anschlüsse verändern also im Detail, nicht jedoch bezüglich des statisch genehmigten Profils, die Bühnenträger eines fremden Verantwortungsbereichs. Wie im Arbeitsbericht zum Vorprojekt und durch eigene Feldstudien festgestellt, lassen die verantwortlichen Konstrukteure derartige Änderungen durch Fremdkonstrukteure ausdrücklich als „stille Änderungen“ ohne EchtzeitMeldung zu. Unter berufserfahrenen Kooperationspartnern, die gegenseitige Arbeitsstörungen minimal halten wollen, ist diese stille Vorgehensweise sinnvoll und verantwortbar. Spätestens jedoch bei Zeichnungsfreigabe muss über den Status „Fremdänderung“ eine Kontrolle der von Fremdänderungen betroffenen Objekte durch den jeweils verantwortlichen Konstrukteur erzwungen werden. Jeder vernetzt-kooperativ am Planungsprozess Beteiligte kann sich über die Benutzungsoberfläche durch Filter den Objektstatus ausgewählter Objekte interaktiv-grafisch anzeigen lassen. Wenn ein am Koordinationspunkt erforderlicher Status nicht erfüllt ist, wird er spätestens bei Anforderung der Freigabe einer Planungsphase zwangsweise angezeigt. Gibt der Verantwortliche in Kenntnis dieses Sachverhalts, z.B. aus Termingründen, dennoch frei, erfolgt in Intervallen zwangsweise eine Wiedervorlage der Objekte, deren Status an diesem Koordinationspunkt verletzt ist. Im Gegensatz zu konventionellen, listenbasierten Verfahren ist die Benutzungsoberfläche bei vernetzt-kooperativer Arbeitsweise auch für die rechnergestützte Koordination mit neuartigen Elementen durch visuelle, grafische Projektinformation zu gestalten. Über Filter für Kriterienkombinationen können Fragestellungen in grafischer Form, z.B. farbliche Markierung in 3D-Darstellung auf dem Bildschirm, statt in Form von Listen, sichtbar gemacht werden. Zusammen mit den in Phase II entwickelten Statusinformationen sind so z.B. folgende Fragestellungen ohne Aufwand für den Anwender zu klären: Ist für alle Bauteile der Zeichnung, die freigegeben werden soll, die Statik fertig und geprüft? Ist das benötigte Material angefordert, bestellt, geliefert, aus Lagerbestand gesichert? Welche Bauteile sind derzeit gefertigt, versandt, montiert, abgerechnet?

190

Georg Pegels, Torsten Weckmann

Neben passiven Informationsanfragen ist die Benutzungsoberfläche mit grafisch-interaktiver Direktwahl von Objekten am Bildschirm auch für diese Eingaben oft besser geeignet als Dialogfenster es sein können. So sind Baugruppen, Montageabrufe oder Fertigungslose direkt durch Wahl der dargestellten Objekte am Bildschirm zusammenzustellen. Sie zeigen als Quickinfo oder über entsprechende Farbdarstellung ihren Status. An Bildschirmen in der Fertigung, wie in technisch führenden Unternehmen bereits eingeführt, können zusätzliche Darstellungen, Testmaße u. ä. direkt aus dem zentralen Modell im Bedarfsfall hergeleitet werden. Ebenso ist auf der Baustelle bei der Montage jedes Kontrollmaß direkt im grafisch dargestellten Produktmodell abgreifbar.

4.5 Anwendungsbeispiele Die folgenden Anwendungsbeispiele aus der Praxis vernetzt-kooperativer Bearbeitung veranschaulichen die Forschungserkenntnisse des Teilprojekts unter realen Bedingungen. Wie in Abb. 4.6 ersichtlich, stoßen an einem zentralen Knotenpunkt, hier einer Industrieanlage, die Verantwortungsbereiche vieler Kooperationspartner aneinander und beeinflussen sich gegenseitig. Hierdurch kommt es in der Praxis zu einem erheblichen Konfliktpotential, insbesondere wenn Änderungen bzw. Ausführungsdetails an der Sekundär- und/oder Tertiärkonstruktion zu Veränderungen am Tragsystem der Primärkonstruktion führen. In diesen Fällen ist zwingend eine „konzertierte“, rechnergestützt koordinierte Freigabe erforderlich.

Abb. 4.5. Lochbilder im Riegel fehlen, da ohne rechnergestützte Koordination konstruiert

Rechnergestützt koordinierte,vernetzt-kooperative Planungsprozesse

191

Bearbeiter 8 Wandriegel 2

Bearbeiter 2 Stützen

Bearbeiter 3 Verbände vertikal

Bearbeiter 7 Wandriegel 1

Bearbeiter 6 Geländer Bearbeiter 4 Bühnenebene

Bearbeiter 1 Verbände vertikal

Bearbeiter 5 Verbände horizontal

Bearbeiter 7 Wandriegel 1

Bearbeiter 7 Wandriegel 1

Bearbeiter 3 Verbände vertikal

Bearbeiter 9 Bühnenbelag (nicht dargestellt)

Abb. 4.6. Verantwortungsbereiche am Knoten

Im Beispiel der Abb. 4.5 wurden Dachriegel, Pfetten, Pfettenschuhe und Pfettenverhängungen an unterschiedlichen CAD-Arbeitsplätzen konstruiert. Beim Zusammenladen der Teilkonstruktionen erfolgte keine Überwachung der Elemente durch rechnergestützte Koordination. Der verantwortliche Konstrukteur der Pfettenverhängungen gab die Konstruktion daher ohne eine explizite Freigabe des Bearbeiters der Primärkonstruktion für die Fertigung frei. Auf der Baustelle stellte sich dann heraus, dass die Bohrungen für die Pfettenschuhe nicht in die Riegel übernommen worden waren. Aus diesem Fehler resultierten erhebliche Kosten, da auf der Baustelle alle Bohrungen in den betroffenen Riegeln nachträglich hergestellt werden mussten. In einem weiteren Fall der Pilotanwendung von Vorstufen vernetztkooperativer Planung wurde bei einem Luftkühlergerüst der so genannte Lüfterlaufring nicht von dem Bearbeiter der primären Stahlkonstruktion übernommen. Hierdurch wurde die Kollisionsprüfung mit einem unvollständigen Modell ausgeführt. Ohne automatisierte, rechnergestützte Überwachung gab der Bearbeiter die Stahlkonstruktion frei, ohne dass alle potentiellen Kollisionsteile untersucht wur-

192

Georg Pegels, Torsten Weckmann

den. Nur zufällig wurde bei einem späteren Kollisionstest festgestellt, dass Vertikalverbände und Lüfterlaufring kollidieren. Da der komplette Designprozess zu diesem Zeitpunkt bereits abgeschlossen war, musste mit einem erheblichen Aufwand das statische Konzept überarbeitet und Teile der Konstruktion neu konstruiert werden. Glücklicherweise erfolgten diese Änderungen, bevor die Bauteile für die Fertigung freigegeben waren – in einem solchen Fall wären die entstandenen Kosten zur Mängelbeseitigung noch wesentlich höher gewesen. Auch für das Management des Dokumentenbestandes bei vernetzt-kooperativer Planung mit vielen internationalen Partnern stellte sich rechnergestützte Koordination als unabdingbar heraus, um qualitätsgesichert die Dokumente an die verschiedenen Empfänger zu verteilen.

Abb. 4.7. Benutzungsoberfläche eines Collaboration-Servers bei international vernetztkooperativer Planung (Englisch vertraglich vereinbart)

Erst der Einsatz eines Collaboration-Servers zentral im Netz machte diesen Auftrag mit internationalen Partnern durchführbar. Die nachfolgenden Abb. 4.7, 4.8 und 4.9 zeigen die Ergebnisse dieses Pilotversuchs, der bis zur programmtechnischen Lösung, Schulung der Beteiligten und Dokumentation durchgeführt wurde. Die ingenieurwissenschaftliche Problematik internationaler, vernetzt-kooperativer Planungsprozesse wurde an diesem Praxisfall besonders deutlich. Hier besteht durchaus die Chance, durch entsprechende Planungsleistungen hoher Qualität im Auslandsbau die Marktmöglichkeiten ebenso konsequent wahrzunehmen wie der Maschinenbau. In der Ausbildung der Studierenden der Wuppertaler Universität wurden daher bei der Konzeption des neuen Master-Studiengangs „Planen, Bauen und Betreiben“ die Projekte bewusst im Auslandsbau gewählt. Unter Nutzung der von führenden Softwareunternehmen gestellten CAD-Hochleistungssysteme arbeiten in diesen Projekten ausländische und deutsche Studierende als gemeinsames Team an der Problemlösung. Dadurch gewinnen die deutschen Studierenden das Know-How des Auslandsbaus, das der mittelständischen Bauindustrie weitgehend fehlt. Die ausländischen Studierenden erkennen die Vorteile der Kooperation

Rechnergestützt koordinierte,vernetzt-kooperative Planungsprozesse

193

als wirtschaftliche Zusammenarbeit mit kompetenten Partnern und persönlichen Netzwerken. Die strukturierte und revisionierte Ablage von Informationen wurde über den Server systematisch gelöst, ohne durch Einzelversand von großen Datenmengen via Datenträger oder einzeln zu koordinierende Attachments von E-Mails die sehr umfangreiche Koordination unbeherrschbar werden zu lassen.

Abb. 4.8. Koordination des Zusammenbaus von Baugruppen

Abb. 4.9. Planungsprozess-Objekte im Netz

194

Georg Pegels, Torsten Weckmann

Ein entsprechender Collaboration-Server auf der Grundlage eines ContentManagement-Systems wird derzeit erprobt. Er besitzt Java-basiertes Content Management mit Dokumentenverwaltung einschl. Versionierung, mehrsprachig und Überwachung (Aufgabenverwaltung) einschl. Reminder-Funktionalität.

4.6 Zusammenfassung und Ausblick Die Benutzungsoberfläche von Bausoftware ist die entscheidende Stelle, an der die Leistungen einer Software definiert und zugänglich gemacht werden. Sowohl die Entwickler von Bausoftware als auch die späteren Anwender haben in der Definition der Benutzungsoberfläche die zentrale, gemeinsame Verständigungsbasis. Über die Benutzungsoberfläche sind daher auch in der Grundlagenforschung am konkretesten und allseits verständlich die Leistungen von Bausoftware für vernetzt-kooperative Planungsprozesse zu definieren. Das Teilprojekt hat vor diesem Hintergrund zu folgenden Punkten Erkenntnisse erbracht: Definition praxistauglicher Programmleistungen von Bausoftware beim Einsatz für vernetzt-kooperative Planungsprozesse einschließlich der spezifischen Anforderungen des industrialisierten Komplettbaus mit Stahl-, Metall-, Holz- und Glasbau. Globale Verständlichkeit von Benutzungsoberflächen bei der gemeinsamen Programmnutzung durch vernetzt-kooperativ arbeitende Ingenieure, die international an vielen Standorten gleichzeitig an einem Planungsobjekt arbeiten. Die konzipierte Benutzungsoberfläche verwendet daher weltweit verständliche Bauzeichnungen, weitgehend frei von Texten und Schriftzeichen. Rechnergestützte Koordination vernetzt-kooperativer Planungsprozesse, wenn menschliche Leistungsfähigkeit nicht ausreicht. Insgesamt wird angestrebt, die erarbeiteten grundlegenden Erkenntnisse mit international normativer Wirkung als Vorgabe zur Weiterentwicklung von Bausoftware für vernetzt-kooperative Planungsprozesse als Transfer weiterzugeben. Die Firmen Autodesk, bocad und Tekla gehen diese Entwicklung im vorwettbewerblichen Bereich gemeinsam an, koordiniert und wissenschaftlich begleitet durch die Bergische Universität Wuppertal.

Literatur Azadnia H, Eslimy-Isfahany SHR, Pegels G (2007) A Survey on Adaptability/Application of IT in Building Industry in Iran (for submission in ACM-Computing Surveys) Chang Y (2002) Eine von Landessprachen unabhängige Nutzoberfläche mit intelligenten CAD-Objekten des Bauwesens. Dissertation, Fachbereich Bauingenieurwesen, Bergische Universität Wuppertal Dadam S, Pegels G (2004) Alumni-Sommerschule Iran/Deutschland in Wuppertal. In: vision Beiträge aus Architektur und Bauingenieurwesen, Heft 4, Bergische Universität Wuppertal, S 36ff

Rechnergestützt koordinierte,vernetzt-kooperative Planungsprozesse

195

Eslimy-Isfahany SHR, Azadnia H (2003) Information Technology in Structural Design – A Literature Review and a Call for Practical Deployment. Proceedings of the 6th International Conference on Civil Engineering, May 2003, vol 6, Isfahan University of Technology (IUT), Isfahan, Iran, pp 479–486 Eslimy-Isfahany SHR, Pegels G (2004) Net-distributed Cooperation Including Developing Countries – Practical Case Study Iran, ICCCBE-X, The 10th International Conference on Computing in Civil and Building Engineering, Weimar, pp 98–99 Eslimy-Isfahany SHR, Pegels G (2005) Affordable Earthquake-Resistant Housing for Developing Countries. UNESCO’s Worldwide Engineering Award, final report, Berlin, Germany Eslimy-Isfahany SHR, Pegels G (2006) Seismic-Proof Housing: Reconstruction in Rural Areas. Third International I-Rec Conference, Post-disaster reconstruction: Meeting Stakeholder Interests, May 17–19, Florence, Italy (proceedings in print) Pegels G (2002) Experience with network-based cooperative design and detailing processes including the buildings in Iran. Proceedings of the Seminar on Information Technology, May 2002, Tehran, I.R.Iran Pegels G (2003) Euro-islamischer Dialog im Fachbereich Bauingenieurwesen. In: vision Beiträge aus Architektur und Bauingenieurwesen, Heft 3, Bergische Universität Wuppertal Pegels G (2004) Hochtechnologie für das Bauen im Iran – Vision einer Krisenprävention „Made in Germany“. In: vision Beiträge aus Architektur und Bauingenieurwesen, Heft 4, Bergische Universität Wuppertal, S 33ff Pegels G, Azadnia H (2003) Best Practice Worldwide of Computer Aided Design, Detailing and Fabrication. In: Proceedings of the 6th International Conference on Civil Engineering, May, vol 6, Isfahan University of Technology (IUT), Isfahan, Iran, pp 23– 34 Pegels G, Koch A (2002) DFG-Schwerpunktprogramm 1103 Vernetzt-kooperative Planungsprozesse im Konstruktiven Ingenieurbau, Grundlagen vernetzt-kooperativer Planungsprozesse für Komplettbau. DFG-Arbeitsbericht 1. Phase Schwerpunktprogramm Pegels G, Huhn M, Koch A (2002) Praxiserfahrungen mit vernetzt-kooperativen Planungsprozessen an Bauprojekten des Stahl-, Holz- und Glasbaus und ihre Forschungskonsequenzen. VDI-Tagung „Bauen mit Computern – Kooperation in ITNetzwerken“, 11./12. April 2002, VDI Verlag, Bonn Pegels G, Eslimy-Isfahany SHR, Azadnia H (2003) A Proposal for Best Practice in Design, Detailing and Fabrication of Steel Structures in Developing Countries Based on Worldwide Experience. In: Asian Journal of Civil Engineering (Building and Housing), vol 4, no2-4, pp 87–99 and 149–161 Pegels G, Kabiri S, Eslimy-Isfahany SHR (2006) Baumanagement für Entwicklungsländer? Festschrift C.J. Diederichs, Baubetrieb und Bauwirtschaftslehre, DVP-Verlag, Berlin, S 284–289 Samsamshariat M, Eslimy-Isfahany SHR, Pegels G (2007) Progress in Seismic Hazard Study of Iran (for submission in Natural Hazard)

5 Ein Kooperationsmodell für die Kontrolle divergierender Planungszustände

Raimar J. Scherer, Matthias Weise, Peter Katranuschkov TU Dresden, Institut für Bauinformatik {Raimar.Scherer | Matthias.Weise | Peter.Katranuschkov}@cib.bau.tu-dresden.de

5.1 Problemstellung und Projektziele Die besonderen Vorteile der vernetzt-kooperativen Planung sind eine verstärkte Parallelisierung der Planung bei gleichzeitig reduziertem persönlichen (physischen) Kontakt der Planungsbeteiligten. Um diese Vorteile zu erreichen, ist die Verwaltung gemeinsamer Planungsdaten notwendig. Produktmodelle werden hierbei als Grundlage allgemein anerkannt (Eastman 1999). Probleme entstehen durch die parallele, voneinander unabhängige Bearbeitung der Planungsdaten sowie die trotz Standardisierungsbemühung unvermeidbare Heterogenität der eingesetzten, hochspezialisierten Fachmodelle. Hieraus resultieren divergierende Planungszustände, aber auch Informationsverluste, die einvernehmlich aufgelöst bzw. verhindert werden müssen. Daher sind Methoden, die dazu beitragen, dass divergierende Planungszustände wieder geordnet und ohne (physikalische) Koordinierungsgespräche sowie Zeitverluste in konsistente Planungszustände parallel zur laufenden Weiterplanung und ohne Informationsverlust zurückgeführt werden können, von außerordentlicher Bedeutung. Durch die Vielzahl der eingesetzten Fachmodelle, die nur unvollständig in einem gemeinsamen Bauwerksmodell (Building Information Model, abgekürzt BIM) zusammengeführt werden können, ist der Einsatz standardisierter Produktdatenmodelle mit Kompromissen hinsichtlich der austauschbaren Informationen verbunden (Turk 2001). Erschwerend kommt hinzu, dass die Qualität der wiederholt stattfindenden Datenabgleiche von zahlreichen, nicht unmittelbar beeinflussbaren Faktoren abhängig ist. Hierzu gehören vor allem die Modellierungsphilosophie des verwendeten Produktmodells sowie die Datenqualität der eingesetzten CAD-Programme. Der hier vorgestellte Ansatz verfolgt das Ziel, die Qualität der kooperativ genutzten Planungsdaten zu verbessern und mögliche Fehler und Pla-

198

Raimar J. Scherer, Matthias Weise, Peter Katranuschkov

nungskonflikte für die Planer erkennbar zu dokumentieren. Erst dadurch ist es aus Sicht der Autoren möglich, Methoden der Produktdatenverwaltung schrittweise in der Praxis einzusetzen (Amor u. Faraj 2001). Der nachfolgend vorgestellte Ansatz und die hierfür entwickelten Methoden beruhen auf drei Prinzipien: 1. Transparenz, um den Planungsprozess und die dabei vorgenommenen Änderungen nachvollziehbar zu dokumentieren, 2. Flexibilität, um von konkreten Produktdatenmodellen zu abstrahieren und einen verallgemeinerten, d.h. wiederverwendbaren Ansatz zu erforschen, und 3. Fehlertoleranz, um mit den auftretenden technischen Unzulänglichkeiten der eingesetzten Planungsprogramme umgehen zu können. Mit dieser Herangehensweise, die kein vollständig automatisiertes Verfahren erfordert und den Planer aktiv in die Pflege der gemeinsamen Datenbasis einbezieht, kann das kooperative Arbeiten mit vergleichsweise geringen Anforderungen an die eingesetzten CAD-Programme realisiert werden.

5.2 Lösungsansatz Die nachfolgende Übersicht über den erforschten Ansatz soll die Bewertung der erzielten Ergebnisse erleichtern. Durch ein verallgemeinertes Kooperationsmodell werden zunächst die entwickelten Methoden beschrieben und der Bezug zum Planungsablauf hergestellt. Aus diesem Kooperationsmodell werden Kooperationsszenarien abgeleitet, die die Anwendung der entwickelten Methoden verdeutlichen. Schließlich wird der Beitrag zu den Zielen des Schwerpunktprogramms dargestellt. 5.2.1 Kooperationsmodell Das zugrunde liegende Kooperationsmodell strukturiert die Planungsphasen in wiederkehrende parallele Planungsprozesse mit Planungs- bzw. Modellkoordinationspunkten, die durch die Prozesse Modelltransformation, Modellvergleich und Modellzusammenführung geprägt sind (Weise et al. 2004a). Der Umgang mit Teildatensätzen, der das Herauslösen der benötigten Produktdaten sowie die Aktualisierung des Gesamtdatensatzes beinhaltet, ist dabei ein wesentlicher Bestandteil eines Bearbeitungsschrittes. Dieser in Abb. 5.1 gezeigte Ablauf, der die Schritte der Produktmodellverwaltung beschreibt, wird durch die hier erforschten, datenmodellunabhängigen1 und damit wiederverwendbare Verfahren unterstützt.

1

Die Grundlage des Ansatzes bildet das Metamodell, konkret die Modellbeschreibungssprache EXPRESS (ISO 10303-11).

Ein Kooperationsmodell für die Kontrolle divergierender Planungszustände

199

Idealisierter Planungsablauf mit den Phasen der parallelen Bearbeitung (Prozessphase) und Koordination (Koordinationspunkte) Koordinationspunkt

t0

Prozessphase Planungsfortschritt

t2

t1

tN

Temporär divergierende Planungsstände als Folge der parallelen Bearbeitung

n Teilmengenbildung,

Modelltransformation Modellvergleich

o p Modellvereinigung

zentrale Verwaltung gemeinsamer Gesamtdatensatz Planungsdaten

Gesamtdatensatz MTi 1(BIM)

M i+1 (BIM) T

2

n ti

lokale Arbeitsumgebung des Fachplaners, z.B. des Tragwerksplaners

Teildatensatz S i+1 (Fachmodell S)

Teildatensatz S i (Fachmodell S)

Teildatensatz A i (Fachmodell A)

p o

Teildatensatz A i+1 (Fachmodell A)

ti+1

Abb. 5.1. Schematische Darstellung des entwickelten Kooperationsmodells und Einordnung der hierfür erforschten Methoden

Teildatensatzbildung und Modelltransformation (Mapping) Das Auswählen der benötigten Planungsdaten, also die Teildatensatzbildung (als Methode nachfolgend mit createSubset bezeichnet), und das Konvertieren der Planungsdaten in eine andere Darstellungsform, also die Modelltransformation (map), sind konzeptionell verwandt und stehen am Beginn eines Bearbeitungsschrittes. Ein Teildatensatz ist hierbei eine Untermenge des Gesamtmodells, die ohne Transformation gebildet werden kann. Beide Problemstellungen wurden getrennt voneinander betrachtet, um das Bilden von Teildatensätzen zu optimieren. Hierfür wurde das Generalised-Model-Subset-Definition Schema (GMSD) entwickelt (Weise et al. 2003; Scherer et al. 2006), das eine einfache Beschreibung der aufgabenspezifisch benötigten Produktdaten durch den Einsatz flexibel anpassbarer Filter, die unter Ausnutzung der Objektbeziehungen vordefiniert werden, erlaubt. Das Beschreiben der benötigten Planungsdaten kann dadurch auf die Auswahl weniger, aussagekräftiger Objekte, wie beispielsweise ein Stockwerkobjekt, und einen passenden Filter, der z.B. alle für die Tragwerksplanung relevanten Daten beschreibt, beschränkt werden. Diese zweistufige Beschreibung eines Teildatensatzes ist am Beispiel zweier Abfrageszenarien in der Abb. 5.2 veranschaulicht. Die Auswertung einer solchen Teildatensatzbeschreibung wird durch das Verfahren der Reintegration ergänzt (reintegrate), das den bearbeiteten Teildatensatz durch Umkehr der Teildatensatzbildung wieder zu einem Gesamtdatensatz ver-

200

Raimar J. Scherer, Matthias Weise, Peter Katranuschkov

vollständigt. Hierfür müssen die bei der Bearbeitung vorgenommenen Änderungen (userModify) bekannt sein.

betrachteter Planungsstand Mi

Gesamtdatensatz M i

ausgewählte Objektmenge

1.Auswahl Möglichkeit 1: Auswahl des vollständigen Planungsstandes

Gesamtdatensatz M i

Möglichkeit 2: Auswahl aussagekräftiger Objekte

2.“Filter“

gesuchter Teildatensatz Msi

Anwenden des Filters auf Mi , um nicht benötigte Daten zu entfernen

Anwenden des Filters auf einzelne Objekte, um zugehörige Daten (Objekte) aufzusammeln Stockwerkobjekt EG

Abb. 5.2. GMSD Prinzip der anpassbaren Filter durch die 2-stufige Beschreibung eines Teildatensatzes

Für die datenmodellunabhängige Modelltransformation zwischen zwei EXPRESSbasierten Produktdatenmodellen wurde eine deklarative Mappingspezifikationssprache entwickelt, die Context-Independent-Schema-Mapping-Language (CSML, Katranuschkov 2001). Der Vorteil von CSML ist die Nutzung von Mappingmustern, die eine schnelle und einfache Erstellung der Mappingspezifikation (mappingDef) ermöglicht. Zur Unterstützung bi-direktionaler Modelltransformationen werden in CSML beide Mappingrichtungen getrennt beschrieben. Datenmodellebene

M

S

mappingDef(M,S)

mappingDef(S,M)

M

Instanzebene

Mi

map(Mi, mappingDef(M,S))

Si

Si+1

map(Si+1, mappingDef(S,M))

Mi+1

Planungsänderung userModify(Si)

Abb. 5.3. Modelltransformation auf der Basis der Mapping-Spezifikationsprache CSML

Die Abb. 5.3 verdeutlicht das Prinzip der Modelltransformation. Der auf dem Quelldatenmodell M basierende Datensatz Mi wird auf der Basis der CSMLSpezifikation (als mappingDef(M,S) gekennzeichnet) in den Datensatz Si des Zieldatenmodells S überführt und nach entsprechender Bearbeitung durch den zuständigen Planer zurück in einen neuen, wieder auf M basierenden Datensatz Mi+1 transformiert. Da der Informationsgehalt des überführten Datensatzes in der Regel eine Teilmenge des Ausgangsdatensatzes ist, ist die Modelltransformation zusätz-

Ein Kooperationsmodell für die Kontrolle divergierender Planungszustände

201

lich mit dem Teildatensatzverfahren zu kombinieren. Dadurch können die sonst üblichen Informationsverluste bei einer Rücktransformation von S nach M vermieden werden. Modellvergleich (Matching) Das Erkennen von Änderungen (match) ist die Voraussetzung für das Aktualisieren eines Gesamtdatensatzes (Reintegration geänderter Teildatensätze, reintegrate) sowie das Zusammenführen parallel bearbeiteter Datensätze. Dieser Vorgang ist in Abb. 5.4 dargestellt. reintegrate

Mi

create Subset

Msi

user Modify

Msi+1 ǻMsi+1,i

Mi+1

match

Abb. 5.4. Modellvergleich und Reintegration auf der Basis von Teildatensätzen

Der Teildatensatz Msi wird in einem CAD-Programm bearbeitet und als modifizierter Datensatz Msi+1 der Datenverwaltung übergeben. Die dabei vorgenommenen Modifikationen sind der Datenverwaltung nicht bekannt und müssen aus den vorliegenden Datensätzen nachträglich ermittelt werden. Der Modellvergleich ermittelt die Änderungen zwischen zwei Planungsständen. Es wurde ein datenmodellunabhängiger Vergleichsalgorithmus erforscht, der durch das Auswerten der Objektbeziehungen selbst das Fehlen von Objektschlüsseln kompensieren kann. Hierfür wurde ein iteratives Verfahren entwickelt, das ausgehend von bereits identifizierten Objektpaaren2 über die Bewertung der Referenzen schrittweise zu weiteren Objektpaaren gelangt. Die heuristische Zuordnung der Objekte schränkt hierbei die Komplexität der Problemstellung deutlich ein und ermöglicht ein schnelles Vergleichsverfahren bei einer gleichzeitig hohen Erkennungsrate. Die dabei auftretende Unsicherheit kann durch das Konzept der Trefferwahrscheinlichkeit, die das Zustandekommen des Objektpaares beschreibt, individuell begrenzt werden. Als Ergebnis liegen die Datenänderungen zwischen den Produktdatenständen als Delta-Werte vor (Weise et al. 2003).

2

Ein Objektpaar besteht aus einem alten und einem neuen Objekt und kann beispielsweise über den invarianten Objektschlüssel gebildet werden.

202

Raimar J. Scherer, Matthias Weise, Peter Katranuschkov

Modellzusammenführung (Merging) Die parallel veränderten Datensätze müssen zu einem Planungsstand zusammengeführt werden (merge). Ziel ist ein aktueller Datensatz, der die Konsistenzanforderungen der konkreten Planungssituation erfüllt. Die Abb. 5.5 verdeutlicht, dass bei einem solchen Abstimmungsprozess, der hier als VorschlagZustimmungszyklus verstanden wird, nicht nur die unmittelbar betroffenen Planer S und A beteiligt sind, sondern auch andere Planer, hier T, einbezogen werden müssen.

Mi-1

Mi+1

Mi

Mi+2

Mi+c

Planer A

Planer T

Darstellung der von den Planern T ( ) und S ( benutzten Daten

merge

)

Planer S

geänderte Daten fallen auch in die Verantwortung von Planer T

Abstimmung zwischen den Planern A, S und T

Abb. 5.5. Zusammenführen divergierender Planungsstände durch 1.) den Vorschlag eines neuen, gemeinsamen Planungsstandes Mi+c und 2.) die Zustimmung anderer Planer

Für das Zusammenführen parallel durchgeführter Änderungen wurde ein Vorgehen erforscht, das formale Konflikte auf der Grundlage der Datenstruktur erkennt und einen Vorschlag zur Erreichung eines gemeinsamen konfliktfreien Planungsstands anbietet. Durch den Umgang mit Änderungen bleibt dieser Vorgang für den Planer transparent und er kann jederzeit korrigierend eingreifen. Er erkennt sofort, welche Änderungen in den gemeinsamen Planungsstand übernommen und welche Änderungen auf Grund von Konflikten zurückgewiesen wurden. Entstandene Konflikte können dadurch gezielt durch die betroffenen Planer im Nachgang aufgelöst werden (Weise et al. 2005). Das Erkennen zusätzlich einzubeziehender Planer geschieht auf der Grundlage der verwendeten Teildatensätze, aus denen die Bedeutung einer Änderung für einen Planer individuell abgeschätzt werden kann.

Ein Kooperationsmodell für die Kontrolle divergierender Planungszustände

203

5.2.2 Kooperationsszenarien Die nachfolgend vorgestellten Anwendungsszenarien bilden die Grundlage zur Verifikation des Kooperationsmodells und der hierfür entwickelten Methoden. Prinzipiell kann die gemeinsame Datenhaltung in einem kooperativen Planungssystem auf der Basis von Modellharmonisierung, Modellverbund oder Modelltransformation erfolgen. Für die praktische Anwendung sind aber vor allem Mischformen interessant (Eastman 1999; Amor u. Faraj 2001; Turk 2001). Neben dem Modellierungsansatz sind die eingesetzten CAD-Programme für die Betrachtung von Anwendungsszenarien entscheidend. Wesentlich ist hier die Unterscheidung in integrierte und eigenständige CAD-Programme. Den Idealfall stellt die Integration der CAD-Programme in die Datenverwaltung dar, die in einer heterogenen Planungsumgebung aber nur schwer durchgängig durchsetzbar ist. Der Fokus unserer Untersuchungen liegt daher auf eigenständigen CADProgrammen, die auf Basis einer optimistischen Kooperationsstrategie in die Planungsumgebung eingebunden werden. In diesem Zusammenhang ergeben sich die folgenden drei Kooperationsszenarien, die mit den entwickelten Methoden unterstützt werden. Kooperationsszenario 1: Arbeiten mit heterogenen Datenmodellen Dieses Szenario bildet die komplexeste Projektumgebung ab, die bei der heutigen dynamischen Projektorganisation sehr oft vorkommen kann. Ausgangspunkt ist ein gemeinsamer Planungsstand Mi, der zum Zeitpunkt ti in einem konsistenten Zustand ist. Grundlage ist das gemeinsame Produktdatenmodell M, das wesentliche Informationen der kooperativen Planung aufnehmen kann. Der allgemeine Fall ist in Abb. 5.6 dargestellt. Er beinhaltet die folgenden Schritte: 1. die Auswahl des zu bearbeitenden Teildatensatzes aus Mi durch Msi = createSubset (Mi , subsetDef (Mi )) 2. die Modelltransformation des Teildatensatzes Msi vom Schema M in das Schema S durch Si = map (Msi , mappingDef (M, S)) 3. die unabhängige Bearbeitung von Si durch ein CAD-Programm, hier ausgedrückt durch Si+1 = userModify (Si , useApplication (A , Si ) 4. die Rücktransformation des bearbeiteten Teildatensatzes Si+1 vom Schema S in das Schema M, in Analogie zu (2) durch Msi+1 = map (Si+1, mappingDef (S, M)) 5. die Objektidentifizierung, den Vergleich sowie die Bewertung der gefundenen Änderungen durch Msi+1,i = match (Msi , Msi+1 ) 6. die Integration der Änderungen in den Gesamtdatensatz Mi+1 durch Mi+1 = reintegrate (Mi , Ms i+1,i ) und 7. das Zusammenführen divergierender Planungstände zu dem neuen gemeinsamen Planungsstand Mi+c durch Mi+c = merge (Mi+1 , Mi+2 , … , Mi+k ). Als Ergänzung ist die Nutzung des Planungsstandes Si-1 sinnvoll, wenn in dem Modell Si-1 Informationen enthalten sind, die nicht in das Produktdatenmodell M

204

Raimar J. Scherer, Matthias Weise, Peter Katranuschkov

abgebildet werden können. In diesem Fall können aus Si-1 wichtige Informationen zur Ergänzung von Si genutzt werden. Dafür sind die Methoden der Schritte 5 und 6 anzuwenden. reintegrate

ǻMsi+1,i

Mi match

createSubset

Msi

...

map

Si-1

Si

user Modify

Msi+1 map

Si+1

Mi+1 merge Mi+c

... Mi+k

Abb. 5.6. Kooperationsszenario mit Teildatensätzen und Modelltransformation

Kooperationsszenario 2: Arbeiten mit einem homogenem Datenmodell Ein praxisrelevanter Spezialfall ergibt sich durch die Anwendung eines standardisierten Produktdatenmodells M, das von einem CAD-Programm direkt verarbeitet werden kann. In der Abb. 5.7 ist das vereinfachte Szenario dargestellt. Der Schritt der Modelltransformation ist im jeweiligen CAD-Programm in Form einer Datenmodellschnittstelle z.B. für IFC 2x enthalten. Im Unterschied zum allgemeinen Fall ist für den Modellvergleich 5 eine modellabhängige Vorbehandlung (Preprocessing) des bearbeiteten Teildatensatzes sinnvoll, die aus einer normalisierenden Modelltransformation Msi+1’ = map (Msi+1 , mappingDef (M, M)) besteht, da Modellhomogenität nicht Datenhomogenität impliziert. reintegrate

ǻMsi+1,i'

Mi

match

createSubset

Msi

user Modify

Msi+1

map

Mi+1 merge ...

Msi+1'

Mi+c

Mi+k

Abb. 5.7. Kooperationsszenario mit Teildatensätzen und standardisiertem Modell

Die beiden vorgestellten Szenarien verwenden Teildatensätze, die in einer GMSD Teildatensatzanfrage formalisiert werden. Bei der Nutzung eigenständiger CADProgramme wird diese Aufgabe von separaten Clients übernommen, die die Interaktion mit dem Planungssystem übernehmen.

Ein Kooperationsmodell für die Kontrolle divergierender Planungszustände

205

Kooperationsszenario 3: Arbeiten mit dem Gesamtmodell Wesentlicher Unterschied im Vergleich zu den vorangegangenen Szenarien ist, dass im CAD-Programm mit dem Gesamtmodell gearbeitet wird und somit die Bildung und Reintegration der Teildatensätze entfällt (Abb. 5.8). In diesem Szenario wird auch der Fall berücksichtigt, dass das Zusammenführen divergierender Planungsstände, z.B. als erster Vorschlag, in einem unabhängigen Programm durchgeführt werden kann. Um die hierbei vorgenommenen Änderungen nachträglich erkennen und bewerten zu können, ergibt sich für den Modellvergleich der Sonderfall, dass ein neuer Planungsstand mit k alten Planungsständen verglichen werden muss. Insgesamt stellt dieses Szenario die höchsten Anforderungen an die verwendeten CAD-Programme, da das Modell vollständig implementiert und die zuvor betrachteten Funktionalitäten integriert sein müssen.

Mi

user Modify, k* (match 1:1)

Mi+1 ...

external merge, match k:1

Mi+c

Mi+k Abb. 5.8. Kooperationsszenario mit Gesamtdatensätzen und k:1 Vergleichen

5.2.3 Bezug zu anderen Forschungsarbeiten des Schwerpunktprogramms Die vorgestellten Methoden mit dem zugrunde liegenden Kooperationsmodell unterstützen die Verwaltung gemeinsamer Planungsdaten und liefern damit einen wichtigen Beitrag zur Realisierung vernetzt-kooperativer Planungsprozesse. Sie sind in eine übergeordnete Kooperationsumgebung einzubetten, um den Planungsablauf zu überwachen und die beteiligten Planer zu koordinieren (s. Teil II). Diese Problemstellungen werden innerhalb des Schwerpunktprogramms in verschiedenen Arbeitsgruppen thematisiert und ergänzen, wie in Abb. 5.9 gezeigt, die hier erforschten Methoden. Hierzu gehören vor allem die Koordination der Arbeitsabläufe und die Organisation des virtuellen, vernetzt-kooperativen Unternehmens. Neben diesen, der Produktdatenverwaltung übergeordneten Themen liefern Forschungsarbeiten im Bereich der verteilten Produktdatenmodelle (s. Einleitung im Kap. III.1) wichtige Beiträge zur Anwendung des vorgestellten Ansatzes. Dies betrifft einerseits die Problemstellung der Versionsverwaltung (s. Kap. III.2) und andererseits das Einbringen von zusätzlichem Fachwissen zur Bewertung der Datenkonsistenz (s. Kap. III.3 u. III.6). Beide Forschungsvorhaben besitzen daher eine hohe Bedeutung für den vorgestellten Ansatz und ergänzen die entwickelten Methoden.

206

Raimar J. Scherer, Matthias Weise, Peter Katranuschkov

Softwarearchitektur eines verteilten Systems (Methoden der Kommunikation und Informationsverteilung)

Planungsprozesse Planungsprozesseund und Nutzerverwaltung Nutzerverwaltung Methoden für die Verwaltung und den Umgang mit Produktdaten Dokumentation der Planungsschritte, Auswertung der Planungshistorie

Steuerung der entwickelten Methoden, Auswertung der Ergebnisse zur Optimierung der Planungsaktivitiäten

Kooperationsmodell Kooperationsmodell und undentwickelte entwickelteMethoden Methoden

Versionsverwaltung Versionsverwaltung

Qualitative Aufwertung der Methoden, Konsistenz der Planungsdaten

Wissensbasen Wissensbasen

Abb. 5.9. Bezug zu Forschungsarbeiten des Schwerpunktprogramms

5.3 Forschungsergebnisse Der vorgestellte Ansatz verallgemeinert die Problemstellung der Produktdatenverwaltung und stellt datenmodellunabhängige Methoden bereit, die auf der Modellbeschreibungssprache EXPRESS basieren (ISO 10303-11). Diese Methoden wurden mit der Programmiersprache JAVA™ prototypisch in einer Client-ServerUmgebung implementiert und an praxisnahen Beispielen getestet. Eine Validierung ist jedoch nur für konkrete Produktmodelle und Implementierungen sinnvoll, weil dadurch die Qualität der Ergebnisse beeinflusst wird. Die Grundlage der nachfolgend betrachteten Bewertung bildet daher ein konkretes Szenario, das sich an der Nutzung des international akzeptierten IFC-Modells orientiert und den Implementierungsempfehlungen der IAI3 folgt (Wix u. Liebich 2003). Bei diesen Empfehlungen werden Anwendungsfälle definiert (Steinmann 2005), mit denen die hier entwickelten Methoden verifiziert wurden. Es konnte hierbei gezeigt werden, wie technische Unzulänglichkeiten verfügbarer CAD-Implementierungen überwunden werden könnten. Das genutzte Szenario ist in Abb. 5.10 an einem Beispiel dargestellt. In diesem Beispiel wird der Rohbau des Erdgeschoßes mit dem CAD-Programm ArchiCAD der Firma Graphisoft bearbeitet. Der aus dem ursprünglichen Gesamtdatensatz M1 erzeugte Teildatensatz Ms1 entspricht demzufolge dem aufgabenrelevanten Informationsbedarf, der nicht nur fachliche und räumliche sondern auch programmspezifische Kriterien berücksichtigt. Auf diese Weise wird garantiert, dass dem nach3

Die IAI (International Alliance for Interoperability) ist eine international tätige Organisation, die die Industry Foundation Classes (IFC) entwickelt und als offenen Standard für den Datenaustausch im Bauwesen etabliert hat. Mitglieder der IAI sind Softwarehersteller, Forschungseinrichtungen und Anwender aus verschiedenen Ländern.

Ein Kooperationsmodell für die Kontrolle divergierender Planungszustände

207

folgenden Bearbeitungsschritt nur solche Daten übergeben werden, die von der eingesetzten Software auch verstanden werden. Die Transformation der Daten in das ArchiCAD-Format geschieht dagegen innerhalb des CADProgramms, das nach dem Bearbeitungsschritt die Daten auch wieder in das IFC-Format zurückkonvertiert. Aus dem dabei erzeugten, überarbeiteten Teildatensatz Ms2 sind anschließend die durchgeführten Änderungen zu bestimmen, um den Gesamtdatensatz M1 aktualisieren zu können. Dieser Schritt ist in der Praxis außerordentlich kritisch, der durch die Normalisierung der Daten, den heuristischen Modellvergleich und den als neue Version M2 dokumentierten, formal aktualisierten Gesamtdatensatz berücksichtigt wird. Mögliche Fehler, die nicht vollständig ausgeschlossen werden können, sind dadurch jederzeit korrigierbar.

1. Extrahieren der Rohbaudaten des EG

Ms2

CAD-Programm

M1

M2

4. Exportieren des geänderten EG

Ms1

6. Reintegration der Änderungen

2. Importieren und 3. Modifizieren

ǻMs2,1 5. Ermitteln der Änderungen durch Normalisierung und Vergleich von Ms1 und Ms2

Abb. 5.10. Bezug zu Forschungsarbeiten des Schwerpunktprogramms

5.3.1 Teildatensatzbildung und Modelltransformation Für das untersuchte IFC Szenario ist das Arbeiten mit einem homogenen Datenmodell relevant. Ein Schwerpunkt der Untersuchung ist daher das Bilden von Teildatensätzen, die durch eine normalisierende Modelltransformation4 ergänzt wird (s. Abb. 5.7). Mit Hilfe des entwickelten GMSD Schemas kann die Auswahl bestimmter Objekte mit einem vordefinierten Filter kombiniert werden. Ein solcher Filter wird für die Formalisierung fach- bzw. programmspezifischer Views verwendet. Zusätzlich wurde die Möglichkeit bewertet, die Filter durch die Auswahl von Objekten wie z.B. eines Stockwerkobjekts individuell anzupassen.

4

Hierbei handelt es sich um einen Spezialfall der Modelltransformation, bei der die Daten nicht in ein anderes Datenmodell sondern eine einheitliche Form überführt werden.

208

Raimar J. Scherer, Matthias Weise, Peter Katranuschkov

Vordefinierte Filter zur Beschreibung programmspezifischer Views Ein Teildatensatz ist bei fachübergreifenden Datenmodellen häufig sehr komplex und muss zusätzlich an die Fähigkeiten des verwendeten CAD-Programms angepasst werden. Durch die Vielzahl der Anwendungsfälle und nutzbaren CADProgramme entstehen zahlreiche Kombinationen, die durch Filter zu definieren und zu pflegen sind. Diese Anpassungsarbeiten sind jedoch unvermeidbar, um Informationsverluste zu verhindern. Für das Erstellen eines Filters ist neben der Formalisierbarkeit somit auch der Aufwand für die Definition und Pflege entscheidend. Dieser Aspekt wird einerseits durch das GMSD Schema über die Möglichkeit von Voreinstellungen5 und andererseits durch das in Abb. 5.11 dargestellte, hierfür beispielhaft entwickelte Werkzeug berücksichtigt.

1

Zugriff auf Zugriff auf ProduktmodellProduktmodelldefinition definition

2

Übersicht über Übersicht über die Hierarchie die Hierarchie der Filterdefinition der Filterdefinition

3

Festlegen der Festlegen der Filterdetails Filterdetails

Abb. 5.11. Programmunterstützung zur Definition komplexer, wiederverwendbarer Filter

Mit dem in Abb. 5.11 gezeigten Werkzeug kann auf der Grundlage eines EXPRESS basierten Produktmodells eine Filterdefinition sehr schnell und unter Einhaltung der hierfür gültigen Konsistenzbedingungen zusammengestellt werden. Die Definition eines Filters wird zusätzlich durch das Konzept der Subviews erleichtert, die ausgehend von aussagekräftigen Objekten eine strukturierte, in unterschiedlichen Detailebenen beschreib- und wiederverwendbare Formalisierung erlauben. Es hat sich gezeigt, dass auf dieser Grundlage eine Filterdefinition vergleichsweise einfach zu warten und mit anderen Personen zu kommunizieren ist. Ein wesentlicher Teil der Modellimplementierung kann auf diese Weise vereinfacht werden. Neben dem Aspekt der Benutzbarkeit ist die Beschreibbarkeit der gewünschten Teildatensätze entscheidend. Die dafür bereitgestellte Funktiona5

Voreinstellungen reduzieren die Anzahl der notwendigen Anweisungen, indem nur die davon abweichenden Ausnahmen definiert werden müssen.

Ein Kooperationsmodell für die Kontrolle divergierender Planungszustände

209

lität beruht auf einer klassenbezogenen Unterscheidung, die über das Konzept der Subviews zusätzlich eine pfadabhängige, d.h. auf Referenzierung basierende Differenzierung erlaubt. Diese miteinander kombinierbaren Kriterien haben sich in den meisten Fällen als ausreichend erwiesen, um fach- bzw. programmspezifische Teildatensätze zu beschreiben. Ein Beispiel der pfadabhängigen Differenzierung ist in Abb. 5.12 gezeigt. Obwohl die Geometriebeschreibung für Stützen und Räume über gleiche Klassen realisiert ist, wird in dem gezeigten Beispiel nur die Geometrie der Stützen benötigt. Herausfiltern der Objekte b,c und d (Geometrie der Objekte vom Typ IfcSpace) a :IfcSpace … Representation …

e :IfcColumn … Representation …

b :IfcProductDefinitionShape c :IfcShapeRepresentation

Die Objekte b und f sind vom gleichen Typ, werden jedoch über die Referenzierung mit den Objekten a bzw. e anders bewertet.

d :IfcBoundingBox

f :IfcProductDefinitionShape g :IfcShapeRepresentation h :IfcBoundingBox

gesuchter Teildatensatz bestehend aus den Objekten a, e, f, g und h (Objekte des Typs IfcSpace ohne Geometrie und Objekte des Typs IfcColumn mit Geometrie)

Abb. 5.12. Beispiel, das die Kombination der klassenspezifischen Unterscheidung mit der Referenzierung erfordert

Die Grenzen der vordefinierbaren Filter werden erreicht, wenn eine Unterscheidung auf der Ebene der Attributbelegung erforderlich ist. So ist das Herausfiltern bestimmter Schlüssel-Werte-Paare nicht über die Filterdefinition sondern nur in Kombination mit der Objektauswahl möglich. Gleiches gilt für die Differenzierung über das Konzept der Subviews, die nur für direkt referenzierte Objekte möglich ist. Eine solche Differenzierung ist nicht vorgesehen, da ausgehend von aussagekräftigen Objekten die zugehörigen Daten in der Regel über das Verfolgen von Referenzen erreichbar sind. Ein Problem entsteht folglich dann, wenn ein auszuwählendes Objekt nicht über eine Referenz eines ausgewählten Objektes erreichbar ist. Dieser Fall wurde in den untersuchten Beispielen für die Beschreibung der Materialeigenschaften relevant. Ansonsten waren zugehörige Informationen zumindest über inverse Beziehungen erreichbar. Trotz der vorhandenen Einschränkungen, die nur wenige Spezialfälle betreffen, haben sich die vordefinierbaren Filter als praxistauglich erwiesen. Für die vermissten Auswahlkriterien sind Erweiterungen abzuwägen, um in die vordefinierbaren Filter eine größere Funktionalität integrieren zu können.

210

Raimar J. Scherer, Matthias Weise, Peter Katranuschkov

Kombination programmspezifischer Filter mit der Auswahl von Objekten Zusätzlich zu einer Filterdefinition kann die attributbasierte Auswahl von Objekten notwendig werden. Eine Filterdefinition soll dabei möglichst effizient mit der Auswahl von Objekten kombinierbar sein. Um den gewünschten Teildatensatz auf diese Weise zu beschreiben, sind Konsistenzbedingungen zwischen der Filterdefinition und der Objektauswahl einzuhalten. Für die Auswahl eines Stockwerks ist es beispielsweise notwendig, das gesuchte Stockwerkobjekt zu benennen. In der vorliegenden Version des GMSD Schemas sind solche, zusätzlich einschränkenden Konsistenzbedingungen nicht formalisierbar, unter anderem auch deshalb, um die Beschreibung einfach zu halten. Ein weiterer Grund ist auf die notwendige Umsetzung einer nutzerfreundlichen Abfrage zurückzuführen, die auf das Produktmodell und die gewünschte Abfrage angepasst werden muss. In der hierfür erforderlichen Implementierung sind die einzuhaltenden Konsistenzbedingungen in der Regel integriert. Die Untersuchungen haben insgesamt bestätigt, dass die in dem GMSD Schema realisierte Kombination zwischen einem vordefinierbaren Filter und der Auswahl von Objekten sinnvoll und effizient ist. Dadurch kann das Beschreiben von Teildatensätzen bei einer gleichzeitig sehr hohen Flexibilität wesentlich vereinfacht werden. Normalisierende Transformation In den untersuchten Beispielen ist vor dem Modellvergleich eine Normalisierung des überarbeiteten Datensatzes unerlässlich. Dadurch werden Besonderheiten der CAD-Programme erfasst, die andernfalls zu schlechteren Vergleichsergebnissen6 und unter Umständen zu fehlerhaft aktualisierten Gesamtdatensätzen führen würden. Die Normalisierung stellt jedoch einen Sonderfall der Modelltransformation dar, die nicht den Übergang zwischen verschiedenen Produktmodellen sondern die Homogenisierung der Daten innerhalb eines Modells verfolgt. Sie ist dadurch verstärkt durch funktionale Abhängigkeiten zu beschreiben, die auf der Grundlage der vorgeschlagenen Mappingmuster über ergänzende Prozeduren erfasst werden müssen. Der besondere Vorteil von CSML liegt in der Strukturierung der Mappingproblematik, die das Erstellen und Einordnen der erforderlichen prozeduralen Transformationsregeln erleichtert. In den untersuchten Beispielen war das Angleichen der Datensätze vor allem für die Korrektur der Bezugskoordinatensysteme und global verwendeter Maßeinheiten notwendig. Durch ein Verändern solcher Bezugsgrößen werden bei der Aktualisierung des Gesamtdatensatzes implizit auch andere, nicht im bearbeiteten Teildatensatz enthaltene Daten verändert. Dies würde im weiteren Verlauf zu unbeabsichtigten Inkonsistenzen und somit zu einem ungültigen Planungsstand füh6

In diesem Fall werden einerseits inhaltlich unbedeutende Änderungen erkannt. Andererseits würde die Qualität des Vergleichsergebnisses durch eine höhere Anzahl veränderter Daten leiden, da sie die Zuordnung der (nicht eindeutig identifizierbaren) Objekte erschwert.

Ein Kooperationsmodell für die Kontrolle divergierender Planungszustände

211

ren. Die hierfür erforderlichen Transformationen sind funktional zu beschreiben, z.B. sind Längeneinheiten bei Umwandlung von [m] auf [cm] durch Multiplikation mit 100 zu bilden, und werden nur unter bestimmten Voraussetzungen angewendet, beispielsweise bei Angabe der Längen in [m] statt der zuvor verwendeten [cm]. In diesen Beispielen sind nur geringe strukturelle Unterschiede zu überwinden, so dass die Transformationsbeschreibung auf vergleichsweise einfache Mappingmuster zurückgeführt werden kann. Wesentlich komplexere strukturelle Änderungen sind dagegen notwendig, wenn die vollständige Normalisierung gewünscht ist. Ein sehr hoher Aufwand ist beispielsweise dann erforderlich, wenn eine normalisierte Darstellung der Geometrie erreicht werden muss. Es hat sich jedoch gezeigt, dass der Gesamtaufwand der Normalisierung sehr gut auf ein individuell handhabbares Maß beschränkt werden kann, weil nur wenige, wirklich kritische Normalisierungen7 durchzuführen sind. Insgesamt stellt das Erkennen der erforderlichen Normalisierungsparameter, z.B. ein zu verwendendes Bezugskoordinatensystem, die größte Schwierigkeit dar, die in Vorgriff auf den Modellvergleich auch das Identifizieren bzw. die Zuordnung maßgebender Objekte erfordert. 5.3.2 Modellvergleich Das besondere Problem des Modellvergleichs stellt das Erkennen von Objektpaaren zwischen den zu vergleichenden Datensätzen dar. Ein Objektpaar stellt demzufolge die Verbindung zwischen einem alten und einem neuen Objekt her. Ursache ist das häufige Fehlen von Objekt ID’s, das ein eindeutiges Identifizieren der Objekte verhindert. Erschwerend kommt hinzu, dass potenziell veränderte Objekte zuzuordnen sind und die hierfür auswertbaren Informationen entsprechend vage sind. Für die untersuchten IFC Datensätze war beispielsweise zu beobachten, dass der Anteil der eindeutig identifizierbaren Objekte bei praxisrelevanten Problemstellungen zwischen 5% und deutlich unter 1% liegt. Mit dem entwickelten generischen Vergleichsverfahren wird daher zunächst versucht, diesen Informationsverlust auszugleichen und somit zwischen den zu vergleichenden Modellversionen eine möglichst vollständige Zuordnung der zusammengehörigen Objekte zu erreichen. Ausgehend von identifizierbaren Objekten wird durch die Bewertung der Verknüpfungen das Identifizieren weiterer Objekte erreicht. Auf diese Weise kann ein Objekt mit einer gewissen Wahrscheinlichkeit, die über die Verknüpfungstiefe und die Verknüpfungsart abgeschätzt wird, identifiziert werden. Die Identifikation zugehöriger Objekte kann aber auch zu Mehrdeutigkeiten führen, die in dem vorgestellten Vergleichsverfahren durch das Bewerten des Objektzustandes aufgelöst werden. Der Umfang und die Art der Änderungen haben demzufolge Einfluss auf das Vergleichsergebnis. Dieser Einfluss wurde durch die Untersuchung unterschiedlich stark veränderter Datensätze abgeschätzt. Ein kritisches Maß ist hierbei die Anzahl der Änderungen, die sich auf die Bewertung ei7

Kritisch sind solche Änderungen, die beim Aktualisieren des Gesamtdatensatzes zu ungewollten Inkonsistenzen führen.

212

Raimar J. Scherer, Matthias Weise, Peter Katranuschkov

ner Verknüpfung und somit die Zuordnung anderer Objekte auswirken. Hieraus wird deutlich, dass der Anteil der eindeutig identifizierbaren Objekte eine wichtige Bezugsgröße ist. Vergleich geringfügig veränderter Datensätze Ein geringfügig veränderter Datensatz bietet die besten Voraussetzungen, um ein gutes Vergleichsergebnis zu erzielen. Mit diesem Szenario kann überprüft werden, welcher Anteil der Objekte korrekt zugeordnet werden kann, welche der heuristischen Zuordnungsregeln anzuwenden sind und wie empfindlich das Vergleichsergebnis auf gezielte Änderungen reagiert. Für die untersuchten Datensätze hat sich gezeigt, dass trotz des geringen Anteils eindeutig identifizierbarer Objekte eine zumeist vollständige und fehlerfreie Zuordnung der Objekte möglich ist. Um dieses Ergebnis zu erreichen, werden alle Formen der Zuordnungsregeln benötigt. Hierzu gehören Einfachreferenzen, Mehrfachreferenzen sowie die Auswertung nicht erreichbarer Objekte. Diese Zuordnungsregeln haben einen unterschiedlichen Anteil am Vergleichsergebnis. Entsprechend dem relativ geringen Anteil an Einfachreferenzen hat sich bestätigt, dass über diese Form der Zuordnung, die formal die höchste Zutreffenswahrscheinlichkeit besitzt, nur wenige Objekte erkannt werden können. Den höchsten Anteil am Vergleichsergebnis haben Mengenreferenzen, wobei die ungeordneten Mengenreferenzen gegenüber den geordneten Mengenreferenzen deutlich überwiegen. Für diese Form der Zuordnung ist die Bewertung des Objektzustandes notwendig. Hierbei hat sich gezeigt, dass eine Entscheidung häufig nur dann möglich ist, wenn auch die toleranzbehafteten Attribute (Gleitkommazahlen) in die Bewertung des Objektzustandes einfließen. Diese Art von Attributen ist für das Bilden der Prüfsumme kritisch, weil die zulässigen Toleranzen den Wert einer Prüfsumme nicht beeinflussen sollen. Die hierfür vorgenommene Rundung der Gleitkommazahlen hat sich bei den Untersuchungen als sinnvoll erwiesen. Ausgehend von identifizierbaren Objekten kann mit Hilfe der Einfach- und Mengenreferenzen die Mehrzahl der Objekte zugeordnet werden. Jedoch verbleibt mitunter ein Rest von Objekten, die nicht zugeordnet werden können. Neben neuen bzw. gelöschten Objekten gehören hierzu Objekte, die über Verknüpfungen nicht erreicht werden konnten. Für diesen Rest von Objekten muss im Gegensatz zu anderen Zuordnungsregeln eine relativ aufwendige Bewertung des Objektzustandes verfolgt werden, die nicht skalierbar und somit nur für eine begrenzte Anzahl von Objekten einsetzbar ist. Vergleich stark veränderter Datensätze In den untersuchten Datensätzen standen einem eindeutig identifizierbaren Objekt mitunter 175 nicht identifizierbare Objekte gegenüber. Um alle Objekte zuordnen zu können, waren bis zu 6 Verknüpfungen zu verfolgen (s. auch die Prinzipdarstellung in Abb. 5.13). Aus diesem Grund ist eine hohe Empfindlichkeit gegenüber Änderungen zu erwarten.

Ein Kooperationsmodell für die Kontrolle divergierender Planungszustände

213

In den Untersuchungen hat sich gezeigt, dass Änderungen nur unter bestimmten Voraussetzungen zu einer Störung der Objektzuordnung führen. Bei geringfügig veränderten Daten ist eine solche Störung relativ selten zu beobachten. Für stark veränderte Datensätze sind die Voraussetzungen für eine Störung der Objektzuordnung dagegen deutlich häufiger gegeben. Doch auch in diesem Fall hat sich gezeigt, dass eine Störung meist auf wenige Objekte begrenzt ist. Dieser Effekt ist eine Folge eindeutig identifizierbarer Objekte, die in dem IFC Modell zwar sporadisch aber dennoch vorhanden sind und eine gewisse Stabilisierung bewirken. Der Vergleichsalgorithmus arbeitet unter diesen Voraussetzungen auch bei relativ stark veränderten Datensätzen vergleichsweise robust und erzeugt ein brauchbares Vergleichsergebnis. Im Fall einer Störung ist insgesamt zu beobachten, dass deutlich häufiger keine als eine falsche Zuordnung der Objekte stattfindet. Für einen sehr stark veränderten Datensatz und eine geringe Anzahl identifizierbarer Objekte stößt der Vergleichsalgorithmus dennoch an Grenzen, weil unter diesen Voraussetzungen das Vergleichsergebnis durch einen hohen Anteil „neuer“ Objekte einen begrenzten Nutzwert hat. verbleibende Objekte, die ausgehend von den Objekten a und b über Verknüpfungen nicht erreicht werden können

von den Objekten a und b gemeinsam verwendete Objekte (shared objects)

Legende: identifizierbare Objekte nicht identifizierbare Objekte mit aufsteigender Verknüpfungstiefe zu einem identifizierbaren Objekt: a

Verknüpfungstiefe 1 b

Verknüpfungstiefe 2 Verknüpfungstiefe 3 Objekte, die durch das Objekt b gekapselt sind

Verknüpfungstiefe 4

Abb. 5.13. Beispiel für ein Objektnetz, das über gegenseitige Verknüpfungen entsteht

5.3.3 Modellzusammenführung Das Zusammenführen divergierender Planungsstände und die Reintegration geänderter Planungsdaten sind konzeptionell ähnlich. In beiden Fällen sind Änderungen auf einen anderen Datensatz zu übertragen. Die Qualität des erzeugten Datensatzes ist dabei abhängig von den dokumentierten Änderungen, die das Ergebnis der Nutzerinteraktionen (userModify), der Qualität der vom CAD-Programm exportierten Daten und schließlich des Modellvergleichs sind.

214

Raimar J. Scherer, Matthias Weise, Peter Katranuschkov

Reintegration Das hierfür entwickelte Verfahren garantiert, dass die Änderungen in einem Gesamtdatensatz formal integriert und die Konsistenzbedingungen der Datenstruktur eingehalten werden. Es ist jedoch nicht gewährleistet, dass die Informationen des ursprünglichen Gesamtdatensatzes (Mi, s. Abb. 5.7) vollständig in den neuen Gesamtdatensatz (Mi+1) übernommen werden können. Zusätzlich besteht die Gefahr, dass die vorgenommenen Änderungen den Gesamtdatensatz implizit verändern und dadurch einen ungewünschten, vom Planer in dieser Form nicht erwarteten Planungsstand erzeugen. Während Inkonsistenzen auf der Ebene der Datenstruktur vergleichsweise einfach erkannt und nach vordefinierten Regeln aufgelöst werden können, ist die Bewertung der fachlichen Konsistenz für ein generisches Verfahren nicht ohne modellspezifisches Wissen möglich. Ein Teil dieses Wissens wird in dem betrachteten Kooperationsszenario durch die normalisierende Modelltransformation bereitgestellt, wodurch unverträgliche Änderungen vermieden werden können. Die Gefahr fehlerhafter Vergleichsergebnisse soll schließlich mit Unterstützung des Planers durch das Bewerten der vom Vergleichsalgorithmus ermittelten Änderungen reduziert werden. Wurden ermittelte Änderungen als falsch erkannt, so müssen diese Änderungen vor dem Schritt der Reintegration korrigiert werden. Die Gefahr unbeabsichtigter, impliziter Veränderungen kann durch die Korrektur des Vergleichsergebnisses nicht vollständig ausgeschlossen werden. In den Untersuchungen war dieser Fall für Objekte des Typs IfcOwnerHistory zu beobachten, die beim Schreiben eines IFC-Datensatzes entgegen dem Ziel der Änderungsdokumentation meist vollständig, d.h. auch für unveränderte Objekte von den CAD-Programmen ersetzt wurden. Der Vergleichsalgorithmus erkennt diese Objekte als geändert und erzeugt für den betrachten Teildatensatz ein plausibles Ergebnis. Aus diesem Vergleichsergebnis entsteht beim Erzeugen des Gesamtdatensatzes jedoch ein Konflikt, wenn mit diesem Objekt die Entstehungsgeschichte auch für andere, nicht im Teildatensatz enthaltene Objekte beschrieben wird. In diesem Fall wird die Entstehungsgeschichte unbeabsichtigt auf unveränderte Objekte übertragen. Solche Fälle können durch das vorgeschlagene generische Verfahren nicht eindeutig erkannt sondern bestenfalls über die Art der gemeinsamen Nutzung abgeschätzt werden. Ein automatisiertes Verfahren zum Auflösen entdeckter Konflikte ist in dem vorgeschlagenen Verfahren auf das Einhalten gültiger Referenzen beschränkt. Es wird demzufolge darauf verzichtet, zulässige Wertebereiche, auszuschließende Wertkombinationen oder die formulierte Vollständigkeit eines Objektes zu erzwingen. Hierdurch können zusätzliche Inkonsistenzen entstehen, die nur mit fachspezifischen Wissen aufgelöst werden können. Vereinfacht wird das Problem durch die Tatsache, dass nur solche Verträglichkeitsbedingungen zu prüfen sind, die die Beziehungen zwischen veränderten und unveränderten Planungsdaten einschränken. Insgesamt ist für den Schritt der Reintegration festzustellen, dass ein konsistenter Planungsstand nur unter idealen Bedingungen erzeugt werden kann. Voraussetzungen hierbei sind, dass der Entwurfsschritt selbst nicht in Widerspruch zu den restlichen Planungsdaten steht, der überarbeitete Datensatz durch

Ein Kooperationsmodell für die Kontrolle divergierender Planungszustände

215

den Schritt der Normalisierung erfolgreich an den ursprünglichen Datensatz angepasst wurde und schließlich die erzeugten Änderungen durch den Vergleichsalgorithmus richtig erkannt wurden. Diese Voraussetzungen können nur durch das Einbeziehen der Planer garantiert werden. Zusammenführen Im Unterschied zur Reintegration, bei der die vorgenommenen Änderungen gegenüber einem alten Planungsstand bewertet und vollständig übernommen werden, werden beim Zusammenführen zwei Änderungsmengen betrachtet. Ausgehend von einer der beiden Änderungsmengen8 werden nur solche Änderungen der anderen Änderungsmenge übernommen, die nicht zu Inkonsistenzen innerhalb der Datenstruktur führen. Es wird somit ein neuer Planungsstand erzeugt, der durch die Planer im Nachgang zu bewerten ist. Sind in den beiden Änderungsmengen ausschließlich die vom jeweiligen Planer beabsichtigten Änderungen enthalten, so sind die Probleme des Zusammenführens auf fachliche, durch die Planer entweder bewusst oder durch das parallele Arbeiten unbewusst herbeigeführte Widersprüche begrenzt. Das Zurückweisen von Änderungen, das zum Einhalten der Konsistenzbedingungen notwendig sein kann, kann selbst zu Widersprüchen führen. In diesem Fall entstehen Abhängigkeiten, die das Zurückweisen weiterer Änderungen erfordern. Durch diese Abhängigkeiten entstehen logisch zusammengehörige Änderungen, die entweder vollständig oder gar nicht übernommen werden. Das Ermitteln voneinander abhängiger Änderungen ist in dem vorgeschlagenen formalen Verfahren auf die Bewertung der gegenseitigen Referenzierung beschränkt und erfüllt damit die Mindestanforderungen an einen neuen Planungsstand. Es zeigt sich, dass ein auf diese Weise entstandener Planungsstand in jedem Fall durch die Planer auf fachliche Widersprüche überprüft und ggf. korrigiert werden muss. Ein fachlich sinnvoll zusammengeführter Planungsstand, der ohne Überprüfung an die anderen Planer als Vorschlag geschickt werden kann, kann mit den berücksichtigten Konsistenzbedingungen folglich nur unter idealen Bedingungen erreicht werden. Der besondere Vorteil des Verfahrens ergibt sich durch die für das Überprüfen des zusammengeführten Planungsstandes bereitgestellten Informationen, die auf dieser Ebene zwischen sicheren Konflikten, also die nicht übernehmbaren Änderungen inklusive ihrer Abhängigkeiten, sowie den als konfliktfrei eingeschätzten Änderungen unterscheidet. Die Zustimmung zu einem zusammengeführten Planungsstand wird auf dieser Grundlage nicht unerheblich unterstützt. Es ist festzustellen, dass das Zusammenführen durch das Einbringen von zusätzlichem Fachwissen weiter verbessert werden kann. Ein von uns näher untersuchter Ansatz ist das Einbeziehen der zurückliegend verwendeten Teilmengen, wodurch das Konfliktpotenzial zu Planungsleistungen anderer Planer auf der Basis von bereits vorhande-

8

Das vorgeschlagene Verfahren ist nur dann anwendbar, wenn die Änderungen bezüglich eines gemeinsamen Planungsstandes vorliegen und die zusammenzuführenden Datensätze im Sinne der jeweiligen Planer konsistent sind.

216

Raimar J. Scherer, Matthias Weise, Peter Katranuschkov

nem Wissens, also ohne zusätzlichem Formalisierungsaufwand abgeschätzt und in den Abstimmungsprozess einbezogen werden kann.

5.4 Schlussfolgerungen Für eine abschließende Einschätzung der Projektergebnisse wird zwischen den unmittelbar nutzbaren Methoden und dem Potenzial bzw. den Erweiterungsmöglichkeiten unterschieden. 5.4.1 Bewertung des Lösungsansatzes Mit dem Kooperationsmodell wurde ein allgemein gültiger Ansatz für die Verwaltung objektorientierter Produktdaten vorgestellt und die hierfür benötigten Funktionalitäten beschrieben. Die Grundlage des vorgestellten Ansatzes bildet das unabhängige, parallele Arbeiten mit individuell benötigten Teildatensätzen. Eine wesentliche Randbedingung ist die Tatsache, dass auf Grund der Problemstellung keine vollständige Integration der Planungsdaten und somit kein absolut fehlerfreies Verfahren garantiert werden kann. Diese Unsicherheit lässt sich nicht vermeiden und wird in dem vorgestellten Ansatz durch die Dokumentation der Teilschritte berücksichtigt. Die Änderungen der Planungsdaten lassen sich dadurch nachträglich bewerten und jederzeit korrigieren. Gleichzeitig wurden datenmodellunabhängige Methoden erforscht, die die hierbei notwendigen Teilschritte unterstützen. Auf diese Weise wird die Abhängigkeit von äußeren, nicht unmittelbar beeinflussbaren Faktoren deutlich reduziert und die Verwaltung gemeinsamer Produktdaten erleichtert. Bei den erforschten Methoden wurde auf zusätzliches Fachwissen zur Bewältigung der Datenintegration zunächst verzichtet. Sie sind dadurch universell einsetzbar. Darauf aufsetzende fachspezifische Erweiterungen sind unverzichtbar, um beispielsweise die normalisierende Modelltransformation und modellspezifische Benutzerschnittstellen zu realisieren. Diese Erweiterungen ergänzen das entwickelte Verfahren und können die Ergebnisse gezielt verbessern. Der nachträgliche Korrekturaufwand und die Qualität der gemeinsamen Planungsdaten können dadurch schrittweise und nach eigenen Prämissen verbessert werden. Die Untersuchungen für das IFC Modell haben die erreichbaren Vorteile des Ansatzes und der entwickelten Methoden gezeigt und den gewählten Ansatz bestätigt. Der Umgang mit Teildatensätzen, das Ermitteln der durchgeführten Änderungen sowie die Vorschläge für das Aktualisieren und Zusammenführen von Planungsständen sind für das Arbeiten mit einem gemeinsamen Produktmodell eine große Unterstützung. Der notwendige Korrekturaufwand ist für praktische Problemstellungen jedoch immer noch sehr hoch, kann aber durch fachspezifische Anpassungen deutlich reduziert werden. Eine solche Erweiterung wurde mit der Formalisierung einer normalisierenden Modelltransformation untersucht, um die Divergenz zwischen Inhalt und Struktur der Planungsdaten zu reduzieren und das

Ein Kooperationsmodell für die Kontrolle divergierender Planungszustände

217

Aktualisieren eines Planungsstandes zu ermöglichen. Auf dieser Grundlage lassen sich minimale Anforderungen an eine gemeinsame Datenbasis realisieren. Der wesentliche Vorteil des vorgestellten Ansatzes und der zugehörigen Methoden ist die Bereitstellung eines universell einsetzbaren Verfahrens, das an das verwendete Fachmodell und die benötigten Anforderungen individuell angepasst werden kann. Der hierfür erforderliche Aufwand wird dabei deutlich reduziert. 5.4.2 Ausblick und Verwertungsmöglichkeiten Der vorgestellte, datenmodellunabhängige Ansatz liefert in vielen Fällen bereits sehr gut Ergebnisse. Dennoch sind eine Reihe von Verbesserungen notwendig, um die Anforderungen der Praxis zu erfüllen. Hierbei sind in erster Linie eine gleichbleibend hohe Qualität bei nur wenigen Nutzerinteraktionen gefordert. Zu den notwendigen Verbesserungen gehören vor allem die Konsistenz der Planungsdaten, problemspezifische Benutzerschnittstellen, Programme zur Interaktion mit der Datenverwaltung, beispielsweise zur Anzeige der ermittelten Änderungen, und schließlich die Integration der Methoden in eine Gesamtarchitektur für verteiltkooperatives Arbeiten. Dies betrifft auch die Harmonisierung mit der Prozessplanung, die noch ein sehr hohes Potenzial für die Verbesserung vernetztkooperativer Planungsprozesse besitzt. Eine solche Integration kann durch die weitere Modularisierung der entwickelten Methoden sowie standardisierte Schnittstellen und Abläufe erreicht werden. Der hier vorgestellte datenmodellunabhängige Ansatz stößt bei den Anforderungen der Praxis schnell an seine Grenzen, die nur durch modellspezifische Anpassungen überwunden werden können. Hierfür reichen mitunter geringfügige Erweiterungen, die zur gewünschten Stabilität der Ergebnisse beitragen. Das Einbringen von zusätzlichem, modellspezifischen Fachwissen stellt demzufolge eine notwendige, mit sehr hohem Optimierungspotenzial verbundene Verbesserungsmöglichkeit der vorgestellten Methoden dar. Durch das steigende Interesse an der produktmodellbasierten Arbeitsweise, speziell dem BIM-Ansatz und dem IFC-Modell, und den gleichzeitig unzureichenden technischen Voraussetzungen zur Umsetzung einer durchgängigen Produktdatenverwaltung entsteht ein hoher Bedarf an unterstützenden, flexibel einsetzbaren Methoden zur Handhabung komplexer Produktmodelle. Der Umgang mit Teildatensätzen und das Erkennen geänderter Planungsdaten haben dabei die größte Bedeutung. Das vorgestellte Kooperationsmodell und die entwickelten Methoden liefern hierzu eine Grundlage, die mit vergleichsweise wenig Aufwand auf konkrete Szenarien angepasst werden kann. Hierfür ist eine fachspezifische Optimierung bzw. Ergänzung der generischen Methoden vorgesehen. Zusätzlich ist die Umsetzung der Methoden als Internet-fähige Dienste (Web-Services) geplant, die flexibel in bestehende Projektmanagementsysteme eingebunden werden können. Solche Dienste werden vor allem dadurch interessant, weil ihr Einsatz nicht ein vollständiges Datenintegrationskonzept erfordert und auch ohne eine durchgängig produktmodellbasierte Planung nutzbar ist. Das Vermarktungspotenzial ist daher insgesamt sehr hoch. Letztendlich ist der praktische Wert solcher Dienste aber

218

Raimar J. Scherer, Matthias Weise, Peter Katranuschkov

vom Erfolg standardisierter Produktmodelle wie IFC, CIS/2 und anderen abhängig, die das größte Risiko für die Akzeptanz der Methoden in der Praxis darstellen.

Literatur Amor R, Faraj I (2001) Misconceptions about Integrated Project Databases. IT-con, vol 6 Eastman CM (1999) Building Product Models: Computer Environments Supporting Design and Construction. CRC Press, Boca Raton, Florida ISO 10303-11 IS /Cor.1:1999/ Industrial Automation Systems and Integration – Product Data Representation and Exchange – Part 11: Description Methods: The EXPRESS Language Reference Manual. ISO, Geneva ISO 10303-21 IS /Cor.1:1996/: Industrial Automation Systems and Integration – Product Data Representation and Exchange – Part 21: Implementation Methods: Clear Text Encoding of the Exchange Structure. ISO, Geneva Katranuschkov P (2001) A Mapping Language for Concurrent Engineering Processes. Dissertation, TU Dresden Scherer RJ, Katranuschkov P (2004) Management of the Multi-Dimensional Project Information Space. In: Proc. CIB-W78 Workshop, Toronto Scherer RJ, Weise M, Katranuschkov P (2006) Adaptable Views supporting Long Transactions in Concurrent Engineering. In: Proc. ICCCBE-XI Conference, Montreal, Canada Steinmann R (2005) Web-site of IAI's ISG, the Implementer Support Group (http://www.bauwesen.fh-muenchen.de/iai/iai_isg/) Turk Z (2001) Phenomenological Foundations of Conceptual Product Modelling in AEC. In: Int. J. of AI in Engineering, no 15 Wagner U, Katranuschkov P, Scherer RJ (2001) A Generic Approach to the mapping Problems in Co-operative Design. In: Thoben K-D, Weber F, Pawar KS (eds) Proc. 7th Int. Conf. On Concurrent Enterprising (ICE), Bremen Wagner U, Katranuschkov P, Scherer RJ (2002) Ein Kooperationsmodell zur Lösung von Datenkonsistenzproblemen in der vernetzt-kooperativen Planung. VDI-Tagung, Bonn Weise M, Katranuschkov P, Scherer RJ (2003) Generalised Model Subset Definition Schema. In: Proc. CIB-W78 Conference – Information Technology for Construction, Auckland Weise M, Katranuschkov P, Scherer RJ (2004a) Generic Services for the Support of Evolving Building Model Data. In: Proc. ICCCBE-X Conference, Bauhaus-Universität, Weimar Weise M, Katranuschkov P, Scherer RJ (2004b) Managing Long Transactions in Model Server Based Collaboration. In: Proc. ECPPM 2004 Conference, Istanbul Weise M, Katranuschkov P, Scherer RJ (2005) Supporting State-based Transactions in Collaborative Product Modelling Environments. In: Proc. CIB-W78 Conference 2005, Dresden Wix J, Liebich T (2003) Industry Foundation Classes IFC 2x2. © International Alliance for Interoperability (http://www.iai-ev.de/spezifikation/IFC2x2/index.htm)

6 Vernetzt-kooperative Gebäudeplanung im Massivbau mit verteilten deklarativen Wissensinstanzen und Fuzzy-Methoden

Martina Schnellenbach-Held, Torben Pullmann Universität Duisburg-Essen, Institut für Massivbau {m.schnellenbach-held | torben.pullmann}@uni-due.de

Markus Hartmann Bernhardt & Mertens, Darmstadt [email protected]

6.1 Zusammenfassung Die gestiegenen Anforderungen an Planung und Ausführung von Bauprojekten erfordern für eine wirtschaftliche Projektabwicklung eine koordinierte Kommunikation sowie eine effiziente Informationsverarbeitung (Bretschneider 1998). Im Rahmen dieses Forschungsprojektes wurden Konzepte für vernetztkooperative Planungsprozesse auf der Grundlage wissensbasierter Modellierung erarbeitet und prototypisch implementiert. Das entwickelte Softwaremodell integriert weitreichende Aspekte der Mehrbenutzerfähigkeit, Datensicherheit, Modellintegrität und Anwendbarkeit auf sämtliche Gewerke des Bauwesens. Das Gebäude-Informations-Modell (Building-Information-Model – BIM) als zentrale, serverseitige Datenbasis (im Weiteren als Produktinstanz bezeichnet) dient zur Verwaltung der im Rahmen des Planungsprozesses erforderlichen Informationen. Dieses wird auf der Grundlage der Struktur eines eigens hierfür erarbeiteten Produktmodells (Product-Model – PM) generiert. Das PM beinhaltet neben rein statischen Produktdaten ebenso eine vollumfängliche Prozessmodellierung.

220

Martina Schnellenbach-Held, Torben Pullmann, Markus Hartmann

Die aus dem erarbeiteten Wissensmodell (Knowledge-Model – KM) instanziierten gewerkespezifischen Wissensinstanzen werden primär auf den verteilt angeordneten, lokalen Workspaces der Projektbeteiligten vorgehalten. Die Wissensrepräsentation für die verschiedenen am Planungsprozess beteiligten Domänen erfolgt in deklarativer Form. Hierdurch wird eine hohe Modularität des Gesamtsystems und somit eine starke Unabhängigkeit der Wissensinstanzen sowohl untereinander als auch von einem zentralen Inferenzmechanismus sichergestellt. Infolge der Aufteilung des Wissensmodells in einen öffentlich einsehbaren und einen privat geschützten Bereich wird die Wahrung von firmeninternem Ingenieurwissen und somit eine hohe Akzeptanz des Gesamtsystems gewährleistet. Im Rahmen des Forschungsprojektes wurden Konzepte für eine effiziente Steuerung und Regelung des Daten- und Informationsflusses für netzwerkoptimierte Benutzerinteraktionen sowie für erforderliche Mechanismen zur Erhaltung der Datenintegrität erarbeitet. Unter anderem werden aus Gründen der Reduktion des Kommunikationsaufwandes während der Auswertung die verteilt angeordneten, gewerkespezifischen Wissensinstanzen serverseitig repliziert. Mit Hilfe von Inferenzmechanismen wird die lückenlose Identifikation auch gewerkeübergreifender Konsequenzen von Planungsaktivitäten ermöglicht und somit die Konsistenz des Gesamtmodells sichergestellt. Aus diesem Grund werden sämtliche produkt- und prozessbasierte Daten serverseitig vorgehalten und verwaltet. Dadurch wird ermöglicht, dass die Konsequenzen von Planungsänderungen sowie die Einhaltung lokaler Sperren jederzeit für alle Beteiligten ersichtlich sind. Weiterhin bietet das PM die Modellierung von Abhängigkeiten zwischen Bauteilen, wodurch die Abbildung komplexer Netzstrukturen erfolgen kann. Dies ist beispielsweise für eine deterministische Abhängigkeitsverfolgung (z.B. Lüftungskanalnetz, Lastabtragung, o.ä.) erforderlich. Mit Hilfe einer Erklärungskomponente wird für den Anwender die lückenlose Rückverfolgung des Planungsprozesses dargestellt. Dies betrifft ebenso Berechnungen, die auf Wissensinstanzen fremder Gewerke basieren, sofern deren Informationen nicht explizit geschützt sind. Diese Nachvollziehbarkeit und somit Sicherung der Transparenz in der Planungshistorie eines Bauwerks ist ein grundlegender Vorteil des entwickelten Systems im Vergleich zu existierenden Softwaremodellen des Ingenieurwesens. Die Qualität komplexer Planungsentscheidungen wird in starkem Maße beeinflusst von Informationen über mögliche Konsequenzen im Verbund mit mehreren Gewerken. Eine deterministische Ermittlung dieser Auswirkungen wäre präzise, erfordert jedoch unter Umständen weitere Entscheidungen und erheblichen Rechenaufwand. Basierend auf dieser Erkenntnis wurden Verfahren evaluiert, die bei Planungsänderungen eine möglichst einfache, jedoch aussagekräftige und transparente Sensitivitätsanalyse zur Abschätzung von Konsequenzen aus Planungsänderungen ermöglichen. Hierfür wurden unter anderem logische Fuzzy-Modelle eingesetzt. Zur Evaluierung der erarbeiteten Konzepte wurden Wissensinstanzen beispielhaft für die Gewerke der Tragwerksplanung (Massivbau) und der Haustechnik (Raumlufttechnik) mit Hilfe einer prototypisch entwickelten Wissenserwerbskomponente erarbeitet. Für die Definition, Editierung, Visualisierung und Auswertung der Produktinstanz sowie zur Steuerung der Konzepte für die Kom-

Vernetzt-kooperative Gebäudeplanung im Massivbau

221

munikationsinfrastruktur wurde eine Softwareapplikation (Domain Augmented Environment for Intelligent Networked & Cooperative Design – DaVinci) implementiert. Die Vorteile des entwickelten Modells liegen in der beschleunigten Durchführung zeitintensiver und somit kostenverursachender Vorgänge durch eine effiziente Kommunikationsinfrastruktur, sowie in der vollständigen Erfassung von sowohl gewerkespezifischen, als auch gewerkeübergreifenden Konsequenzen einzelner Planungsaktivitäten innerhalb der verteilten heterogenen Planungsumgebung. Durch konsequenten Einsatz eines derartigen Systems können die Fehleranfälligkeit minimiert und Planungs- und Entscheidungsprozesse erheblich beschleunigt werden.

6.2 Arbeits- und Ergebnisbericht 6.2.1 Ausgangslage Bauherren und Investoren verlangen nicht nur immer kürzere bauliche Ausführungszeiten, sondern auch eine beschleunigte, größtenteils baubegleitende Planungsphase. Konsequenzen, welche sich aus Planungsänderungen ergeben, sollen hierbei von allen Planungsbeteiligten schnell, vollständig und korrekt erfasst und bearbeitet werden. Zur Kommunikation und Kooperation zwischen Bauherr, Projektsteuerer, Fachplanern und Baustelle stehen bereits internetbasierte ProjektmanagementSysteme zur Verfügung (Steiger 1998; Zimmermann 1999). Diese erfassen größtenteils die Abhängigkeiten bestimmter Teilprozesse untereinander. Die Vorgänge solcher auch als „Datenpool“ oder „Projektserver“ bezeichneten Systeme werden jedoch ausschließlich dokumentenbasiert durchgeführt (Behaneck 2002). Aufgrund dezentraler, dokumentenbasierter Datenhaltung liegen den Arbeiten der verschiedenen Projektbeteiligten gegebenenfalls differierende Planungszustände zugrunde. Diese konventionelle Vorgehensweise ist zeit- und somit auch kostenintensiv und führt schnell zu erheblichen Inkonsistenzen. Modellbasiertes Arbeiten sowie eine aktive Unterstützung des Planungsvorgangs im Sinne von Entscheidungsfindungen werden bislang nicht berücksichtigt (Sanders 2004; Miles 2005). Erste, durchgängig objektorientierte Ansätze für die Wissensrepräsentation wurden von Garrett und Hakim mit dem Object Oriented Model (OOM) erarbeitet (Garrett u. Hakim 1992). Hierauf aufbauend entwickelte Holéwik das Objektorientierte Wissensrepräsentationsmodell (OWM) (Holéwik 1996). In (Schnellenbach-Held et al. 1992; Albert 2002) wird das Objektorientierte FuzzyWissensrepräsentationsmodell (OFWM) vorgestellt, welches die Formalisierung von Entwurfs- und Bemessungswissen im Stahlbetonhochbau ermöglicht. Eine gemeinsame Bearbeitung von Planungsobjekten wird mit Hilfe kooperationsunterstützender Ansätze realisiert. In so genannten Blackboard-basierten Ansätzen (Nii 1986) dient eine gemeinsame Datenbasis dazu, Informationen und Wissen im Rahmen eines Planungsprozesses zu verwalten. Messner stellt in

222

Martina Schnellenbach-Held, Torben Pullmann, Markus Hartmann

(Messner et al. 1993) ein Blackboard-basiertes System für die Planung von Stahlbeton-Fertigteil-Bauwerken vor. Mit dem CMPS (Construction and Manufacturing Planning System) wird der Schwerpunkt auf ein ganzheitliches (Produkt-) Modell für die Fertigteilplanung – ohne Berücksichtigung von Wissenselementen – mit mehreren Projektbeteiligten realisiert. Petersen stellt in (Petersen 2002) ein verteiltes System zur fachspezifischen Optimierung des Energiehaushaltes baulicher Anlagen in der Planungsphase vor. Das von ihm entwickelte Programmsystem VAMOS (Verteilte Applikation zur Modellierung und Optimierung bauphysikalischer Systeme) verwendet für das Führen der bauphysikalischen Nachweise eine prozedurale Form der Wissensrepräsentation (Altenkrüger u. Büttner 1992). Das im Rahmen dieser Forschungsarbeit entwickelte Modell unterteilt sich ebenfalls in problemspezifische Teilmodelle. Es sollte ein Produktmodell erarbeitet werden, welches die Belange von Bauteilen unterschiedlicher Gewerke sowie insbesondere deren Konfliktbereiche (z.B. Wanddurchbrüche) berücksichtigt. Beispielhaft sollten in diesem Projekt die für die Gewerke der Tragwerksplanung (Bereich Stahlbetonbau) und Haustechnik (Bereich Raumlufttechnik) erforderlichen Produktinformationen erfasst werden. Gleichzeitig waren prozessbezogene Anforderungen der verteilten Planungsumgebung (Änderungsmodelle, Sperrmechanismen, Planungshistorie etc.) zu berücksichtigen. Auf dem zu entwickelnden Produktmodell sollten mit Hilfe von Elementen aus Wissensinstanzen gewerkeübergreifende Planungsprozesse ausgeführt werden, die den Fachplaner sowohl bei der Nachweisführung, als auch bei der Approximation von Konsequenzen aus Planungsmodifikationen unterstützen. Im Gegensatz zu vorangegangenen Arbeiten sollte das zu erarbeitende Wissensmodell Anforderungen, welche sich speziell im Rahmen einer verteilten Planungsumgebung (MehrbenutzerFähigkeit, öffentliche/private Wissensrepräsentation, prozessbasierende Nachweisführung etc.) ergeben, berücksichtigen. Für die Anwendung der zu entwickelnden Modelle sollten geeignete Softwareprototypen entwickelt werden. 6.2.2 Die Ergebnisse des Forschungsprojektes Im Rahmen dieses Forschungsprojektes wurde ein umfassendes Softwaremodell erarbeitet, welches sich in zwei grundlegend getrennte Datenmodelle, das Produktmodell (PM) und das Knowledge-Model (KM) unterteilt (s. Abb. 6.1). Das PM dient zur detaillierten Repräsentation von Bauwerksmodellen unter Berücksichtigung der Anforderungen unterschiedlicher Gewerke. Exemplarisch wurden Klassen zur Repräsentation detaillierter Informationen der Gewerke „Tragwerksplanung“ und „Raumlufttechnik“ generiert. Als Ergebnis der ersten Forschungsphase wurden die Grundlagen für die Formalisierung prozessbasierter Informationen zur Berücksichtigung der effizienten Kommunikation, der Mehrbenutzerfähigkeit, der unterschiedlichen Planungsstadien sowie der Planungshistorie geschaffen. Somit integriert das PM als Metamodell die Informationen eines klassischen Produktmodells mit einem Prozess-Daten-Modell. Eine Produktinstanz als Instanz des PM

Vernetzt-kooperative Gebäudeplanung im Massivbau

223

enthält sämtliche Informationen eines Bauwerks, die im Rahmen der Planungsphase und der gewerkeübergreifenden Bearbeitung zur Anwendung kommen. In Anlehnung an die Data Item Hierarchy von Garrett und Hakim (Garret u. Hakim 1992) sowie das Modell der Elemente der Wissensinstanz von Albert (Albert 2002) wurde das KM entwickelt. Im Gegensatz zu den vorangegangenen Arbeiten berücksichtigen die im KM erarbeiteten Klassen die Anforderungen für eine gewerkeübergreifende Nachweisführung auf der Grundlage unterschiedlicher Wissensinstanzen in einer verteilten Planungsumgebung. Das KM ermöglicht die allgemeine Formalisierung von Ingenieurwissen in Form von Formeln, Tabellen, Diagrammen und Regeln. Eine auf dem KM basierende Wissensinstanz kann gleichzeitig auf mehrere Produktinstanzen angewendet werden, daher ist die Ablage von projektspezifischem Wissen in Wissensinstanzen explizit ausgeschlossen. Die Elemente einer Wissensinstanz werden entsprechend dem PM hinsichtlich ihrer Anwendung strukturiert abgelegt. Wissensrepräsentationsmodell Produktmodellierung

Wissensmodellierung Wissensmodell Knowledge Model (KM)

Produktmodell (PM)

referenziert

referenziert

Applikation

generiert

ProduktInstanz

Wissensbank generiert

(PI)

DaVinci

Applikation KBDT

Inferenzkomponente verifiziert

Sensitivitätsanalyse Konsistenzanalyse

verwendet

DaVinci

Abb. 6.1. Struktur des erarbeiteten Wissensrepräsentationsmodells

Systemarchitektur in verteilter Umgebung Die in diesem Projekt erarbeitete Systemarchitektur erfordert softwaretechnisch eine umfassende Kommunikationsplattform. Als mögliche Systeme wurden Peerto-Peer-Systeme sowie Client-Server-Systeme untersucht. Folgende Randbedingungen wurden hierbei als notwendig erachtet:

x x x x x x

Ständige Verfügbarkeit des aktuellen Datenbestandes für alle Beteiligten Benutzerfreundliche Bearbeitung und Visualisierung Konsistenzsicherung Einhaltung eines Berechtigungskonzeptes Minimierung des Datenverkehrs Datensicherheit

224

Martina Schnellenbach-Held, Torben Pullmann, Markus Hartmann

Die Einhaltung vorgenannter Kriterien ist durch Peer-to-Peer-Topologien nicht oder nur bedingt sicherzustellen. Reine Client-Server-Systeme sind ebenfalls nicht in der Lage, sämtliche Kriterien zu erfüllen, da beispielsweise eine schnelle Visualisierung aufgrund des erforderlichen Kommunikationsaufwands kaum möglich wäre. Zur Sicherstellung einer größtmöglichen Flexibilität bei gleichzeitiger Konsistenzsicherung der Datenbestände hat sich eine hybride Client-ServerArchitektur als zweckmäßig herausgestellt (s. Abb. 6.2).

Wissensbank

Gewerk – A

Gewerk – B

Gewerk – X

(public Sector)

(public Sector)

(public Sector)

(private Sector)

(private Sector)

Wissensbank

Replikation

Wissensbank

Replikation

Replikation

Lokale Workspaces

(private Sector)

Kommunikationsplattform: Internet

(public Sector)

Produkt-Instanz (PI)

(private Sector)

Wissensbank Gewerk – B (public Sector) (private Sector)

Wissensbank Gewerk – X (public Sector) (private Sector)

Request & Response (Benutzereingaben)

Gewerk – A

Request & Response (Benutzereingaben)

Wissensbank Request & Response (Benutzereingaben)

Zentraler Projekt-Server

Zentrale Planungsapplikation (DaVinci) - Inferenzkomponente

Abb. 6.2. Systemarchitektur in verteilter Umgebung

Zur Verwaltung der im Rahmen des Planungsprozesses erforderlichen Informationen dient eine gemeinsame serverseitige Datenbasis (Projekt-Datenbank). Sämtliche BIM-Informationen werden dort kontinuierlich aktuell vorgehalten. Hierdurch wird sichergestellt, dass die Konsequenzen von Planungsänderungen jederzeit für alle Beteiligten ersichtlich sind und die Datenintegrität permanent gewährleistet ist. Sämtliche Vorgänge der Editierung erfolgen direkt auf der serverseitigen Projekt-Datenbank. Zusätzlich werden geometrische Informationen auf die lokalen Workspaces repliziert und dort visualisiert. Im Falle von Änderungen müssen somit lediglich sehr geringe Datenmengen zu den Clients übertragen werden. Aus Gründen der Konsistenzhaltung handelt es sich bei der Zugriffsklassifizierung auf die einzelnen PM-Instanzen um pessimistische Sperrverfahren (Schlichter 2000). Im Gegensatz zu den PM-Instanzen werden die KM-Instanzen – die gewerkespezifischen Wissensinstanzen – auf den lokalen Workspaces der Projektbeteiligten vorgehalten. Die Evaluierung des Inferenzprozesses mit einer adäquaten Testumgebung hat jedoch frühzeitig gezeigt, dass bei vollständiger Dezentralisierung der KM-Instanzen ein erheblicher Kommunikationsbedarf während der Auswertung resultiert. (Performance: ca. 1000 Objekte in 18.000 ms bei 100 Mbit/s

Vernetzt-kooperative Gebäudeplanung im Massivbau

225

mit linearem Anstieg). Zur Reduktion des Kommunikationsaufwandes im Rahmen von Inferenzprozessen wurde die Systemarchitektur um einen selektiven Replikationsmechanismus erweitert. Hierbei werden eventuelle Änderungen der lokalen Wissensinstanzen der Fachplaner bei Bedarf auf den Projektserver repliziert. Die replizierten Wissensinstanzen werden somit ausschließlich durch einen serverseitigen Inferenzprozess auf die zentrale Produktinstanz angewendet. zentraler Projektserver

lokale Workspaces PI Gewerk A

Gewerk B

Gewerk X

Änderungsszenarien (CS) - Ersteller Gewerk A Gewerk B Gewerk X

priv. CS (PCS) - Ersteller …. Gewerk A

Wissensbank

Request_PI

(1)

PI

PI

Response_PI

(2) PI

PI

PI Initialisation_CS

Derivation_PI

(3)

PI

PI_CS1_B Response_CS

(4) PI_CS2_A

Request_Release_CS1_B

(6) Response_Release_CS1_B Edit_CS1_B

(7) Edit_CS1_B Initialisation_PCS

(8) Response_PCS

PI_CS2_B_PCS1 _A

(9)

ᅛ

PI_CS2_B

Kommunikationsplattform: Internet

Response_CS1_B

PI_CS1_B

PI_CS2_A

Zentrale Planungsapplikation: Da Vinci

Request_CS1_B

(5)

PI_CS1_B

PI

PI_CSX_X

PI_CS1_B

PI_CS1_B

PI_CS1_B

Derivation_PI PI_CS1_B

Start_SI

ᅛ

PI_CS2_B

PI_CSX_X

PI_CS2_B_PCS1 _A

Analysis_SI

ᅛ

Results_SI

Project Management

PI_CS2_B

Consulting Information

(10)

Accaptance_SI

!

Start_PI

(11)

ᅛ

PI_CS2_B

ᅛ

PI_CS2_B

Analysis_PI

(13)

craft-specific KB‘s

PI_CS2_B Settlement_PI

Accaptance_PI

PI_CSX_X

ᅛ

Results_PI

Consulting

(12)

!

Information

PI_CS2_A

PI

PI

ᅛ

PI_CS2_B

!

PI_CS2_A

Takeover

!

PI_CSX_X

Abb. 6.3. Sequenzdiagramm einer verteilten Modellbearbeitung

Zum Zwecke der Bearbeitung können innerhalb der Produktinstanz so genannte Szenarien erzeugt werden. Ein Szenario soll hier verstanden werden als eine vollständige Kopie eines Gebäudemodells zu einem bestimmten Zeitpunkt. An einem Szenario können unterschiedliche Operationen vorgenommen werden, um diese

226

Martina Schnellenbach-Held, Torben Pullmann, Markus Hartmann

zu einem späteren Zeitpunkt in das Hauptmodell zu übernehmen oder auch zu verwerfen. Dieses Verfahren ermöglicht neben geschlossenen Bearbeitungseinheiten die Erprobung unsicherer Entwurfskonzepte und Veränderungen sowie die Evaluation von unterschiedlichen Planungsvarianten. Die grundlegende Funktionsweise des Modells in einer verteilten Planungsumgebung verdeutlicht das Sequenzdiagramm (Abb. 6.3). Als Ausgangspunkt dient eine abgestimmte Produktinstanz (PI) auf dem zentralen Projektserver. Zum Zwecke der Visualisierung werden nur die geometrischen Informationen eines jeweiligen Szenarios an die Clients übertragen (1 und 2). Nach Ableitung von Szenarien aus dem Hauptmodell (3 und 4) und Bearbeitung eines Szenarios durch Gewerk A (5) werden die Änderungen durch die anderen Fachplaner akzeptiert (6) und in deren Szenarien sowie in das Hauptmodell übernommen (7). Ebenso können Resultate von Sensitivitätsanalysen (9) und Inferenzprozessen (11) in betroffene Szenarien übergeben werden. Werden für die Nachweisführung gesonderte Vorgaben – so genannte Benutzereingaben – von einzelnen Fachplanern benötigt, so werden diese von der zentralen Planungsapplikation vor Beginn eines Inferenzprozesses direkt bei dem betreffenden Anwender angefragt (Request) (s. Abb. 6.4). Dieser bearbeitet die Anfrage und sendet nach Bearbeitung der Benutzereingabe das Ergebnis zur Ablage in der Produktinstanz zurück (Response). Ebenso werden zur Anzeige von Berechnungsergebnissen lediglich die zur Darstellung notwendigen Daten an die Clients übermittelt. zentraler Projektserver

lokale Workspaces Gewerk X

DaVinci Client

DaVinci Client

DaVinci Client

(1)

*

Request_Edit Benutzereingabe (ID-A_123) in PI_CS1_B

(2) (3) (4)

Response_Edit

Änderungsszenarien (CS)

PI

PI_CS2_A

Da Vinci - Server

Gewerk B

Kommunikationsplattform: Internet

Gewerk A

PI_CS1_B

PI_CSX_X

Wissensbanken (KB) KB_A

KB_B

Demand_ID

Demand_Benutzereingabe

(5) Update

Update

Abb. 6.4. Sequenzdiagramm der Editierung einer Benutzereingabe

Produktmodell Das erarbeitete PM ermöglicht die vollständige Repräsentation üblicher Stahlbeton-Hochbauten. Zusätzlich wurden fachspezifische Informationen beispielhaft für die Bereiche der Tragwerksplanung sowie der Raumlufttechnik integriert. Ein besonderer Schwerpunkt wurde hierbei auf der Modellierung von Kollisionen gelegt, die Bauteile beider Gewerke betreffen, wie beispielsweise Wand- oder Deckendurchbrüche infolge der Durchdringung eines Lüftungskanals.

Vernetzt-kooperative Gebäudeplanung im Massivbau

227

Die größtenteils iterative Vorgehensweise beim Planungsprozess erfordert neben der Vorhaltung eines bauteilbezogenen Planungsstatus auch zusätzlich die Berücksichtigung einer Planungshistorie. Aus einer Bearbeitung von Änderungsanfragen durch den Fachplaner des Gewerkes A können Folgeanfragen für das Gewerk B resultieren. Die Evaluierung der Folgeanfrage durch den Client B kann zu erneuten Folgeanfragen – u. a. auch wiederum für Client A – führen. Hierdurch besteht die Gefahr der Bildung von Planungszyklen (Mehrfachbearbeitung gleicher Aufgabenstellungen). Dieser Vorgang kann durch einen Benutzereingriff unterbunden werden. Als Entscheidungshilfe steht dem Anwender hierfür die elementbezogene Planungshistorie zur Verfügung, wobei folgende Attribute hinterlegt werden:

x x x x x

Typ der Veränderung (neu, editieren, löschen) Variable der Änderung (x, y, z, Name, …) vorheriger Wert und neuer Wert ID des Benutzers, der die Änderung vornimmt Zeitpunkt der Änderung n n

Szenario

Grau hinterlegte Klassen -> Prozessmodellierung

1

1

Planungsstatus

1

1

n

n

SD_Lager

Bemessungsstelle

Berechtigungen

n

Benutzer 1

1

n

n

n

1 m

1

Ersteller n

Historie

Element

n

Gebäude

n

SD_BS_Balken

Stockwerk

SD_BS_Wand

Gruppe 1

Bauteil 2

0….

Kollisionselement

SD_Bauteil

1

Raum

n

1

Wanddurchbruch

SD_Balken

Deckendurchbruch

SD_Decke

1

SD_Wand SD_Stuetze

2

Raumvolumen 2..*

4..*

HVAC_Bauteil

n

HVAC_Luefter

1

HVAC_Auslass HVAC_Leitung HVAC_BS_Profil 1

HVAC_Bogen HVAC_Gerade HVAC_Abzweig

Abb. 6.5. Auszug aus dem UML-Klassendiagramm des Produktmodells

Unter Berücksichtigung der für die Planungsabläufe zugrunde liegenden Szenarien ergibt sich das in Abb. 6.5 auszugsweise dargestellte UML-Klassendiagramm des PM. Eine Unterteilung in separate Produkt- und Prozessmodelle, wie beispielsweise in (Bretschneider 1998) praktiziert, wird aus Gründen des zu erwartenden immensen Datenvolumens nicht vorgesehen. Vielmehr ist das im Rahmen dieser

228

Martina Schnellenbach-Held, Torben Pullmann, Markus Hartmann

Arbeit entwickelte PM als übergeordnetes Metamodell aus Produkt- und Prozessmodellierung zu verstehen (Fahrig et al. 2004). Wissensmodell Das KM repräsentiert die formale Sprache, mit der das Wissen problemgerecht strukturiert und in den erforderlichen Wissensinstanzen abgebildet wird. Mit Hilfe des KM wird sowohl Normwissen als auch „unscharfes“ Erfahrungswissen, welches beispielsweise im Rahmen der Sensitivitätsanalyse zur Anwendung kommt, auf der Grundlage definierter Berechnungselemente und -methoden modelliert und strukturiert. Das dieser Arbeit ursprünglich zugrunde liegende KM wurde im Hinblick auf geschlossene Einzellösungen entwickelt. Durch die Anwendung von heterogenen Wissensdomänen in einer verteilten Planungsumgebung ergeben sich jedoch erweiterte Anforderungen an das KM. Neben den zur Formalisierung von Normwissen erforderlichen KM-Klassen wie Formel, Diagramm, Benutzereingabe etc. weist das KM daher folgende grundlegende Erweiterungen gegenüber vorangegangenen Arbeiten auf: PM-Zugriffe Die Klasse PM-Zugriff ermöglicht den Zugriff auf Werte, die im Rahmen einer Auswertung nicht unmittelbar zugänglich sind. Neben dem Zugriff auf AttributWerte von PM-Instanzen (z.B. Durchmesser d eines RLT-Kanals) können auch Verweise auf andere PM-Instanzen, die durch beliebige Relationen innerhalb des PM assoziiert sind, ermittelt werden. Mit Hilfe von Instanzen der KM-Klasse PMZugriff kann aber auch infolge vordefinierter Methoden auf Werte zurückgegriffen werden, deren Ermittlung sich auf Basis anderer Berechnungselemente nur sehr aufwändig gestaltet (beispielsweise komplexe geometrische Zusammenhänge). Neben dem PM-Zugriff auf Parameter des jeweiligen Elementes oder deren übergeordnete Elemente wird auch der Zugriff auf weitere Elemente ohne direkte Zugehörigkeit ermöglicht. Beispielsweise erfolgt für den Nachweis eines Lüftungskanalquerschnittes eine über das gesamte Kanalnetz rückwärts verkettete Aufsummierung des maßgebenden Parameters Volumenstrom. Dies bedeutet, dass innerhalb des Auswertungsprozesses eines Kanalnetzes jedem Lüftungsquerschnitt der Zugriff auf Parameter vorangegangener PM-Elemente ermöglicht werden muss. Nachweisselektionen Mit Hilfe einer Nachweisselektion wird ermittelt, welche Nachweise für die Instanzen PM erforderlich sind und ob diese erfüllt sind. Nachweisselektionen des KM stellen eine Verallgemeinerung der requirement rules und requirement rule sets der Data Item Hierarchy (Garret u. Hakim 1992) sowie der Nachweisselektionen des MEW (Albert 2002) dar. Im Zuge der Nachweisführung gewerke-

Vernetzt-kooperative Gebäudeplanung im Massivbau

229

übergreifender Elemente, welche aus der Kollision von Bauteilen aus unterschiedlichen Gewerken resultieren, wird die Berücksichtigung des Planungsstatus für eine effiziente Nachweisführung erforderlich. Beispielsweise erscheint der endgültige statische Nachweis eines Wanddurchbruchs auf der Grundlage einer bisher nur vordimensionierten Lüftungsleitung wenig sinnvoll. Daher wird der Planungsstatus als ein Kriterium für die Erfordernis eines Nachweises zu einem bestimmten Planungsstand herangezogen. Logische Fuzzy-Modelle / Sensitivitätsanalyse Ziel der Sensitivitätsanalyse ist die adäquate Formalisierung des für das Änderungsmanagement innerhalb von Planungsprozessen erforderlichen Wissens. Damit werden planungsrelevante Konsequenzen aus Änderungen computerunterstützt und vereinfacht abgeschätzt. Eine rein deterministische Betrachtung der von einer Planungsänderung betroffenen Bauteile führt in einem Abhängigkeitsnetz sehr schnell zu einer unüberschaubar großen Anzahl betroffener Bauteile für alle am Planungsprozess beteiligten Gewerke. Im Rahmen einer Sensitivitätsanalyse wird der Anwender bei der Approximation von Konsequenzen für die betroffenen Bauteile infolge Planungsmodifikationen vom System adäquat unterstützt. Statt der einfachen Angabe sämtlicher betroffenen Parameter erfolgt eine aussagekräftige Bewertung möglicher Konsequenzen aus Änderungen, die eine qualitative Einschätzung der Planungsänderung durch den Anwender ermöglicht. Die Abbildung des für die Sensitivitätsanalyse erforderlichen komplexen Expertenwissens bedurfte einer geeigneten Repräsentationsform. Unter Berücksichtigung der spezifischen Anforderungen der vorliegenden Arbeit wurde der Einsatz verschiedener Methoden der künstlichen Intelligenz untersucht. Besondere Anforderungen sind in diesem Zusammenhang: 1. 2. 3. 4.

Möglichkeit der manuellen Wissensakquisition Repräsentation unscharfen Wissens kein vollständiges Vorwissen über den gesamten Suchraum erforderlich transparente Nachvollziehbarkeit der Ergebnisse

Untersucht wurde zunächst die Anwendung Neuronaler Netze. Diese erfüllen nicht die Kriterien 1 und 4 und erschienen somit ungeeignet. Funktionale FuzzyModelle erschienen gut geeignet, erfordern jedoch vollständige Regelbasen und verstoßen somit gegen Kriterium 3. Weiterhin wurde der Einsatz Logischer FuzzyModelle geprüft. Infolge der konjunktiven Verknüpfung eignen sich logische Fuzzy-Modelle besonders gut zur angestrebten Wissensrepräsentation, da aufgrund der hohen Varianz von Eingangsgrößen möglicher Änderungsprozesse die Informationen zur Erstellung der erforderlichen Regelbasis naturgemäß nur unvollständig vorliegen (Dubios et al. 2000). Zur geeigneten Abbildung logischer Fuzzy-Modelle innerhalb des KM wurde eine entsprechende Klasse entwickelt. Für die Implikation wurde der sicherheitsqualifizierende Operator von Lukasiewicz herangezogen: PA B(x,y) = min(1,1PA(x)+PB(y)). Im Rahmen der Akkumulation der Regeln wird infolge konjunkti-

230

Martina Schnellenbach-Held, Torben Pullmann, Markus Hartmann

ver Verknüpfung mittels des MIN-Operators die Ergebnismenge verdichtet. Somit folgt aus zusätzlicher Information eine weitere Einschränkung der Ausgangsvariablen. Als Eingangswerte werden entsprechend der Vorgehensweise logischer Fuzzy-Modelle scharfe Werte (Singletons) zugrunde gelegt. Dies gründet auf der Tatsache, dass die Verwendung unscharfer Eingangswerte mit deren steigenden Unschärfe zu größeren Einschränkungen der möglichen Ergebnisse führen würde, was dem gewünschten Systemverhalten völlig entgegensteht. Durch ein im Rahmen dieser Arbeit entwickeltes Verfahren zur Defuzzyfikation, welches die besonderen Charakteristika der zugrundeliegenden logischen Fuzzy-Modelle berücksichtigt, sowie die Erarbeitung eines Parameters zur Bestimmung der Spezifität resultierender Fuzzy-Ergebnismengen (Parameter for Determination of Specifity – PDS) können planungsrelevante Konsequenzen effizient approximiert werden. 'q 'N'q

'b

Fuzzy-Regeln (Beispiele): (1)

IF [delta_N = "mittel"] AND [delta_l = "keine"] AND [Ausnutzung = "groß"] AND [Lambda = "groß"] THEN [delta_b = "mittel"]

(2)

IF [delta_N = "groß"] AND [delta_l = "keine"] AND [AUsnutzung = "groß"] AND [Lambda = "klein" OR "mittel"] THEN [delta_b = "groß"]

(3)

IF [delta_N = "klein" OR "mittel"] AND [delta_l = "klein"] AND [Ausnutzung = "mittel"] AND [Lambda = "klein" OR "mittel"] THEN [delta_b = "klein"]

Abb. 6.6. Unscharfe Abschätzung der Wandbreitenvarianz 'b infolge veränderter Nutzlast

Beispielhaft wurde für eine Stahlbetonwand ein Fuzzy-Modell zur Approximation von Konsequenzen infolge veränderter Planungsparameter erarbeitet. Abbildung 6.6 zeigt dessen Anwendung für den Fall der Erhöhung der Nutzlast eines abzutragenden Raumes, hier infolge einer Umnutzung. Berücksichtigt werden die Parameter ţN (Laststeigerung), ţl (Änderung der Wandhöhe), Ausnutzungsgrad der Wand, O (Schlankheit der Wand). Als resultierende Größe wird die prozentuale Wandbreitenänderung ţb angegeben. Struktur des Wissensmodells Die Wissensinstanz stellt das zentrale Element eines wissensbasierten Systems dar. Die sinnvolle und transparente Formalisierung des Fachwissens auf der Grundlage der Struktur des Wissensmodells unter Berücksichtigung der Struktur des Produktmodells ist hierbei von entscheidender Bedeutung. Im Rahmen der vorliegenden Arbeit wurde das Wissensmodell (KM) erarbeitet, dessen UMLKlassendiagramm in Abb. 6.7 dargestellt ist.

Vernetzt-kooperative Gebäudeplanung im Massivbau

231

Element

Regelmenge

Berechnungselement

1

n

abgeleitetes Berechnungselement

Regel 1

Nachweisselektion

Konstante

1 1 2

Bedingung

Fremdzugriff

Formel

BasisBerechnungselement

funktionale Fuzzy-Modelle (MA)

Fuzzy-Modell

PDM-Zugriff

funktionale Fuzzy-Modelle (TSK)

Begriffszuweisung

Benutzereingabe

Logische Fuzzy-Modelle

Diagramm

komplexe Tabelle

Tabelle

Wertetabelle

PDM-Zugriff

Abb. 6.7. Auszug aus dem UML-Klassendiagramm des Wissensmodells

Der Inhalt der auf dem KM basierenden Wissensinstanzen untergliedert sich grundlegend in zwei Teilbereiche (s. Abb. 6.8). Zur Repräsentation von Normwissen werden die gewerkespezifischen und richtlinienbezogenen Nachweise vorgehalten. Ebenso besteht die Möglichkeit, unscharfes und auf Erfahrung basierendes Expertenwissen zu formalisieren. Mit Hilfe einer Wissenserwerbskomponente können unter Verwendung und Berücksichtigung der definierten Klassenschemen des PM und des KM durch einen Experten neue Berechnungselemente in der Wissensinstanz, welche die Informationen einer Wissensdomäne beinhaltet, strukturiert und abgelegt werden. Aufgrund der durch den Replikationsmechanismus auch zentral vorgehaltenen Daten der Wissensinstanzen stellt ein Projektserver notwendigerweise eine „vertrauenswürdige Instanz“ innerhalb des Systemverbundes dar. Grundlage für die Akzeptanz eines solchen wissensbasierten Systems in der Praxis ist der Schutz sensibler Daten vor dem Zugriff „Außenstehender“. „Außenstehende“ beschreibt hierbei diejenigen am Planungsprozess Beteiligten, welche das betrachtete Berechnungselement nicht in ihren eigenen Wissensinstanzen formalisiert haben. Daher wurde für alle Berechnungselemente die Möglichkeit der Gruppierung in einen öffentlich-zugänglichen bzw. in einen privat-geschützten Bereich geschaffen. Durch die auf das Ergebnis reduzierte Visualisierung der Auswertung geschützter Berechnungselemente innerhalb der Erklärungskomponente ist der Rechenweg für „Außenstehende“ nicht mehr ersichtlich. Das für die Auswertung erforderliche und formalisierte Expertenwissen steht somit zur Verfügung, bleibt

232

Martina Schnellenbach-Held, Torben Pullmann, Markus Hartmann

aber vor der Einsichtnahme und Antizipation durch weitere Planungsbeteiligte geschützt. Wissensinstanz Teil A

Teil B

Normen (PM)

(KM)

Erfahrungswissen (PM)

(KM)

Wissensakquisition

Abb. 6.8. Aufbau einer gewerkespezifischen Wissensinstanz

Software-Prototypen und Evaluation Zur Evaluierung und als Beleg der Eignung der erarbeiteten Konzepte und Modelle wurden im Rahmen dieser Arbeit die Softwareapplikationen DaVinci sowie die Wissenserwerbskomponente KBDT (Knowledge Base Definition Tool) prototypisch entwickelt. Zusammen bilden diese beiden Softwareapplikationen die Umgebung des entwickelten Modells für eine wissensbasierte Modellierung vernetztkooperativer Planungsprozesse. Die Applikation DaVinci dient zur domänenübergreifenden und netzwerkbasierten, kooperativen Definition, Editierung, Visualisierung und Auswertung der Produktinstanz. DaVinci ist sowohl als Einzelapplikation, als auch im Client/Serverbetrieb lauffähig. Mit Hilfe der in den Clients integrierten Dialogkomponente können die räumlich verteilt angeordneten Projektbeteiligten Instanzen der Produktinstanz definieren, editieren und visualisieren. Innerhalb der zentralen Planungsapplikation des DaVinci-Servers werden der Daten- und Informationsfluss, die gewerkeübergreifende Benutzerinteraktion sowie die erforderlichen Sperrmechanismen gesteuert und geregelt. Hierin beinhaltet ist auch die gewerkeübergreifende Inferenzkomponente, bei der die gewerkespezifischen Wissensinstanzen auf eine Produktinstanz angewendet und die hierbei als erforderlich identifizierten Nachweise im Rahmen des Inferenzprozesses automatisiert geführt werden. Dies geschieht unter Zugrundelegung sowohl der Strukturierung des PM als auch des Schemas des KM. Die in DaVinci integrierte Erklärungskomponente bildet die für wissensbasierte Systeme erforderliche Schnittstelle zum Anwender, in der mit Hilfe der gewerkeübergreifenden Abhängigkeitsverfolgung der Nachweisprozess unter Berücksichtigung privater und öffentlicher Wissensrepräsentation nachvollzogen werden kann. Mit Hilfe der Wissenserwerbskomponente KBDT können Wissensinstanzen definiert sowie editiert werden. Die hiermit formalisierten Instanzen der Berechnungselemente werden den zugehörigen Klassenebenen des PM zugeordnet. Hierfür ist neben der Struktur des KM auch das domänenspezifische Schema des PM erforderlich, welches durch ein spezielles Metaformat zwischen den Applikatio-

Vernetzt-kooperative Gebäudeplanung im Massivbau

233

nen DaVinci und KBDT ausgetauscht wird. Da theoretisch mehrere unterschiedliche PM koexistieren können, wird bei Instanziierung einer neuen Wissensinstanz im KBDT die Assoziation mit einem PM-Schema erforderlich. Zusätzlich besteht die Möglichkeit der Anbindung von Fremdapplikationen an das hier entwickelte System. Während des Inferenzprozesses werden diese wie die Berechnungselemente des privaten Bereichs einer Wissensinstanz behandelt. Da die unscharfe Abschätzung von Planungsänderungen innerhalb der Wissensinstanzen unabhängig von den zugehörigen, deterministischen Berechnungsvorschriften modelliert wird, kann somit auch bei der Anbindung von in sich „gekapselten“ Fremdapplikationen im Gesamtsystem ein vollständiges Änderungsmanagement ermöglicht werden. Durch eine komponentenbasierte Implementierung und die mittels Schnittstellen realisierte offene Architektur kann eine vielseitig einsetzbare Expertensystem-Umgebung bereitgestellt werden. Abbildung 6.9 zeigt die Systemarchitektur der realisierten verteilten Planungsumgebung mit den prototypisch entwickelten Applikationen KBDT und DaVinci.

Lokaler Workspace Fremdkomponente

Dialogkomponente

externe Applikationen zur Schnittgrößenermittlung

DaVinci (Client)

KBDT

-Definition-Editierung-Visualisierung-

-Definition-Editierung-

Benutzerinteraktion

SOAP / XML

(z.B. Finite Elemente; Simulationen;….)

Auswertung

Wissenserwerbskomponente KM PM

gewerkespez. Wissensbank public Sector private Sector

Replikation

Inferenzkomponente Erklärungskomponente PM Produktinstanz (PI)

DaVinci (Server) -Daten- / Informationsfluss-Benutzerinteraktion-Sperrmechanismen-Inferenz (Sensitivität/Nachweis)-

KM public Sector

PM

gewerkespez. public Sector Wissensbank public Sector

zentraler Projektserver

private Sector

Abb. 6.9. Aufbau und Architektur der auf dem entwickelten Softwaremodell basierenden verteilten Planungsumgebung

Zur Überprüfung der im Rahmen dieser Arbeit erstellten Modelle und Konzepte wurde auf der Grundlage des erarbeiteten Produktmodells (PM) ein Referenzmodell (s. Abb. 6.10) erstellt. Das dreigeschossige Bürogebäude beinhaltet Gebäudemodell-Instanzen der in dieser Arbeit beispielhaft untersuchten Gewerke der Tragwerksplanung (Stahlbetonbau) sowie der Haustechnik (Raumlufttechnik). Die im Rahmen dieser Forschungsarbeit erarbeiteten Konzepte konnten hieran erfolgreich evaluiert werden.

234

Martina Schnellenbach-Held, Torben Pullmann, Markus Hartmann

Abb. 6.10. Darstellungen des Referenzmodells

Die Darstellung der Abschätzung von Konsequenzen aus Planungsänderungen erfolgt je nach Auswirkungsgrand die betroffenen Elemente in verschiedenen Helligkeitsstufen. Die Zuverlässigkeit der getroffenen Aussage kann durch Variation der entsprechenden Bauteiltransparenz erfolgen, wodurch zusätzlich gesicherte von ungesicherten Aussagen visuell unterschieden werden können. Abbildung 6.11 zeigt beispielhaft die potentiellen Auswirkungen der Nutzungsänderung eines Raumes auf die lastabtragenden Wände, die im Gegensatz zur Decke bereits vor der Änderung einen hohen statischen Ausnutzungsgrad aufwiesen.

Abb. 6.11. Darstellung von Änderungsabschätzungen

Vernetzt-kooperative Gebäudeplanung im Massivbau

235

6.2.3 Ausblick auf zukünftige Arbeiten Automatisierung der Wissensakquisition Ein kritisches Argument zum Einsatz von Expertensystemen stellt die aufwendige Wissensakquisition dar. Der so genannte „knowledge acquisition bottleneck“ verhindert derzeit eine weitere Verbreitung von Expertensystemen in der Praxis. Im Rahmen dieses Projektes wurde unter anderem durch die deklarative Wissensrepräsentation sowie durch eine benutzerfreundliche Dialogführung in der Wissenserwerbskomponente die Anwendung für den Experten vereinfacht. Dennoch stellt die Formalisierung des Ingenieurwissens, insbesondere die Abbildung komplexen Wissens mittels Fuzzy-Modellen, einen erheblichen Aufwand dar. Weitere Forschungsarbeiten sollten daher eine Automatisierung dieser Aufgabe, beispielsweise durch Methoden der Genetischen Programmierung (Freischlad et al. 2004) zum Ziel haben. Vorgabe von Restriktionen mit unscharfen Grenzen Die Möglichkeit der Vorgabe von Restriktionen mit unscharfen Grenzen für die Werte einzelner Planungsparameter bietet eine weitere sinnvolle Anwendung von Methoden der Fuzzy-Logik im Rahmen einer vernetzten Planungsumgebung. Hierdurch wird beispielsweise das Auffinden von guten Kompromisslösungen bei hochkomplexen Entscheidungen im Rahmen von Planungs-Änderungs-Anfragen ermöglicht. Konsistenzsicherungen von Parameterdefinitionen Bedingt durch die offene Architektur des Modells kann ein Parameter identischer Aussage in verschiedenen Wissensinstanzen völlig unterschiedlich definiert werden. Diese Problematik wird erschwert durch die Tatsache, dass die Wissensinstanzen der Fachplaner jeweils gleichzeitig in mehreren unabhängigen Planungsprojekten Verwendung finden können. Jede Art von Verbindung zwischen entsprechenden Parametern unterschiedlicher Wissensinstanzen darf demnach zur Konsistenzsicherung ausschließlich auf Projektebene stattfinden. Der Administrationsaufwand der in diesem Projekt umgesetzten Mapping-Technik kann in großen Teilen durch Verwendung intelligenter Suchalgorithmen minimiert werden. Ist aus geometrischer und logischer Sicht kein ausreichender Zusammenhang herzustellen, so stellt der zugehörige Beschreibungstext der jeweiligen Parameter die aussagekräftigste Definition dar. Hierbei ist die detaillierte Analyse des semantischen Zusammenhanges zwischen Teilen des beschreibenden Textes erforderlich. Ein Ansatz zur entsprechend automatisierten Analyse von Texten ist deren zielgerichtete Transformierung in semantische Netze. Die Kombination mehrerer Typen von semantischen Netzen kann die Entwicklung und Erprobung einer geeigneten, intelligenten Suchkomponente, die erheblich zur Reduzierung des Administrationsaufwands beiträgt, ermöglichen. Dies ist für kritische Berechnungen aus Gründen

236

Martina Schnellenbach-Held, Torben Pullmann, Markus Hartmann

der Sicherheit zwar nur im Bereich interaktiver Unterstützung möglich. Für unkritischere Anwendungen ist bei entsprechender Treffsicherheit eine teil- oder vollautomatisierte Suche sinnvoll durchführbar. Diese Unterscheidung ist für das Vertrauen der Fachplaner in zugehörige Parameter von entscheidender Bedeutung. Interdisziplinäre Weiterentwicklung Die im Rahmen dieser Arbeit entwickelten Modelle stellen einen innovativen Ansatz zur Reduzierung des Arbeits- und Zeitaufwands im Rahmen der Änderungskontrolle im Vergleich zu der heutigen Arbeitsweise dar und versprechen darüber hinaus eine künftige domänenübergreifende Anwendbarkeit. Durch die Aufteilung des Gesamtmodells in mehrere Teilmodelle wird die Möglichkeit der Anwendung dieses wissensbasierten Systems auch in weiteren Domänen sichergestellt. Die Anpassung der Struktur innerhalb des PM ermöglicht die Anwendung der Wissensinstanzen auch auf adäquate Informations-Modelle. Diesen Wissensinstanzen muss lediglich die Struktur des erforderlichen PM zugrunde liegen. Somit ist es möglich, Wissensinstanzen auch auf völlig andere (Bau-)Konstruktionen anzuwenden. Verknüpfungen mit anderen Forschungsvorhaben Innerhalb der Arbeitsgruppe „Verteilte Produktmodelle“ des Schwerpunktprogramms wurden unter der Leitung von Prof. Firmenich die unterschiedlichen Arbeitsweisen der verschiedenen Systeme herausgearbeitet. Hierfür wurde für alle beteiligten Projekte im Vorfeld des Berichtskolloquiums in Herrsching (2003) ein praxisbezogenes Szenario erarbeitet. Mit Hilfe der jeweiligen systembezogenen Bearbeitungsmethodik konnten so die unterschiedlichen Ansätze für alle Beteiligten sehr transparent veranschaulicht werden. Zusätzlich wurde eine projektübergreifende Systemarchitektur erarbeitet. Neben der Übertragbarkeit der Struktur auf die einzelnen Projekte lag ein Schwerpunkt auf der Begriffsvereinheitlichung. Dies ist u. a. Grundlage für die weitere gemeinsame Kommunikation und Zusammenarbeit. In der Arbeitsgruppe erfolgte eine engere Kooperation mit dem Projekt „Neue Software-Werkzeuge zur Unterstützung des konzeptuellen Gebäude-Entwurfs“ von Herrn Prof. Nagl (Kraft u. Wilhelms 2004), s. auch Beitrag III.4. Dieses Vorhaben verfolgt ebenso wie das vorliegende Projekt einen wissensbasierten Ansatz. Abweichend zur deklarativen Wissensrepräsentation im hier bearbeiteten Forschungsprojekt wird von Prof. Nagl eine Plattform zur Wissensrepräsentation mit Hilfe einer vorgegebenen graphbasierten Darstellung erarbeitet. Es wurde die Möglichkeit der Verknüpfung des Fachwissens aus beiden wissensbasierten Ansätzen überprüft. So kann beispielsweise eine konzeptuelle Überprüfung des Gebäude-Entwurfs vor der eigentlichen Nachweisführung im Rahmen der Entwurfsplanung erfolgen. Die Aufgabenfelder dieser beiden bearbeiteten Projekte ergänzen sich vom Planungsablauf diesbezüglich sehr gut.

Vernetzt-kooperative Gebäudeplanung im Massivbau

237

Literatur Albert A (2002) Wissensbasiertes Entwerfen und Bemessen von Tragwerken unter Einsatz von Fuzzy-Methoden. Dissertation, TU Darmstadt, Fortschritt-Berichte VDI, VDIVerlag, Düsseldorf Albert A, Pullmann T, Freischlad M, Hartmann M (2003) Wissensbasierte Entwurfsbearbeitung gemäß DIN 1045-1. Tagungsband: Darmstädter Massivbau-Seminar – IuK-Technologie, Darmstadt Altenkrüger D, Büttner W (1992) Wissensbasierte Systeme. Vieweg, Braunschweig Ambler SW (2003) Agile Database Techniques – Mapping Objects to Relational Databases. Wiley-Publishing Behaneck M (2002) IBPM darf jetzt kein Fremdwort mehr bleiben. Deutsches IngenieurBlatt – Heft 5 Beierle C, Kern-Iseberger G (2003) Methoden wissensbasierter Systeme. Vieweg Verlag, Wiesbaden Bretschneider D (1998) Modellierung rechnergestützter, kooperativer Arbeit in der Tragwerksplanung. Dissertation, Ruhr-Universität Bochum, Fortschritt-Berichte VDI, VDIVerlag, Düsseldorf Dubois D, Ughetto L, Prade H (2000) Fuzzy interpolation by convex completion of sparse rule bases. Proceedings of the 9th International Conference on Fuzzy Systems (FUZZIEE’00), San Antonio Fahrig T, Nachtwey B, Geller S, Tölke J, Krafczyk M (2004) A Product Model based Approach to Interactive CAE Design Optimization. Proceedings of the Xth International Conference on Computing in Civil and Building Engineering, Weimar Freischlad M, Albert A, Pullmann T, Lubasch P, Schnellenbach-Held M (2004) Genetic Programming based Fuzzy System Design for Knowledge Representation in Structural Engineering. Proceedings of the 11th Workshop of the European Group for Intelligent Computing in Engineering (EG-ICE), Weimar Garrett JH, Hakim MM (1992) An object-oriented model of engineering design standards. Journal of computing in civil engineering, vol 6, no 3, pp 323–347 Görz G, Rollinger CR, Schneeberger J (2003) Handbuch der Künstlichen Intelligenz. 4. Aufl, Oldenburg-Verlag Hartmann M, Pullmann T, Schnellenbach-Held M (2004) Architecture of a Knowledge Based System for Computer Supported Cooperative Design Processes. Proceedings of the 11. Workshop of the European Group for Intelligent Computing in Engineering, Weimar Hartmann M, Schnellenbach-Held M (2005) Knowledge Bases and Fuzzy Methods in Structural Engineering. Tagungsband: Deutsch-Russisches Bauinformatik-Symposium, Moskau Holéwik P (1996) Ein objektorientiertes Wissensrepräsentationsmodell zur Entwicklung computerunterstützter Nachweissysteme im Bauwesen. Dissertation, Technischwissenschaftliche Mitteilung Nr. 96-7, Bochum Kraft B, Wilhelms N (2004) Interactive distributed Knowledge Support for Conceptual Building Design. Proceedings of the Xth International Conference on Computing in Civil and Building Engineering, Weimar Messner JI, Sanvido VE (1993) Developing an integrated database structure for the lifecycle of precast concrete projects. Cohn (ed) Proceedings of the Fifth International Conference on Computing in Civil and Building Engineering, Anaheim, pp 646–653 Miles JC (2005) IT-Supported Collaboration for Structural Engineering. Structural Engineering International, vol 15, no 3, pp 139–144

238

Martina Schnellenbach-Held, Torben Pullmann, Markus Hartmann

Miles JC, Moore L, Cadogan J (2002) Matching computational strategies to task complexity and user requirements. Advanced Engineering Informatics, vol 16, no 1, pp 41–51 Nii HP (1986) Blackboard Systems: Blackboard Application Systems – Blackboard Systems from a Knowledge Engineering Perspective. AI Magazine (3), pp 82–106 Petersen M (2002) Ein Konzept verteilter Software-Komponenten zur Integration der thermischen Bauphysik in die Gebäudeplanung. Dissertation, TU Darmstadt, Shaker Verlag Sanders K (2004) Why building information modeling isn’t working ... yet. FAIA, Architectural Record Schlichter J (2000) Rechnergestützte Gruppenarbeit. Vorlesungsskript, Technische Universität München Schnellenbach M (1991) Wissensbasierte Integration und Steuerung computergestützter Entwurfsprozesse im Stahlbetonbau. Dissertation, Technisch-wissenschaftliche Mitteilung Nr. 91-15, Institut für Konstruktiven Ingenieurbau, Bochum Schnellenbach-Held M, Hartmann M (2003a) Computer Supported Cooperative Design Processes in Distributed Environments Supported by Knowledge Based Systems. Proceedings of the 10. Workshop of the European Group for Intelligent Computing in Engineering, Delft Schnellenbach-Held M, Hartmann M (2003b) Using Knowledge Based Systems for Building Design in Computer Supported Cooperative Work. Darmstadt Concrete, vol 18, Eigenverlag Schnellenbach-Held M, Hartmann M (2005a) Online Expert Systems & Risk Analysis in Change Management. Proceedings of the IABSE-Symposium – Structures and Extreme Events, International Association for Bridge and Structural Engineering, Lissabon Schnellenbach-Held M, Hartmann M (2005b) Computer Supported Knowledge Based Cooperative Work. 3rd International DIANA Users Meeting, Keynote Lecture Schnellenbach-Held M, Freischlad M, Albert A (2002) Fuzzy rule based models for structural design decisions. Proceedings of IABSE-Symposium – Towards a Better Built Environment / Innovation, Sustainability, Information Technology, Melbourne Schnellenbach-Held M, Hartmann M, Pullmann T (2004) Knowledge Based Systems in Distributed Design Environments. Proceedings of the Xth International Conference on Computing in Civil and Building Engineering, Weimar Schnellenbach-Held M, Hartmann M, Pullmann T (2006) Knowledge Based Modeling in Networked Cooperative Building Design using Elements of Fuzzy Logic. Proceedings of the XIth International Conference on Computing in Civil and Building Engineering, Montreal Steiger F (1998) Datenmanagement bei Großprojekten. Der Eisenbahningenieur, Heft 7 World Wide Web Consortium: XML Protocol Working Group ( www.w3.org/2000/xp/Group) Zimmermann F (1999) Kooperatives Bauen via www. Gebäudemanagement, Heft 3

Teil IV Verteilte Simulation

1 Überblick zum Themenbereich Verteilte Simulation

Manfred Krafczyk Technische Universität Braunschweig, Institut für Computeranwendungen im Bauingenieurwesen (CAB) [email protected]

1.1 Ziele der Arbeitsgruppe 1.1.1 Einführung und Motivation Unter dem Begriff Simulation versteht man allgemein die Imitation des Verhaltens eines existierenden oder zu entwickelnden Systems. Spezifischer wird im Rahmen des in diesem Band beschriebenen Schwerpunktprogramms unter einer Simulation die rechnerbasierte Modellierung von Ingenieurproblemen aus dem Bereich des Konstruktiven Ingenieurbaus verstanden. Die Teilprojekte der AG Verteilte Simulation untersuchen die Eignung verschiedener Ansätze für verteilte Simulationen als Teil von Planungs-, Entwurfs- und z. T. auch Ausführungsprozessen im Konstruktiven Ingenieurbau. Solche verteilten Simulationen führen im Allgemeinen zu Konflikten bei der Zusammenführung parallel bearbeiteter Fachmodelle, die eine konsistente Modellentwicklung und -haltung erschweren. Der Schwerpunkt der Forschungsarbeiten in der AG liegt daher auf methodischen Entwicklungen und exemplarischen Validierungen von Simulations- und Organisationsmodellen auf unterschiedlichen Verteilungsebenen, die konzeptionell zur Konfliktminimierung bzw. zur Konfliktlösung beitragen und von verteilten Planungspartnern im Verbund betrieben und bewertet werden können. 1.1.2 Stand der Technik Die verteilte Simulation beinhaltet die verteilte Erstellung, Ausführung und Datenhaltung von Modellen und Simulatoren. Jedes sinnvolle Gesamtmodell einer

242

Manfred Krafczyk

verteilten Simulation sollte im Prinzip modular und hierarchisch aus wieder verwertbaren existierenden Teilmodellen aufgebaut werden können. Die Teilmodelle können im Prinzip auf jeweils dedizierter vernetzter Hardware residieren. Ereignisse oder Ergebnisse von Simulationen werden dann mithilfe von geeigneten Strategien an die Komponenten des Gesamtmodells weitergeleitet. Das Gebiet der Verteilten Simulation hat sich in den letzten zwanzig Jahren rasant entwickelt. Maßgebliche Beiträge stammen aus verschiedensten Bereichen der Informatik über die Mathematik bis hin zu den Ingenieurwissenschaften, wobei die jeweiligen fachspezifischen Sichten auf die Problematik sich durchaus qualitativ unterscheiden. Die Vielfalt der Ansätze lässt sich neben einer Vielzahl von Publikationen schlaglichtartig an dem Umstand ablesen, dass sich allein unter dem Begriff verteilte Simulation bei Google 462.000 Treffer und bei der englischen Version distributed simulation mehrere Millionen Einträge finden lassen. Es soll daher an dieser Stelle auf den Versuch verzichtet werden, einen kompletten Überblick über das Gebiet zu geben; stattdessen erfolgt eine kurze Einführung in typische Probleme bei der verteilten Simulation sowie eine übersichtsartige Auflistung der meistverbreiteten Lösungsansätze und Implementationen verteilter Simulationsumgebungen. Nachfolgend sind einige der meistverbreiteten (Integrations-) Ansätze zur Verteilten Simulation aufgeführt:

x HLA (High-Level-Architecture) Diese Simulationsumgebung entstand durch eine Initiative des amerikanischen Verteidigungsministeriums und wurde vor kurzem als IEEE-Standard für verteilte Simulation akzeptiert. Kernstück ist die Einführung einer sog. runtime infrastructure (RTI), die als globales Interface eine Art verteilten Aufsatz zu den darunter liegenden (potentiell heterogenen) Betriebssystemen der das Hardwaremodell konstituierenden und an der verteilten Simulation beteiligten Plattformen darstellt. Jeder Einzelsimulator muss eine entsprechende Schnittstelle zum globalen Interface bereitstellen. Eine einführende Übersicht findet sich in (Straßburger 2001). Seit kurzem existiert auch eine Open Source Variante (OHLA 2006), deren Funktionalität bezogen auf das proprietäre Original aber eingeschränkt ist. x CORBA (Common Object Request Broker Architecture) Dieser von der OMG (Object Management Group) entwickelte Standard ist eine Middleware, die Kommunikations- und Synchronisationsmechanismen zur plattformübergreifenden Ausführung gekoppelter Anwendungen im Sinne eines Client-Server-Ansatzes zur Verfügung stellt. Eine einführende Übersicht findet sich unter (CORBA 2006). x JADE (Java Agent Development Framework) Diese Simulationsumgebung ist ein bekannter Vertreter sog. Agentensysteme, welche ausführlich in den Teilprojekten der AG Agentensysteme beschrieben werden. Es existieren weitere agentenbasierte Systeme, die sich strukturell ähneln, jedoch bezüglich des Implementationsstandes qualitativ deutliche Unterschiede aufweisen.

Überblick zum Themenbereich Verteilte Simulation

243

x CCA (Common Component Architecture) Diese Entwicklungslinie wurde vom amerikanischen Energieministerium und einer Reihe von Großforschungszentren initiiert und trägt insbesondere den Anforderungen von gekoppelten Simulatoren im Hochleistungsrechnen (High Performance Computing, HPC) Rechnung. Einführendes Material findet sich unter (CCA 2006). x MPI (Message Passing Interface) Dieser low-level Kommunikationsstandard wird oftmals auch als Beispiel für eine Plattform für verteilte Simulation beschrieben. Dies ist aber insofern irreführend, als es sich dabei eher um eine standardisierte Sammlung von low-level Kommunikations- und Synchronisationsroutinen handelt, für die mehrere freie Implementationen erhältlich sind (MPI 2006). Schwerpunkt dieser Pakete ist eine große Kommunikationsbandbreite. Eine echte objektorientierte Anbindung ist nicht Teil des Standards. Durch den vergleichsweise geringen Abstraktionslevel ist für die Nutzung in einer verteilten Anwendung meist ein massiver Eingriff in die zu verwendenden Simulatoren auf Quelltextebene erforderlich. Nach Ansicht des Autors adressieren keine der oben skizzierten Ansätze die für eine erfolgreiche Integration von unterschiedlichsten Simulationen im Bauingenieurwesen nötigen Fragen bzgl. der oben angesprochenen Notwendigkeiten einer automatischen Transformation zwischen Modellattributen unterschiedlicher Modellrepräsentationen. Diese müssen alle individuell für die jeweiligen Simulationsumgebungen implementiert werden. Die Arbeiten im Schwerpunktprogramm und insbesondere in der Arbeitsgruppe fokussierten sich damit auf entsprechende methodische Ansätze als auf erweiterte Schnittstellendefinitionen und allgemeine zeitliche Synchronisationsmechanismen. Für die in diesem Schwerpunktprogramm und insbesondere der AG Verteilte Simulation relevante Problematik lassen sich drei typische Kategorien der rechnergestützten Simulation identifizieren: 1. numerische Simulation: Viele Modelle des Konstruktiven Ingenieurbaus basieren auf einer Kontinuumsbeschreibung durch partielle Differentialgleichungen. Diese Gleichungen haben in den meisten praxisrelevanten Fällen keine analytischen Lösungen. Daher werden zur Auffindung von Näherungslösungen numerische Verfahren verwendet (z.B. Finite Elemente, Finite Volumen oder Finite Differenzen), die bei komplexen Problemstellungen mit vielen Freiheitsgraden sehr große Anforderungen an die Leistungsfähigkeit der verwendeten Rechnerhardware stellen können. Neben numerischen Methoden zur Näherungslösung von Differentialgleichungen existieren aber noch viele andere ingenieurspezifische Berechnungsverfahren, die eine rechnergestützte Bearbeitung erfordern (Computational Geometry, Lineare Algebra, Statistik, Sensitivitätsanalyse etc.) 2. ereignisbasierte Simulation: Hier werden Modelle im Rechner abgebildet, bei denen es weniger um die Manipulation algebraischer Ausdrücke als um die Bestimmung des Verhal-

244

Manfred Krafczyk

tens eines Gesamtsystems geht. Dieses Gesamtsystem besteht aus diskreten Komponenten, deren individuelle Wechselwirkung durch unterschiedliche Synchronisierungsmechanismen modelliert wird, wobei das Gesamtverhalten implizit durch die Summe aller individuellen Ereignisse (neudeutsch: Events) gesteuert wird. Beispiele hierfür sind graphische Oberflächen, Betriebssysteme, Agentensysteme oder Ablaufplanungen sowie Zelluläre Automaten. 3. analytische Simulation: Viele Problemstellungen lassen sich durch Anwenden mehr oder minder aufwändiger symbolischer Regelwerke lösen. Vertreter der entsprechenden Lösungsansätze sind alle Computeralgebrasysteme (Mathematica, Maple, Matlab etc.), sowie diskrete Nachweisverfahren als auch viele der sog. Expertensysteme. In der Planungs- und Entwurfsphase eines Bauwerks kommen vielfältige Simulationswerkzeuge zum Einsatz, deren Modellcharakter sich qualitativ voneinander unterscheidet und die entsprechend unterschiedliche Sichten bzw. Repräsentationen von Teilaspekten des Gesamtproblems widerspiegeln. Als typische Beispiele seien hier die CAD-Modellierung, die numerische Simulation von Struktur- und strömungsmechanischen Problemen für Fragestellungen der Tragfähigkeit oder Klimatisierung sowie die Bauablaufmodellierung genannt. Bei der Planung einer verteilten Simulation bzw. Analyse im Konstruktiven Ingenieurbau lassen sich verschiedene Kategorien bzw. Ebenen der Verteilbarkeit feststellen, deren wichtigste in der AG wie folgt identifiziert wurden: 1. fachmodellübergreifende Verteilung: Hier erfolgt die verteilte Verarbeitung zweier Modelle, welche eine weitgehend unterschiedliche Modellrepräsentation besitzen, wie beispielsweise ein CAD-Modell und ein Tragwerksmodell. Naiv würde man davon ausgehen, dass geometrische Körper in dem einen Modell eindeutig den entsprechenden geometrischen Objekten im anderen Modell entsprechen. Eine solche eindeutige Transformation zwischen den Modellen ist aber nicht immer möglich, da beispielsweise die Änderung der geometrischen Abmessungen eines Objektes im CAD-System einen Wechsel des entsprechenden physikalischen Modellattributes im Tragwerksmodell erzwingen müsste (beispielsweise von der Platte zum elastischen 3D-Körper), d. h. im Allgemeinen können stetige Änderungen von Modellattributen im einen Modell diskontinuierliche Änderungen anderer Modellattribute in einem anderen Fachmodell bewirken. Diese semantische Adaption beim Transfer von Modellattributen ist bisher noch nicht vollständig automatisierbar und ist einer der Gründe für Schwierigkeiten bei der Erstellung einer für beide Fachmodelle konsistenten Zusammenführung beispielsweise innerhalb eines übergeordneten Produktmodells. 2. Verteilung zwischen verschiedenen Planungsbeteiligten innerhalb eines Teilmodells: In diesem Fall werden entweder verschiedene Teilmodelle eines Fachmo-

Überblick zum Themenbereich Verteilte Simulation

245

dells oder identische Teilmodelle mit unterschiedlichen Parametern zeitlich parallel untersucht. Die Zusammenführung der beiden bearbeiteten Varianten kann i. A. inkompatible Änderungen enthalten, deren konsistente automatisierte Bereinigung bisher nicht immer gelingt. 3. Nutzung verteilter Hardwareressourcen innerhalb der Simulation eines Teilmodells: Die Komplexität eines Teilproblems (beispielsweise eine komplexe numerische Tragwerksanalyse) erfordert die Bearbeitung durch mehrere Prozessoren einer räumlich verteilten, vernetzten Hardwareumgebung. Neben der Entwicklung von Synchronisationsalgorithmen, welche die Korrektheit einer parallelen Ausführung sicherstellen, sind dabei neben der konsistenten Modellhaltung u. a. die speziellen Anforderungen von Mehrprozessorarchitekturen (Cluster, Grid) sowie Mechanismen zur gleichförmigen Verteilung der Rechenlast von Interesse. Die Schwierigkeiten bei der Umsetzung einer effizienten verteilten Bearbeitung des Planungsprozesses inklusive Versionierung sind also bedingt durch:

x die unterschiedlichen Abstraktionsgrade der Fachmodelle, x strukturelle Unterschiede in der semantischen Definitionsschärfe der die Fachmodelle konstituierenden Entitäten sowie daraus resultierend eine

x oftmals weit reichende Inkompatibilität der vielfältigen unterschiedlichen Fachmodelle, die im Allgemeinen keine eineindeutige Zuordnung bzw. Transformation zwischen den Objekten bzw. den Attributen derselben erlaubt. 1.1.3 Verfolgte Ansätze in der Arbeitsgruppe In Ermangelung eines allgemein gültigen theoretischen Konzeptes, welches die Überwindung der oben skizzierten Schwierigkeiten systematisch zu eliminieren erlaubte, verfolgten die drei der Arbeitsgruppe zugehörigen Teilprojekte in der Systematik unterschiedliche jedoch gleichzeitig kompatible Ansätze, deren Umsetzung in allen Fällen als erfolgreich angesehen werden kann. Die Datenhaltung wurde durchgängig in Form eines IFC-Produktmodells (Industry Foundation Classes) betrieben, welches einen Standard zur digitalen Beschreibung von Gebäudemodellen definiert, bei dem logische Gebäudestrukturen (z.B. Fenster-ÖffnungWand-Geschoss-Gebäude), zugehörige Eigenschaften (Attribute) sowie optional Geometrien abgebildet werden (IFC 2006).

246

Manfred Krafczyk

1.2 Arbeiten 1.2.1 Sensitivitätsanalyse netzwerkübergreifender Produkt- und Strukturmodelle bei Planungsprozessen des Konstruktiven Ingenieurbaus Prof. Dr.-Ing. K.-U. Bletzinger, Lehrstuhl für Statik, TU München Zielsetzung: Ziel dieses Forschungsvorhabens war es, Methoden der Sensitivitätsanalyse in den kooperativen, disziplinübergreifenden Planungsprozess des Konstruktiven Ingenieurbaus einzubringen. Durch die Analyse des Planungsstandes sowie der möglichen Auswirkungen eigener Entscheidungen in der Wechselwirkung mit den Partnern und daraus folgend einer möglichst zutreffenden Prognose des Planungsfortschrittes sollen der Planungsprozess unterstützt und insgesamt schnellere und wirtschaftlichere Lösungen ermöglicht werden. Konzept: Die Aufgabe wurde aus Sicht von zwei Abstraktionsebenen bearbeitet. Auf der obersten Abstraktionsebene wurden die grundsätzlichen Modellbezüge aus der Sicht des übergeordneten und interdisziplinären Kooperationsmodells betrachtet („top down“) sowie Modelle und Interaktionen über definierte Schnittstellen und Kommunikationsmethoden analysiert. Realisiert wurde dies in Form einer agentenbasierten Kollaborationsumgebung. Auf einer komplementären Abstraktionsebene wurde das Problem von unten angegangen („bottom up“). Hier wurden Teilaufgaben bei der Definition von Eingangs- und Antwortgrößen und des daraus folgenden Datenaustausches konsequent als austauschbare Softwarekomponenten definiert und umgesetzt. Methoden: Für vorhandene Methoden und Softwaremodule wurden Mechanismen für eine stecker-kompatible Austauschbarkeit entwickelt, um netzwerkübergreifend Sensitivitätsanalysen flexibel im Sinne eines Baukastensystems formulieren zu können. Beide Strategien wurden simultan verfolgt, um jede Sicht möglichst vollständig zu gestalten. Hieraus entstand ein Analysetool, das einen Analysten dabei unterstützt, Modellparameter zu variieren und Systemantworten auszuwerten. Letztlich erfolgte die Integration dieses Analysetools in eine agentenbasierte Kollaborationsumgebung. 1.2.2 Ein Prototyp für verteilte, interaktiv-kooperative Simulationen zur Beschleunigung von Entwurfszyklen im Konstruktiven Ingenieurbau Prof. Dr. M. Krafczyk, Dr. Jonas Tölke, Institut für Computeranwendungen im Bauingenieurwesen, TU Braunschweig

Überblick zum Themenbereich Verteilte Simulation

247

Zielsetzung: Entwicklung einer Produktmodell- und Virtual Reality-basierten Plattform zur transdisziplinären Optimierung von HVAC-Installationen im Konstruktiven Ingenieurbau. Konzept: Entwicklung eines Computational Steering basierten Ansatzes, um durch kooperative und interaktive Simulation von Entwurfs- und Konstruktionsvarianten verschiedener Fachmodelle mit simultaner Visualisierung modellspezifischer Zielfunktionswerte in einem gemeinsamen virtuellen Entwurfsraum eine Verständigung zwischen unterschiedlichen Fachplanern mittelbar zu ermöglichen und zu verbessern. Durch iterative Modifizierung der einzelnen Fachmodelle ist eine interaktive Optimierung des Modells möglich, wobei alle für die Klimatisierung relevanten Modellattribute interaktiv und zur Laufzeit der Strömungssimulation geändert werden können. Methoden: Der Computational Steering Ansatz kombiniert folgende Softwarekomponenten:

x AutoCAD in Verbindung mit dem Architectural Desktop als geometrischen x x x x x

Modellierer, den parallelen Strömungssimulator Virtual Fluids, einen oktalbaumbasierten Gittergenerator, VISIT als Interface zwischen dem numerischen Kernel und dem Visualisierungssystem AVS sowie weitere Werkzeuge zur Steuerung des Agentensystems, welches die Virtualiserung der Steuer-, Mess- und Regeltechnik umsetzt.

1.2.3 Volumenorientierte Modellierung als Grundlage einer vernetztkooperativen Planung im Konstruktiven Ingenieurbau Prof. Dr. E. Rank, Lehrstuhl für Bauinformatik, TU München Prof. Dr. H.-J. Bungartz, Institut für Informatik, TU München Zielsetzung: Grundlegendes Ziel dieses Projekts war die Verbesserung einer kooperativen Zusammenarbeit vor allem im Hinblick auf die Tragwerksplanung im Konstruktiven Ingenieurbau. Zwei Punkte standen hierbei im Zentrum der Diskussion: eine strikte Modellierung mittels volumenbasierter Strukturen und das Rechnen am Gesamtsystem. Konzept: Das Forschungsprojekt ging davon aus, dass die kooperative Arbeit verschiedener Planer immer über ein gemeinsames, zentral verwaltetes Modell organisiert werden soll. Dieses liegt als attributiertes, geometrisches Modell des Gesamtsystems vor, wobei bei Bedarf Teilmodelle und Sichten davon abgeleitet werden können. Insbesondere bei konkurrierenden Zugriffen kann damit eine Konsistenz des Datenbestandes sowohl in mechanischer als auch geometrischer

248

Manfred Krafczyk

Hinsicht besser gewährleistet werden. Für die Organisation dieses Modells sowie in den angewandten Berechnungsverfahren spielten vor allem Konzepte der Hierarchie, der Graphentheorie sowie Finite-Elemente-Methoden hoher Ordnung eine wichtige Rolle. Methoden:

x Verwendung eines expliziten geometrischen Volumenmodells Dieses wurde zu Beginn verschiedener Simulationsdurchläufe aus einem standardisierten Bauwerksmodell abgeleitet x Graphenbasierte Analyse und topologische Aufbereitung der Gebäudestruktur x Hierarchische Organisation des Gebäudeinformationsmodells durch einen Oktalbaum als grundlegendes Organisationsschema x p-FEM zur Strukturanalyse

1.3 Ergebnisse Die in den Teilprojekten verfolgten Ansätze (volumenorientierte Modellierung, oktalbaumbasiertes CSCW-Framework und Organisationsprinzip, VR-basiertes und verteiltes Computational Steering sowie die Sensitivitätsanalyse), wurden erfolgreich sowohl an teilprojektspezifischen also auch an einem gemeinsamen, integrierenden Beispiel validiert. Dabei wurde die gekoppelte Problematik der Klimaoptimierung in Verbindung mit einer verteilten Tragwerksanalyse bei Modifikationen des Baukörpers simuliert und die auftretenden Nichtlinearitäten einer Sensitivitätsanalyse unterzogen. Nähere Ausführungen dazu finden sich in den Ergebnisbeschreibungen der Teilprojekte sowie zu der Verbundvalidierung in (Krafczyk et al. 2006).

1.4 Erkenntnisse Die in den Teilprojekten bzw. der AG verfolgten Ansätze zur Unterstützung der verteilten Simulation auf unterschiedlichen Ebenen haben sich im Rahmen ihrer ursprünglichen Zielsetzung bewährt. Gleichzeitig wurde aber offensichtlich, dass zu einer befriedigenden Lösung der Gesamtproblematik neben den in den anderen Arbeitsgruppen des Schwerpunktprogramms erzielten Ergebnissen weitere substantielle Forschungsanstrengungen nötig sind, um einen Durchbruch in Richtung einer allgemeinen und nachhaltigen Lösungsstrategie für effiziente verteilte Simulationen im Konstruktiven Ingenieurbau zu erzielen. Dazu erscheint es nicht nur notwendig, die in den unterschiedlichen Arbeitsgruppen gewonnenen methodischen Kenntnisse stärker als im Rahmen des Schwerpunktprogramms zeitlich möglich zu kombinieren, sondern auch erweiterte theoretische Ansätze zu verfolgen. Dazu gehören z.B. Fragen der Langzeitstabilität von Daten und Interfaces

Überblick zum Themenbereich Verteilte Simulation

249

sowie Technologien, die zukünftig idealerweise eine semantisch konsistente und autonome Kommunikation über dynamisch erzeugte Daten- und Prozessschnittstellen erlauben. Auch wenn sich durch eine solche Theorieorientierung temporär die Schere zwischen den in der Praxis zurzeit eingesetzten Verfahren und den im Rahmen von Grundlagenforschung entwickelten prototypischen Demonstrationsplattformen weiterhin öffnen sollte, ist es doch primäres Ziel der Bauinformatik, Prozesse und Systeme im Bereich des „Civil Engineering“ optimal und rechnerkonform abzubilden und dieses für ausgesuchte Beispielfälle zu demonstrieren, bevor in Kooperation mit praxisorientierten Projektpartnern und geeigneten Gremien soziotechnologische Hemmnisse wie eine auf die neuen Entwicklungen noch nicht abgestimmte Gebührenordnung (HOAI) sowie eine Unzahl weiterer sog. „weicher“ Hemmnisse angegangen werden können, welche einem nachhaltig innovativen Umgang der Bauindustrie mit modernster Hard- und Software bei entsprechender Produktivitätssteigerung bisher noch im Wege stehen.

Literatur CCA (2006) http://www.extreme.indiana.edu/~gannon/cca_report.html CORBA (2006) http://www.omg.org/gettingstarted/corbafaq.htm IFC (2006) http://www.buildingsmart.de/ Krafczyk M, Fahrig T, Tölke J, Niggl A, Rank E, Lähr A, Bletzinger U (2006) A generalized product-model based framework for multidisciplinary sensitivity analysis and optimization in civil engineering. Joint International Conference on Computing and Decision Making in Civil and Building Engineering, Montreal, Canada MPI (2006) http://www.mpi-forum.org/ OHLA (2006) http://sourceforge.net/projects/ohla/ Straßburger S (2001) Distributed Simulation Based on the High Level Architecture in Civilian Application Domains. PhD, Otto-von-Guericke-Universität Magdeburg, Magdeburg

2 Sensitivitätsanalyse netzwerkübergreifender Produkt- und Strukturmodelle bei Planungsprozessen des Konstruktiven Ingenieurbaus

Kai-Uwe Bletzinger, André Lähr Technische Universität München, Lehrstuhl für Statik {kub | laehr}@bv.tum.de

2.1 Zusammenfassung und Ziele Ziel dieses Forschungsvorhabens ist es, Methoden der Sensitivitätsanalyse in den kooperativen, disziplinübergreifenden Planungsprozess des Konstruktiven Ingenieurbaus einzubringen. Durch Analyse des Planungsstandes sowie der möglichen Auswirkungen eigener Entscheidungen in der Wechselwirkung mit den Partnern und daraus folgend eine möglichst zutreffende Prognose des Planungsfortschrittes, soll der Planungsprozess unterstützt werden und insgesamt schnellere und wirtschaftlichere Lösungen ermöglichen. Ein Planungsfortschritt ist definiert durch die Differenz zweier zeitlich verschiedener Planungsstände und setzt Planungsaktivitäten voraus, die zum Übergang vom „alten“ in den „neuen“ Planungsstand führen. Solche Planungsaktivitäten sind neben äußeren Einflüssen vor allem Entscheidungen von Planungsbeteiligten, den so genannten Fachplanern. Des Weiteren müssen Planungsfortschritte und somit auch Planungsstände beurteilt werden können. Hierbei ist zu berücksichtigen, dass eine solche Beurteilung von einem subjektiven Blickwinkel eines Betrachtenden abhängt und nicht für eine allgemeine Bewertung herangezogen werden kann. Solche Bewertungen dienen dem Auffinden von Schwachstellen in einem Planungsprozess, bzw. tragen zur kontextbedingten Entscheidungsfindung bei. Von den genannten Aufgaben fallen viele in das Gebiet der Sensitivitätsanalyse, welche bei der Entwicklung der Methoden eine zentrale Bedeutung hat. Dabei sind zwei Tatsachen zu beachten:

252

Kai-Uwe Bletzinger, André Lähr

1. Bei den betrachteten kooperativen Aufgabenstellungen wirken verschiedene Teilmodelle in einem gemeinsamen Produktmodell zusammen. Typische Fragestellungen der Sensitivitätsanalyse sind dann z.B. die Frage nach den Antwortgrößen des einen Teilmodells infolge Änderungen der Eingangsgrößen eines anderen (z.B. wie ist die Auswirkung der Änderung des Stützenrasters auf die Gestaltung der Fassade, ihrer Dämmeigenschaften und Kosten zu beurteilen?). Es sind folglich zusätzlich übergeordnete Kooperationsmodelle notwendig, um die Konsistenz der beteiligten Teilmodelle zu gewährleisten. 2. Es kommen grundsätzlich alle denkbaren Parameter als Eingangs- oder Antwortgrößen in Frage, die in den beteiligten Teilmodellen definiert sind. Auch variieren Zusammensetzung und Art der Teilmodelle von Aufgabe zu Aufgabe sehr stark (z.B. kann eine Stützenabmessung Eingangsgröße einer statischen Berechnung aber auch Antwortgröße einer brandschutztechnischen Beurteilung sein). Daraus leitete sich eine Doppelstrategie als Ansatz zum Erreichen des Forschungsziels ab. Die Aufgabe wird aus Sicht von zwei Abstraktionsebenen bearbeitet. Abstraktionsebene eins betrachtet die grundsätzlichen Modellbezüge aus der Sicht des übergeordneten und interdisziplinären Kooperationsmodells („top down“). Sie analysiert Modelle und Interaktionen und definiert Schnittstellen und Kommunikationsmethoden. Realisiert wurde dies in Form einer agentenbasierten Kollaborationsumgebung. Abstraktionsebene zwei geht das Problem von unten an („bottom up“). Hier werden Teilaufgaben bei der Definition von Eingangs- und Antwortgrößen und des daraus folgenden Datenaustausches konsequent als austauschbare Softwarekomponenten definiert und umgesetzt. Für vorhandene Methoden und Softwaremodule sind Mechanismen für eine stecker-kompatible Austauschbarkeit entwickelt worden, um netzwerkübergreifend Sensitivitätsanalysen flexibel im Sinne eines Baukastensystems formulieren zu können. Beide Strategien werden gleichzeitig verfolgt, um jede Sicht möglichst vollständig zu gestalten. Hieraus entstand ein Analysetool, das einen Analysten dabei unterstützt, Modellparameter zu variieren und Systemantworten auszuwerten. Letztlich erfolgte die Integration dieses Analysetools in die agentenbasierte Kollaborationsumgebung.

2.2 Angewandte Methoden/Vorgehensweise Die zu entwickelnde Kollaborationsumgebung musste fähig sein, den Workflow und die Kommunikation (Semantik, Daten) zwischen den Planungsbeteiligten zu unterstützen. Außerdem wurde darauf Wert gelegt, diese Umgebung möglichst flexibel für unterschiedliche Szenarien einsetzen zu können. Es war nicht das Ziel den Planungsprozess als Ganzes zu modellieren, sondern auf bestimmte Planungssituationen mit ausgewählten Planern schnell und effektiv reagieren zu können. Die Kollaborationsumgebung stellt die Basis für Sensitivitätsanalysen dar. Erst dadurch wird es möglich einen Planungsvorgang mit Fachplanern aus unterschied-

Sensitivitätsanalyse netzwerkübergreifender Produkt- und Strukturmodelle

253

lichsten Gewerken zu modellieren. Eine Sensitivitätsanalyse kann anschließend durch Untersuchung von Ein- und Ausgangsparametern dieses Kooperationsmodells durchgeführt werden. 2.2.1 Entwurf und Implementierung eines Kooperationsmodells Die Heterogenität und die unterschiedlichen Ansprüche von Planungsbeteiligten erfordern eine konsequente Umsetzung von generischen Schnittstellen. Diesem muss insbesondere bei der Kommunikation und dem Datenmanagement Rechnung getragen werden. Agententechnologie Die Agententechnologie ist eine Methode um Netzwerkkommunikation auf einem sehr hohen Abstraktionsniveau durchzuführen. (Wooldridge u. Jennings 1994) definieren einen Softwareagenten als ein unabhängiges Programm, das in der Lage ist, seine Entscheidungen und sein Handeln, basierend auf der Wahrnehmung seiner Umwelt, bei der Verfolgung von Zielen selbständig zu kontrollieren. (Ferber 1999) hingegen zieht zur Definition eines Agenten seine Eigenschaften heran. Demnach ist ein Agent ein Programm, das alle oder einige der folgenden Eigenschaften besitzt: Autonomie, Kooperation, Kommunikation, Mobilität, Reaktivität, Pro-Aktivität und Lernfähigkeit. Entscheidungen basieren auf seiner Perzeption und tragen dazu bei sein Ziel zu erreichen. Weiterhin werden Agenten auf einer so genannten Agentenplattform erstellt und agieren dort. Diese kann auf mehrere Rechner (Container) verteilt sein und bietet Services an, um beispielsweise andere Agenten zu lokalisieren (Yellow Pages) oder den Lebenszyklus von Agenten zu regulieren (Agent Management System). Der Yellow Pages–Service bietet vielfältige Möglichkeiten nach Agenten zu suchen. Dies erfolgt üblicherweise über direkte Namensuche oder einer Agentenbeschreibung (z.B. angebotener Dienst). Agenten können, wie gesagt, auf so genannten Agentenplattformen existieren, sich dort „bewegen“ (Mobilität), können selbstständig auf äußere Reize reagieren, mit anderen Agenten kommunizieren und lernen (Bilek u. Hartmann 2002; Bilek 2003; Meißner et al. 2004). Eine Agentenplattform und die ihr zugehörigen Agenten werden als Agentensysteme bezeichnet. Bei der Zusammenfassung von Agentensystemen zu einem kooperativ ausgelegten Modell entsteht ein Multiagentensystem (MAS). Agenten besitzen des Weiteren die Fähigkeit auf fremde Agentenplattformen zu migrieren. Die dezentrale Struktur von Multiagentensystemen hat den Vorteil, dass Agenten für die Planung im Konstruktiven Ingenieurbau genau auf die Arbeitsplatzrechner und Server verteilt werden können, die auch in der Realität von den Planern genutzt werden. Die räumliche Verteilung von Agenten für die Planung kann somit den realen Planungsgegebenheiten entsprechend erfolgen. Die wesentlichen Eigenschaften eines Agenten (s. o.) werden durch so genannte Verhalten modelliert. Sie befähigen einen Agenten auf Reize aus seiner Umgebung entsprechend zu reagieren und Aktionen auszuführen.

254

Kai-Uwe Bletzinger, André Lähr

Die Konversation erfolgt auf der Basis eines von der FIPA1 spezifizierten Kommunikationsstandards, der Agentensprache ACL (Agent Communication Language). ACL wurde als gemeinsame Sprache für die Kommunikation und den Informationsaustausch zwischen Agenten entwickelt. ACL basiert auf der Sprechakttheorie (Austin 2002). Mögliche Sprechakte eines Agenten sind request, refuse und agree. Meistens kann ein Agent mehrere Ontologien entschlüsseln. Der Einsatz von Ontologien in diesem Kontext ist sinnvoll, da die Interpretation des Inhalts einer Nachricht von Agent zu Agent durchaus verschieden sein kann. Die Nachricht wird mit Hilfe einer Ontologie gewissermaßen interpretiert. Agentenplattformspezifikation JADE Das Framework zur Implementierung von Agentensystemen, das hier gewählt wurde, nennt sich JADE2. Die Programmiersprache ist Java, was zusätzlich zu einer Plattformunabhängigkeit beiträgt. JADE bietet bereits Basisagentenklassen, die nach eigenem Ermessen erweitert werden können. Bereits vorhandene Funktionalitäten sind Lebenszyklusüberwachung, Nachrichtenverwaltung und das Verhalten. Ebenso werden verschiedene Basiskommunikationsprotokolle (z.B. Achieve Rational Effect, FIPA-Contract-Net usw.) vorgehalten, welche sich bei Bedarf erweitern und einem Agenten als Verhalten zuordnen lassen. Letztere wiederum steuern die Aktionen eines Agenten und sind in JADE beispielsweise durch folgende Basisklassen wie z.B. OneShotBehaviour, CyclicBehaviour oder TickerBehaviour vertreten. Fachplanerintegration Für die Integration der Planungsbeteiligten (oder Fachplaner) wurde ein Proxyagent (PA) implementiert. Er vertritt gewissermaßen den Fachplaner, bzw. die Fachplanersoftware innerhalb der Kollaborationsumgebung. Der PA kann auf die entsprechende lokale Arbeitsumgebung des Fachplaners angepasst werden und ist in der Lage, die Fachplanerapplikation mit Daten zu versorgen und zu steuern. Er verfügt über einen Satz von generischen Kommandos wie z.B. receiveModel, processModel oder sendResults. Andererseits ist er als Softwareagent in der Lage aufgrund der Verbindung zur Kollaborationsumgebung mit anderen Agenten zu kommunizieren. Die Funktionalität proprietäre Software zu kapseln und deren Funktionalität verfügbar zu machen nennt man auch Softwarewrapping. Ein PA ist nicht mobil, d. h. er existiert nur in dem Container, in dem er erzeugt wurde. Da er letztendlich auch die Netzwerkschnittstelle für die Fachplanerapplikation repräsentiert, wäre es nicht sinnvoll Mobilität zu implementieren. Er ist sozusagen ein statischer Dienstleister und verständigt sich über ACL-Nachrichten mit anderen Agenten. In Abb. 2.1 ist ein Beispielszenario dargestellt, welches das Integrationsprinzip der Fachdomänen Statik, Kalkulation und Klimatechnik verdeutlicht. Das zentrale 1 2

FIPA - Foundation for Intelligent Physical Agents (http://www.fipa.org) JADE - Java Agent Development Environment (http://jade.tilab.com)

Sensitivitätsanalyse netzwerkübergreifender Produkt- und Strukturmodelle

255

Rechteck (strichliert) kennzeichnet eine Agentenplattform und die punktiertstrichlierte Ausführung repräsentiert die Container mit den Fachplanerapplikationen.

Abb. 2.1. Integrationsmechanismus mit Proxyagenten

Workflowmanagement Typischerweise ist die Komplexität eines Planungsprozesses im Konstruktiven Ingenieurbau enorm. Wie bereits erwähnt, besteht für dieses Projekt nicht der Anspruch diesen Planungsprozess in seiner Gesamtheit zu modellieren, sondern Planungsszenarien mit ausgewählten Planungsbeteiligten zu simulieren. Dennoch oder gerade aufgrund der dadurch notwendigen Flexibilität im Bezug auf das Workflowmanagement, wurde im zu Grunde liegenden Projekt eine dynamische, ereignisbasierte Ablaufsteuerung entwickelt. Es wurde ein zentraler Workflowmanager (Agent) entwickelt, der über jedes Ereignis (Event) in der Kollaborationsumgebung informiert wird. Events sind beispielsweise der Abschluss einer Berechnung eines Planers oder eine Änderung im Datenmodell, die sich allerdings auch auf gewisse Teilbereiche beschränken kann. Das Event, das die Änderung des Datenmodells signalisiert, enthält auch Informationen über den Teilbereich des Datenmodells, das geändert wurde. Es ist also möglich Änderungen zu erkennen, die sich nur auf bestimmte Objektmengen, wie z.B. Wände oder auch einzelne Objekte, über eine GUID (Globally Unique Identifier) auswirken. Die Granularität der Informationen ist vom verwendeten Datenmodell bzw. vom eingesetzten Datenmodellmanagement abhängig. Es muss entsprechend möglich sein, solche Teilbereiche (Wände, Stützen usw.) zu identifizieren.

256

Kai-Uwe Bletzinger, André Lähr

Der Workflowmanager ist ein nicht mobiler Agent. Er stellt eine zentrale Informationsinstitution dar und verhält sich passiv, d. h. es gibt keine festgelegte Ablaufsteuerung. Er macht lediglich Informationen über ablaufende oder abgelaufene Vorgänge (Events) innerhalb des Szenarios verfügbar. Aufgenommen und verarbeitet werden diese Informationen von einer weiteren Klasse von Agenten, den Monitoragenten (MA). Diese unterstehen jeweils einem Proxyagenten, der beliebig viele MA erzeugen kann. MA sind mobile Agenten, die nach Erstellung auf den Container des PA migrieren und sich bei dem Workflowmanager registrieren. Die Mobilität der MA ist aufgrund von potentiellen Verbindungsabbrüchen notwendig. Planungsbeteiligte sind evtl. nur zu bestimmten Zeiten verfügbar oder die Netzwerkverbindung bricht ab. In diesem Fall warten die Monitoragenten auf die Rückkehr ihres PA und nehmen den Kontakt wieder auf. Folglich können die PA auch nach einer Abwesenheit Nachricht über abgelaufene Vorgänge (Events) erhalten. Die Eventverarbeitung der MA funktioniert auf der Basis von Filtern. Prinzipiell erfasst jeder beim Workflowmanager registrierte MA alle dort eingehenden Events. Spezifische Filter veranlassen einen MA auf bestimmte Events zu reagieren. Die Filter werden den MA bei ihrer Erstellung vom PA zugewiesen. Es existiert augenblicklich eine Auswahl von Filtern, die auf die vorhandenen Events passt. Vorhanden ist beispielsweise der Filter ModelChangedFilter, der das Event ModelChanged auffängt. Entsprechend ist auch die oben beschriebene feinere Differenzierung von ModelChanged, also evtl. bestimmte Objektmengen (Wände, Türen usw.), oder ObjectChanged möglich. Abbildung 2.2. zeigt den Informationsfluss und die Verbindungen der beteiligten Agenten. Die Events und die Filter sind auf der Basis der objektorientierten Programmierung erweiterbar und somit höchst flexibel.

Abb. 2.2. Workflowmanagement bei eingehendem Event

Sensitivitätsanalyse netzwerkübergreifender Produkt- und Strukturmodelle

257

Diese Art des Workflowmanagements birgt natürlich gewisse Risiken, wie z.B. Deadlocks. Sind beispielsweise zwei Fachplaner an der Änderung des gleichen Objekts interessiert, stellt sich zunächst die Frage der Priorität. Außerdem nehmen beide Fachplaner bei ihrer Bearbeitung wiederum Änderungen an dem Objekt vor. Letzteres führt unweigerlich dazu, dass der jeweils andere Fachplaner erneut über eine Änderung des Objekts informiert wird. Um diesem Problem entgegenzutreten wurde ein Zertifizierungsmechanismus entwickelt, der die Aktionen der Fachplaner reguliert. Bevor also ein PA eine Aktion durchführen kann, muss diese zunächst zertifiziert werden. Dazu stellt er eine Anfrage an den Workflowmanager, der entscheidet ob

x der entsprechende PA befugt ist diese Aktion durchzuführen, x ein Deadlock vorliegt oder x der entsprechende PA gemäß seiner Prioritätseinstufung zu diesem Zeitpunkt berechtigt ist, die Aktion durchzuführen. Prioritäten sind eigentlich nur dann interessant, wenn die Software der Planungsbeteiligten in der Lage ist, nach ihrer Bearbeitung, ein verändertes Modell auf der Basis des verwendeten Austauschformats zurückzuschreiben. Die Erprobung, die während dieser Forschungsarbeit durchgeführt wurde, beschränkt sich jedoch darauf, dass die Fachplaner nur Leserechte haben. Der Grund dafür ist, dass die verfügbaren Fachplanerapplikationen das verwendete Datenmodell IFC zwar lesen, jedoch nicht konsistent zurückschreiben können. Im Zuge der immer weiter fortschreitenden Entwicklung solcher Produktmodelle, insbesondere der IFC, sind wir jedoch zuversichtlich, dass dieses Problem in nächster Zeit gelöst sein wird und eine Anwendung in der hier vorgestellten Kollaborationsumgebung finden kann. Produktdatenmanagement Die verfügbare Datenvielfalt und die Granularität hängen ganz wesentlich von der Definition des Produktmodells ab. Aufgrund der sehr aktiven Entwicklung der IFC3 wurden diese zunächst als Datenmodellstandard in die Kollaborationsumgebung implementiert. Dabei wurde Wert darauf gelegt, auch andere Datenmodelldefinitionen integrieren zu können und eine entsprechende Schnittstelle, den Produktmodellagenten, einzuführen. Im Wesentlichen greifen wir dabei die Idee aus (Beitrag II.4, Katzenbach/Rüppel; Beitrag V.3, Hartmann) auf. Somit ist ein Produktmodellagent, wie auch der Proxyagent, ein so genannter Wrapperagent. Er kapselt also die Funktionalität des Datenzugriffs und -managements und stellt diese über eine generische Schnittstelle zur Verfügung. Bei den IFC besteht das Problem, dass sich damit nicht alle Daten standardisiert modellieren lassen. Allerdings stellen sie einen Mechanismus (Property Sets) zur Verfügung, um zusätzlich individuelle Daten zu integrieren.

3

IFC - Industry Foundation Classes

258

Kai-Uwe Bletzinger, André Lähr

Im zu Grunde liegenden Projekt wurden diese Property Sets genutzt, um das IFC Modell um (noch) nicht vorhandene Datenstrukturen zu erweitern. Dabei sind grundsätzlich zwei verschiedene Datenmodellierungen zu unterscheiden. Einerseits ist es notwendig fachdomänenspezifische Daten (z.B. Berechnungsergebnisse) mit Bezug auf das allgemeine Datenmodell zu organisieren und andererseits muss der Standard um bestimmte Aspekte, die er (noch) nicht abdeckt, ergänzt werden. Gelöst wurde das Problem durch Trennung des Gesamtdatenmodells in einen gemeinsamen (CSPM, common shared product data) und jeweils einen domänenspezifischen (DDD, dedicated domain data) Teil. Letzterer muss für jede Fachdomäne spezifiziert werden, die Verwendung ist jedoch optional. Die domänenspezifischen Daten werden als IFCPropertySets definiert, die über eine GUID (globally unique identifier) an das entsprechende Objekt im CSPM gebunden werden können. So lassen sich beispielsweise Spannungen einer Stütze zuordnen. Wie oben bereits erwähnt, übernimmt der implementierte Produktmodellagent die Aufgabe, die entsprechend zertifizierten Anfragen der Proxyagenten zu bearbeiten und somit Daten aus CSPM als auch dem zugehörigen DDD zur Verfügung zu stellen.

Abb. 2.3. Umsetzung der geteilten Datenverwaltung

2.2.2 Entwurf und Umsetzung eines Analysetools Wie anfangs bereits erwähnt ist die Anzahl der möglichen Optionen (Varianten) für einen Fachplaner, die er im komplexen und multidisziplinären Kontext wie dem Planungsprozess im Konstruktiven Ingenieurbau hat, nahezu unüberschaubar. Dieser Kontext lässt sich durch die vorangehende Darstellung der Kollaborationsumgebung in ein System oder Modell überführen. Optionen können dann als System- oder Modellparameterkombinationen definiert werden. Beispiele für solche Parameter sind Stützenbreite, Fensterhöhe, Wanddicke usw.

Sensitivitätsanalyse netzwerkübergreifender Produkt- und Strukturmodelle

259

Das Ziel ist es, einem Analysten ein Werkzeug zur Verfügung zu stellen, mit dem er Varianten definieren und diese bewerten kann. Dazu werden Methoden aus dem Feld der Sensitivitätsanalyse, Design of Experiments und Antwortflächenmethoden herangezogen. Sensitivitätsanalyse Typischerweise behandelt die Sensitivitätsanalyse die Frage, wie sich Systemantworten verhalten, wenn die Eingangsgrößen des gleichen Systems variiert werden. Grundsätzlich ist eine Sensitivitätsanalyse sehr nützlich, wenn man über Ersatzmodelle für reale Systeme oder Prozesse verfügt. (Saltelli et al. 2000) beschreiben die Sensitivitätsanalyse als Grundlage der Modellierung. Insbesondere werden die so genannten Screeningmethoden in lokale und globale unterschieden. Sie werden dazu benutzt, um signifikante Systemparameter zu ermitteln. Die einfachste Methode ist die one-at-a-time (OAT) Methode. Hierbei wird jeweils nur ein Parameter variiert und alle anderen bleiben konstant, während die Systemantworten beobachtet werden. Konsequenterweise ist der Nachteil dabei der, dass Parameterinteraktionen vernachlässigt werden. Lokale Sensitivitäten eines Systems sind am einfachsten als partielle Ableitungen im Bezug auf die Eingabeparameter zu erklären. Das System muss in analytischer Form beschreibbar sein, um die Sensitivitäten direkt davon ableiten zu können. Andernfalls existieren Methoden wie die Finite-Differenzen-Methode, um die Steigungen der Systemantwort zu ermitteln. Betrachtet man reale Systeme, wird man oft mit so genannten Störgrößen konfrontiert. Dabei handelt es sich um Unsicherheiten, wie z.B. Messfehler, Rundungsfehler usw., die nicht kontrolliert werden können. Aus diesem Grund werden globale Methoden der Sensitivitätsanalyse angewendet, um die Gesamtheit der Eingangsgrößen abzudecken. Das Ziel bleibt gleich, nämlich die Systemänderung bei Variation der Eingangsgrößen zu untersuchen. Die Ziele einer Sensitivitätsanalyse sind:

x Identifikation essentieller Eingangsparameter, die die Systemantwort maßgebend beeinflussen.

x Eliminierung von Eingabeparametern, die kaum Einfluss auf die Systemantwort haben.

x Regionen des Entwurfraumes (Gesamtheit aller Eingabeparameterkonfigurationen) zu identifizieren, in denen sich das System im Bezug auf bestimmte Eingabeparameter kritisch verhält. Im Kontext des vorliegenden Projekts existiert keine analytische Beschreibung für das System. Aus diesem Grund lassen sich die Sensitivitäten auch nicht direkt als partielle Ableitungen bestimmen. Meistens ist nicht einmal bekannt wie sich die Parameter gegenseitig beeinflussen. Die Analyse dieser Beziehungen ist das Hauptziel der Sensitivitätsanalyse in diesem Rahmen. Normalerweise sind nur diskrete Punkte im Entwurfsraum bekannt. Daher wird die Sensitivitätsanalyse bei einem Ersatzmodell angewandt, das aus diesen diskreten Punkten erstellt wird. Es ist offensichtlich, dass die Anzahl dieser bekannten, diskreten Punkte wesentli-

260

Kai-Uwe Bletzinger, André Lähr

chen Einfluss auf die Qualität des Ersatzmodells und somit der gesamten Analyse hat. Ersatzmodelle, Antwortflächen Im Konstruktiven Ingenieurbau ist die Aufgabe eines Fachplaners oftmals sehr zeit- und kostenintensiv, besonders wenn man bedenkt, dass er in Anbetracht einer Vielzahl von Planungsvarianten stets versucht, die beste Option zu finden. Um diesen Aufwand zu reduzieren werden Ersatzmodelle erstellt, die es erlauben auf möglichst viele der sonst notwendigen Versuche zu verzichten. Man erhält dadurch zwar „nur“ eine Approximation der realen Auswertungen, aber häufig ist eine rein qualitative Tendenz oder ein Trend hinreichend für eine Entscheidung. Eine Möglichkeit ein Ersatzmodell abzuleiten, stellt die von (Sacks et al. 1989) entwickelte Kriging-Methode dar. Es handelt sich dabei um ein statistisches Approximationsverfahren mit einem interpolativen Charakter. Als besonders sinnvoll stellt sich die Anwendung dieser Methode heraus, wenn man bereits globale Trends des zu untersuchenden Modells (Systems) kennt. Ein weiterer Vorteil dieser Methode ist die Tatsache, dass bei der Erstellung des Ersatzmodells auch direkt die partiellen Ableitungen (Sensitivitäten) zur Verfügung stehen. Einen anderen Weg aus diskreten Stützstellen eine funktionale Beschreibung zu erhalten, stellen Antwortflächenmethoden dar, wie z.B. lineare oder quadratische Regressionsanalysen, die relativ häufig eingesetzt werden. Im vorliegenden Projekt stellte sich die Kriging-Methode als äußerst praktikabel heraus, vor allem, da sie garantiert, zumindest die eingangs vorgegebenen Stützstellen exakt darzustellen. Design of Experiments (DOE) DOE ist eigentlich eine Methode um Versuchspunkte für statistische Experimente zu ermitteln. Um eine zuverlässige Aussage aufgrund eines auf statistischem Wege erzeugten Modells zu machen, muss eine genügend hohe Anzahl von Versuchspunkten vorliegen. Diese Anzahl kann durch Anwendung von so genannten Versuchsplänen, z.B. voll faktoriell, fraktioniert faktoriell, Latin Hypercube sampling usw. gesteuert, bzw. reduziert werden (Taguchi 1986; Box u. Draper 1987). Strategien zur Erkundung des Versuchsraumes Ein Planer hat in einer multidisziplinären Umgebung nur selten das komplette fachübergreifende Wissen, das nötig wäre, um alle Zusammenhänge zu erkennen. Entsprechend verhält es sich beim Durchführen einer hier vorgestellten Analyse. Ausgehend davon, dass der Analyst ein eher geringes Wissen von den an der Planung beteiligten Fachdomänen hat, kann er nicht abschätzen, welche Auswirkung eine von ihm getätigte Änderung am System auf das Gesamtsystem hat. Es stellt sich also die Frage, an welcher Stelle und mit welcher Intensität man beginnen muss, um den gewünschten Effekt zu erzielen. Im Folgenden werden 3 Strategien

Sensitivitätsanalyse netzwerkübergreifender Produkt- und Strukturmodelle

261

vorgestellt, die er optional verfolgen kann. Alle werden am Beispiel eines zweidimensionalen Versuchsraums (Eingangsgrößen x1, x2) vorgestellt, über dem als dritte Dimension die Systemantwort Y dargestellt ist. Trial and Error Strategie Der Analyst beginnt bei einer bestimmten Systemkonfiguration, die ihm sinnvoll erscheint (Abb. 2.4 a). Nach einer Systemberechung erhält er ein Ergebnis (Abb. 2.4 b). Nach seiner Einschätzung oder aus Willkür wählt er eine andere Parameterkombination und gelangt nach einer erneuten Systemberechnung zu einer weiteren Stützstelle (Abb. 2.4 c). Ein Vergleich beider Resultate, z.B. mit der FiniteDifferenzen-Methode, lässt sich nun feststellen wie sich die Antwort verändert hat und welchen Beitrag die verschiedenen Eingangsparameter darauf haben. Mit diesen Informationen lässt sich entweder manuell oder durch Extrapolation eine weitere potentiell interessante Stützstelle finden (Abb. 2.4 d/e). Er kann entscheiden seine Untersuchungen zu beenden, sobald er zufrieden stellende Analyseergebnisse gesammelt hat. Y

Y

Y

a)

x2

x2

x2

x1

b)

Y

Y

x1

c)

x2

x2

x1

d)

x1

e)

x1

Abb. 2.4. Verlauf der Trial and Error Strategie

Vorteile:

x Direkte Kontrolle der auszuwertenden Versuchspunkte x Erfahrung des Analysten kann eingebracht werden Nachteile:

x Interpretation eines mehrdimensionalen Versuchsraumes wird schell unübersichtlich und manuell nicht zu bewältigen

x Es sind sehr viele Benutzereingriffe notwendig, was sehr hohen Zeit- und somit Kostenaufwand bedeutet. DOE Strategie Mit Hilfe von DOE wird je nach gewähltem Versuchsplan eine bestimmte Anzahl (Abb. 2.5 b) von Designs bestimmt. Zu jedem Design wird die entsprechende Antwort durch eine Systemauswertung ermittelt (Abb. 2.5 c). Daraus wird anschließend mittels Kriging ein Ersatzmodell erstellt (Abb. 2.5 d), das als Basis für weitere Analysen dient.

262

Kai-Uwe Bletzinger, André Lähr

Abb. 2.5. Verlauf der DOE Strategie

Vorteile:

x Automatische Ermittlung eine Systemverhaltens in einer bestimmten Region des Versuchsraums

x Kaum Benutzerinteraktionen während der Analyse ĺ Zeit- und Kostenersparnis Nachteile:

x Interpretation eines mehrdimensionalen Versuchsraumes ist wiederum schell unübersichtlich und manuell nicht zu bewältigen x Es sind keine Benutzereingriffe möglich. Dies kann zu sehr vielen potentiell irrelevanten Designs führen und somit zu einer starken Zunahme der Gesamtberechnungszeit. Hybride DOE gestützte interaktive Strategie Diese Methode vereint beide vorangehenden Ansätze. Der Analyst beginnt zunächst mit einem bestimmten Design und lässt sich nach und nach DOE basiert weitere Designs vorschlagen. Dabei wird er dahingehend unterstützt, dass er mit einer möglichst geringen Anzahl von Versuchen zu einem Analyseergebnis kommt. Zugleich kann er durch seine Erfahrung bereits einige Designs ausschließen. Abschließend kann wiederum ein Ersatzmodell als Basis für eine Sensitivitätsanalyse erstellt werden. Der Verlauf erfolgt gemäß (Abb. 2.6).

Abb. 2.6. Verlauf der hybriden DOE-interaktiven Strategie

Sensitivitätsanalyse netzwerkübergreifender Produkt- und Strukturmodelle

263

Bewertungsmethoden Eine Antwort eines Systems im oben geschilderten Kontext setzt sich aus einem oder mehreren Antwortparametern zusammen. Es stellt sich nun die Frage, auf welcher Basis sich eine Entscheidung bezüglich der „besseren“ Variante treffen lässt. Dazu wird ein Qualitätsmaßstab definiert, der individuell (abhängig vom Analysten) definiert werden kann. Die einzelnen Parameter müssen zunächst auf bestimmte Kriterien hin bewertet werden. Umgesetzt wurde dies mit der Einführung von Preference Functions (Präferenzfunktionen oder kurz PF), die die Antwortparameter in Abhängigkeit eines Kriteriums in einen dimensionslosen Skalar überführt. Anschließend sind die bewerteten Antwortparameter vergleichbar und können als Gesamtheit bewertet werden. PF sind auf Antwortparameter angewandte Operatoren. Im Folgenden werden einige Klassen von PFs aufgeführt, mit denen sich grundlegende Bewertungsvorgänge durchführen lassen. 1

fp

1

fp

1

0.8

0.8

0.8

0.6

0.6

0.6

0.4

0.4

0.4

0.2

0.2

0.2

y a)

ymax

ymin

y

ymax

b)

0

fp

yopt

y

c)

Abb. 2.7. 3 Klassen von Präferenzfunktionen

x einfach beschränkt (one sided boundary class, OBC), (s. Abb. 2.7 a) fp

e a ( y b )

(2.1)

x doppelt beschränkt (two sided boundary class, TBC), (s. Abb. 2.7 b) e a (  y b )  e c ( y d )

fp

(2.2)

x optimal (optimal value class, OVC) , (s. Abb. 2.7 c) fp

ay 2  by  c

(2.3)

Die Konfigurationsparameter (a,b,c,d) sind abhängig von den vom Benutzer spezifizierten Informationen (Gültigkeitsbereich, Grenzen, Optima usw.). Diese Klassen lassen sich prinzipiell beliebig erweitern (z.B. digitale PF) und können sehr leicht in das Framework eingebunden werden. Allgemein gilt, dass PFs Antwortparameter in einen “Qualitätsverlustwert” transformieren, wobei niedrige Werte eine hohe Qualität und hohe Werte entsprechend schlechte Qualität bedeuten. Abschließend kann eine Wichtung der Qualitätsverlustwerte für eine Planungsvariante i erfolgen:

264

Kai-Uwe Bletzinger, André Lähr

m

Qi ( X i )

¦ g i f p k ( yk ( X i ))

(2.4)

k 1

Gl. 2.4 formuliert einen allgemeinen Ausdruck für einen gewichteten Qualitätsverlustwert Q aus verschiedenen Antwortparametern yk. Der Index k läuft von 1 bis zur Anzahl der Antwortparameter m. Trendanalyse Im Folgenden bezeichnet der Terminus Trendanalyse die Untersuchung des bewerteten Versuchsraums, also mehreren Systemauswertungen unterschiedlicher Varianten. Die Analyse erfolgt am n-dimensionalen Versuchsraum, wobei n für die Anzahl der Eingabeparameter steht. Folgende Erläuterungen finden aus Gründen der Darstellung an einem zweidimensionalen Versuchsraum (Eingabeparameter x1, x2) statt, über dem der Qualitätsverlust Q abgebildet wird.

Abb. 2.8. Qualitätsverlust Q über den Eingabeparametern x1 und x2

Abbildung 2.10. zeigt ein durch Kriging ermitteltes Ersatzmodell für den Qualitätsverlust Q. Es setzt sich aus den Qualitätsverlustwerten der einzelnen Systemantwortparameter zusammen. Wie oben bereits beschrieben, stellen niedrige Werte eine zu bevorzugende Lösung dar. Auf diese Weise gewinnt der Analyst eine Übersicht über den gesamten Versuchsraum. Der Vorteil am angenäherten Ersatzmodell ist, dass er auch für nicht getestete Systemkonfigurationen Approximationen des Qualitätsverlustes erhält. Es obliegt ihm auf dieser Basis zu entschei-

Sensitivitätsanalyse netzwerkübergreifender Produkt- und Strukturmodelle

265

den, ob bestimmte Bereiche des Versuchsraumes genauer untersucht werden müssen. Gerade bei Versuchsräumen höherer Dimension, bei der solche Darstellungen nicht mehr möglich sind, ist es nützlich Sensitivitäten zur Beurteilung heranzuziehen. Die partiellen Ableitungen des Qualitätsverlusts nach den Eingabeparametern geben darüber Aufschluss, wie stark der Einfluss des jeweiligen Parameters an der aktuellen Stelle im Versuchsraum ist.

Abb. 2.9. Sensitivitäten wQ/wx1 and wQ/wx2

Weitere interessante Beobachtungen an den Sensitivitäten sind einerseits die Nullstellen, die bekanntlich Extremwerte bezüglich des untersuchten Parameters darstellen. Andererseits lässt sich ein Gebiet mit betragsmäßig geringen Sensitivitätswerten als besonders robustes Design im Bezug auf diesen Parameter identifizieren. Beispiel Abschließend soll ein Beispiel die Anwendung der oben beschriebenen Methoden verdeutlichen. Im Rahmen der AG Verteilte Simulation des SPP1103 wurde ein Referenzobjekt bestimmt, an dem die erarbeiteten Methoden der AG Anwendung finden sollten. Unter anderem wurde ein kooperatives Szenario erstellt, das die Methoden der einzelnen Teilprojekte verknüpfen soll. Im Wesentlichen wurde die Interaktion von Klimatechnik und Statik untersucht. Der Lehrstuhl für Bauinformatik der TU München (Beitrag IV.4, Rank) repräsentierte die Anwendung einer 3D-Strukturanalyse und das Institut für Computeranwendungen im Bauwesen (Beitrag IV.3, Krafczyk) stellte seine Methoden der Strömungssimulation zur Verfügung. In Abb. 2.10 ist der Grundriss eines mehrstöckigen Bürogebäudes dargestellt. Die Fragestellung ist, inwiefern der Abstand beider Gebäudekerne einen Einfluss auf (a) das Raumklima an verschiedenen Punkten dieses Stockwerks und auf (b) die maximale Durchsenkung der Bodenplatte hat. Außerdem soll die Analyse eine Entscheidung des Analysten unterstützen, indem Antwortparameterkriterien (maximale Durchsenkung, optimales Raumklima) definiert werden.

266

Kai-Uwe Bletzinger, André Lähr

2 d 3

1

5

4

Abb. 2.10. Grundriss mit variablem Gebäudekernabstand und verschiedenen Klimamesspunkten

Zuerst werden n verschiedene Eingabeparameterkombinationen (Systemkonfigurationen) festgelegt. Die Eingabeparameter X i wurden laut Aufgabestellung als xi1 für den Gebäudekernabstand und xi2 für die Lage des Messpunkts gewählt, Xi

>xi1 , xi 2 , ..., xik , ..., xim @, i

1..n, k

1..m

(2.5)

wobei m die Anzahl der Eingabeparameter darstellt (hier 2) und der Laufindex i die Planungsvariante kennzeichnet. Jede Systemauswertung erfordert jeweils den Beitrag beider beteiligter Fachplaner (Struktur- und Strömungsanalyse). Es werden jeweils die Antwortparameter yi1 für die maximale Durchsenkung der Deckenplatte, yi2 für die Lufttemperatur und yi3 für die Luftgeschwindigkeit berechnet. Die Antwortparameter werden mit Hilfe verschiedener Klassen von Präferenzfunktionen bewertet. Abbildung 2.11 zeigt die Präferenzfunktionen für die drei Antwortparameter. Die Durchsenkung y1 wurde durch eine OBC, also eine einfach beschränkte PF, modelliert (links). Der Grenzwert liegt bei 1,5 cm. Die gleiche Klasse wurde für die Luftgeschwindigkeit gewählt, wobei der Grenzwert bei 0,4 m/s liegt (rechts). Es ist deutlich zu erkennen, dass die Steigung der PF im Bereich des Grenzwerts geringer ist. Dies lässt sich durch geeignete Wahl der Parameter der OBC bestimmen. Der Grund für diese Wahl ist, dass auch noch eine leichte

Sensitivitätsanalyse netzwerkübergreifender Produkt- und Strukturmodelle

267

Abweichung auf die tolerierte Seite der Luftgeschwindigkeitsgrenze als relativ unbehaglich empfunden und deshalb schlechter bewertet wird. Die Lufttemperatur lässt sich am Besten als OVC modellieren, da sie typischerweise einen Optimalwert für Behaglichkeitsuntersuchungen besitzt (Mitte). In dem vorliegenden Beispiel wurde dieser Wert zu 18 °C gesetzt. 1

fp

1

fp

1

0.8

0.8

0.8

0.6

0.6

0.6

0.4

0.4

0.4

0.2

0.2

0

0.2 0.4 0.6 0.8

y1[cm]

1

1.2 1.4

y1,max

0 16

0.2

y2,opt 17

18

y2[°C]

fp

19

20

0

0.1

0.2

0.3

0.4

y3,max

y3[m/s]

Abb. 2.11. Gewählte Präferenzfunktionen

Die bewerteten Antworten werden nun gewichtet (gi) und aufsummiert. Die Wichtungsparameter sind frei wählbar und dienen unter anderem auch dazu, einzelne Parameter für die Analyse auszublenden. Somit lässt sich der Qualitätsverlustwert einer Systemkonfiguration durch Gl. 2.4 beschreiben. Im nächsten Schritt wird das diskrete Modell mittels Kriging in ein stetiges Ersatzmodell überführt, welches in Abb. 2.12 dargestellt ist.

Abb. 2.12. Qualitätsverlust über Gebäudekernabstand d und Messpunkt p

268

Kai-Uwe Bletzinger, André Lähr

Allgemein lassen sich bevorzugte Bereiche bekanntlich dadurch beschreiben, dass das Modell niedrige Qualitätsverlustwerte liefert. Konkret für dieses Beispiel lassen folgende Beobachtungen machen:

x Ein globaler Trend zeigt sich bei anwachsendem Kernabstand d. Für die gewählte Qualitätsbeschreibung bedeutet steigendes d ein Abnehmen der Qualität.

x Es sind starke Qualitätsunterschiede an den unterschiedlichen Messpunkten zu beobachten. Diese Charakteristik stellt sich als ungünstig heraus, um beispielsweise das gesamte Stockwerk als Bürofläche zu nutzen. Weitere Informationen gewinnt man mit Hilfe der Betrachtung von Sensitivitäten (Abb. 2.13). Die linke Seite zeigt die Sensitivität von d. An der Stelle p=1 und d=8 ist ein hoher Sensitivitätswert zu erkennen, der darauf hinweist, dass sich das Modell an dieser Stelle bei einer Änderung von d äußerst sensibel verhält.

Abb. 2.13. Sensitivitäten von d und p

Abb. 2.14. Qualitätsverlust ohne den Einfluss (links) und ausschließlich unter der Luftgeschwindigkeit (rechts)

Abschließend wurde aufgrund der starken Qualitätsschwankungen an den unterschiedlichen Messpunkten in der Etage eine Analyse angestellt, um hinsichtlich einer Nutzung als Großraumbüro möglichst gleichmäßige Qualitätsverhältnisse zu

Sensitivitätsanalyse netzwerkübergreifender Produkt- und Strukturmodelle

269

erhalten. Es zeigte sich, dass die Qualitätsunterschiede maßgeblich von einer Zugluftsituation an der Position 3 geprägt sind. Besonders interessant ist dabei der zusätzliche Qualitätsverlust mit geringer werdendem Kernabstand, der offensichtlich diese Zugluftsituation verstärkt. Das Ergebnis dieser Analyse ist demnach den Kernabstand möglichst gering zu halten und außerdem Maßnahmen gegen die Zugluftsituation an Pos. 3 zu treffen.

2.3 Ergebnisse und ihre Bedeutung für das SPP1103 Dieser Abschnitt dient dazu die erreichten Ergebnisse zu den Zielen des SPP1103 zuzuordnen. Dies erfolgt unter Bezugnahme auf bereits oben beschriebenen Aspekte des zu Grunde liegenden Projekts. 2.3.1 Beitrag zu den Zielen des SPP1103 Neukonzeption der Kommunikation hinsichtlich der Kooperationsinhalte und -formen aus Sicht der Projektbeteiligten Die Natur des Konstruktiven Ingenieurbaus erfordert eine Vielfalt von Kommunikationsarten und -inhalten. Augenblicklich werden eher klassische Methoden wie postalischer Schriftverkehr, Telefon, persönliche Vorsprachen von modernen Arten wie Email, Videokonferenz und Mobilfunk ergänzt. Neue Kommunikationsformen (zentrale Projektserver oder Plattformen) hingegen sind eher selten bis nicht vorhanden. Projekte wie z.B. Plattformen haben gute Ansätze gezeigt. Jedoch scheitern die Ansätze nicht zuletzt daran, dass der Anspruch an Flexibilität im Kontext des Konstruktiven Ingenieurbaus und der Organisationsaufwand enorm ist. Einerseits erfordert das breit gefächerte Spektrum an Gewerken und Disziplinen eine Vielzahl von verschiedenen Kommunikationsformen und abläufen, andererseits sind Einarbeitung in solche Systeme, Umstellungen der unternehmensinternen Arbeitsprozesse und adäquate Schnittstellen zu bewährter proprietärer Software, ein Aufwand, der diese Ansätze bremste. In dieser Hinsicht liefert das hier zu Grunde liegende Projekt einen offenen und flexiblen Ansatz in Form einer agentenbasierten Kollaborationsumgebung. In den Arbeiten (Khedro u. Genereth 1993; Grabowski u. Schreiner 1995; Peine 1998; Strasser u. Rothermel 1998) wurde das Potenzial der agentenbasierten Kollaboration bereits aufgezeigt. Allerdings fehlt dort noch die Modellierung der Wirkungszusammenhänge von Prozessen des Konstruktiven Ingenieurbaus im Informationsverbund. Im hier dargestellten Ansatz wurden die Akteure in einer Planungsphase auf Agenten abgebildet. Unterschiedliche Kommunikationsformen und -arten wurden mittels folgender oben beschriebener Methoden umgesetzt:

x Ereignis-/Filterbasiertes Workflowmanagement x Verhaltensmuster x Ontologie

270

Kai-Uwe Bletzinger, André Lähr

Entwicklung neuer Verfahren und Methoden zur Interaktion und Verwaltung der im Konstruktiven Ingenieurbau einsetzbaren Fachsoftware und Fachmodelle für die vernetzt-kooperativen Planungsprozesse Proprietäre Fachsoftware hat sich im Bereich des Konstruktiven Ingenieurbaus meist schon über längere Zeit etabliert. Neue Interaktionsformen (Datenaustausch, Prozesskommunikation) sind schwer anzubinden, da der Zugriff auf den Quellcode fehlt. Softwarewrapping stellt im Prinzip die einzige Möglichkeit dar, proprietäre Software in andere Softwareumgebungen zu integrieren. Diese Technik wurde im SPP1103 bei mehreren Projekten angewandt. Insbesondere die Projekte aus der Arbeitsgruppe Agententechnologie und der hier vorgestellte Ansatz setzen dies in Form von „Wrapperagenten“ um (Beitrag II.4, Katzenbach/Rüppel; Beitrag V.3, Hartmann). Als ein enorm wichtiger Aspekt hat sich die Datenmodellierung herausgestellt. Die IFC haben sich dabei mangels wirklicher Alternativen als beste Datenbeschreibung für interdisziplinären Austausch geeignet. Bislang vorwiegend zum Austausch von Geometriedaten (z.B. ADT4, ArchiCAD5 usw.) verwendet, werden sie nun mehr und mehr auch für weitere Produktdaten eingesetzt (Romberg et al. 2003; Wassouf et al. 2006). Die IFC sind jedoch nicht dafür vorgesehen grundsätzlich alle Daten im Kontext einer Planungsphase aufzunehmen. Dafür bieten sie den so genannten „Property Set“-Mechanismus. Dieser erlaubt eine beliebige Erweiterung der vorhandenen Produktdatenbeschreibung. 2.3.2 Beitrag zu den Zielen der Arbeitsgruppe Planungsprozesse effektiver gestalten Planungsprozesse effektiver zu gestalten kann bedeuten, sie einfach zu beschleunigen. Der wesentliche Beitrag dieses Projekts hierfür ist die Reduktion der erforderlichen Zeit für Entscheidungsfindung. Entscheidungen eines Planungsbeteiligten basieren auf Vergleichen eines Zustands mit einer Referenz oder einer Alternative. Vorwiegend wird dieser Planungsbeteiligte (oben auch Analyst genannt) dadurch unterstützt, dass aus hinreichender Kenntnis von variierbaren Planungsparametern Planungsalternativen generiert werden können und unter Einsatz von den entwickelten Bewertungsmethoden eine Entscheidung über die Qualität einer solchen Variante getroffen werden kann.

4 5

ADT - Architectural Desktop (http://www.autodesk.com) ArchiCAD - (http://www.graphisoft.de)

Sensitivitätsanalyse netzwerkübergreifender Produkt- und Strukturmodelle

271

Kooperationen zwischen den Planungsbeteiligten unterstützen Zu diesem Zweck wurde eine generische, agentenbasierte Kollaborationsumgebung entwickelt, die es erlaubt, beliebige Kommunikationsakte zwischen Planungsbeteiligten durchzuführen. Ein solcher Kommunikationsakt besteht aus der Definition eines Kommunikationsprotokolls (AchieveRationalEffect, Contract etc.) und kann einem Agenten als Verhaltensmuster zugeordnet werden. Somit ist prinzipiell jeder Kommunikationsakt implementierbar und die Kollaborationsumgebung in dieser Hinsicht sozusagen modular und erweiterbar aufgestellt. Des Weiteren wurde im Laufe dieses Projekts erkannt, dass es nicht möglich ist einen Planungsprozess in seiner Gesamtheit in ein Prozessmodell zu überführen, ohne dabei wesentliche Teile auszublenden. Aus diesem Grund wird hier ein dynamisches, eventbasiertes Workflowmanagement beschrieben. Events sind Ereignisse, die jeweils an bestimmten Knoten in der Kollaborationsumgebung stattfinden. Eine Veränderung der Modelldaten löst beispielsweise ein solches Event aus. Diese Ursachen können auch entsprechend verfeinert werden, indem sie sich nur auf bestimmte Teile des Datenmodells beziehen (Wände, Stützen usw.). Auf Events kann durch eigens dafür implementierte Agenten (Monitoragenten) reagiert werden, die ihre entsprechend gekoppelten Partner (Proxyagenten) benachrichtigen.

Literatur Austin, J (2002) Zur Theorie der Sprechakte. Reclam, 2002 Bilek J (2003) Modell zur Abbildung vernetzt-kooperativer Planungsprozesse in der Tragwerksplanung auf Softwareagenten. In: Kaapke K (Hrsg) Forum Bauinformatik 2003 Junge Wissenschaftler forschen, Aachen Bilek J, Hartmann D (2002) Kooperative Tragwerksplanung basierend auf Multiagentensystemen. In: VDI-Tagung Bauen mit Computern - Kooperation in IT-Netzwerken, VDI-Berichte Nr. 16568, Bonn Box G E P, Draper N R (1987) Empirical Model-Building and Response Surfaces. Wiley, New York Fahrig T, Lähr A, Niggl A (2005) Multidisziplinäre Analyse und kooperative Simulation auf Grundlage eines Bauwerksmodells. In: Schley F, Weber L (Hrsg) Forumsband des 17. Forum Bauinformatik, Cottbus Ferber J (1999) Multi-Agent Systems. An Introduction to Distributed Artificial Intelligence, Addison-Wesley, Harlow Grabowski H, Schreiner P (1995) Multi Agent Driven Cooperative Product Development. In: Proceedings of Product and Process Modelling in the Building Industry, Rotterdam Khedro T, Genesereth M R (1993) Collaborative Distributed Facility Engineering Through Agent Based Software Integration. In: Proceedings of Third International Conference on the Application of Artificial Intelligence to Civil and Structural Engineering, Edinburgh Krafczyk M, Fahrig T, Tölke J, Niggl A; Rank E, Lähr A, Bletzinger K-U (2006) A Generalized Product-model Based Framework for Multidisciplinary Interactive Sensitivity Analysis and Optimization in Civil Engineering. In: Rivard H et al. (eds) Proceedings

272

Kai-Uwe Bletzinger, André Lähr

of the Joint International Conference on Computing and Decision Making in Civil and Building Engineering (ICCCBE, ICCC, DMUCE, CIB-W78, CIB-W102), Montréal Lähr A, Bletzinger K-U (2004) Design of an Analysis Environment for Planning Decision Support. In: Beucke K et al. (eds) Proceedings of the Xth International Conference on Computing in Civil and Building Engineering (ICCCBE), Weimar Lähr A, Bletzinger K-U (2005a) An Analysis Method for Planning Processes in AEC. In:Soibelman L, Feniosky P-M (eds) Proceedings of the International Conference on Computing in Civil Engineering (ICCC), Cancun Lähr A, Bletzinger K-U (2005b) Application of Sensitivity Analysis to a Planning Process in Architecture, Engineering and Construction (AEC). In: Herskovits J et al. (eds) Proceedings of the 6th World Congress on Structural and Multidisciplinary Optimization (WCSMO), Rio de Janeiro Lähr A, Bletzinger K-U (2005c) Prediction of Consequences for Planning Situation Based Decisions. In: Scherer R et al. (eds) Proceedings of the 22nd Conference on Information Technology in Construction, Dresden Lähr A, Bletzinger K-U (2006a) A Decision Supporting Framework based on Trend Analysis of Interdisciplinary Distributed AEC Systems. In: Rivard H et al. (eds) Proceedings of the Joint International Conference on Computing and Decision Making in Civil and Building Engineering (ICCCBE, ICCC, DMUCE, CIB-W78, CIB-W102), Montréal Lähr A, Bletzinger K-U (2006b) Prediction of Interdisciplinary Consequences for Planning Process Based Descisions in AEC. ITcon, vol 11, Special Issue Process Modelling, Process Management and Collaboration, pp 529–545 Meißner UF, Rüppel U, Greb S, Theiß M (2004) Prozessorientierte Brandschutzplanung mit Sortware-Agenten. In: Karlheinz Lehner (Hrsg.) Computer im Bauwesen - Festschrift zum 60. Geburtstag von Prof. Dietrich Hartmann. Shaker Verlag, Bochum Peine U (1998) Security Concepts and Implementation for the Ara Mobile Agent System, In: Proceedings of the 7th IEEE Workshop on Enabling Technologies: Infrastructure for Collaborative Enterprises, Stanford Romberg R et al. (2003) Numerische Simulation auf Basis des IFC-Bauwerksmodells. In: Proceedings of 16th International colloquium about application of computer science and mathematics in architecture and civil engineering, Weimar Sacks J et al. (1989) Design and Analysis of Computer Experiments. Statistical Science 4(4), pp 409–435 Saltelli A et al. (2000) Sensitivity Analysis. Wiley, Chichester Straßer M, Rothermel K (1998) Reliabilty Concepts für Mobile Agents. International Journal of Cooperative Information Systems (IJCIS), vol 7, No. 4 Taguchi G (1986) Introduction to Quality Engineering: Designing Quality into Products and Processes. Kraus International, New York Wassouf Z, Egger M, Neuberg F, van Treeck C, Rank E (2006) Produktmodell basierte Simulation des Ressourcenbedarfs von Bauwerken. In: Bauingenieur, Bd 81, SpringerVDI Verlag Wooldridge MJ, Jennings NR (1994) Intelligent Agents, In: Cohn AG (ed) Proceedings of ECAI -94 Workshop on Agent Theories, Architectures and Languages, Amsterdam

3 Ein Prototyp für verteilte, interaktiv-kooperative Simulationen zur Beschleunigung von Entwurfszyklen im Konstruktiven Ingenieurbau

Manfred Krafczyk, Jonas Tölke, Torsten Fahrig CAB – Institut für Computeranwendungen im Bauingenieurwesen, Technische Universität Braunschweig {kraft | toelke | fahrig}@cab.bau.tu-bs.de

3.1 Einleitung und Zielsetzung Der iterative Planungs-, Entwurfs- und Konstruktionszyklus im Konstruktiven Ingenieurbau erfordert speziell bei nicht-standardisierten Bauprojekten eine enge Kooperation zwischen den beteiligten Fachingenieuren bzw. Architekten, um die Entwicklungs- und Planungsphase so kurz und damit preiswert wie möglich zu halten. Hohe Folgekosten früher Planungs-, Entwurfs- und Konstruktionsfehler sind hinreichend, um eine frühzeitige und effektive Kommunikation zwischen allen an diesem Prozess beteiligten Fachleuten zu motivieren. Leider muss für die Bauwirtschaft mehrheitlich festgestellt werden, dass eine optimale Koordination in Planung und Entwurf heute noch nicht gegeben ist. Aus der Palette der vielfältigen Gründe hierfür sollen an dieser Stelle besonders herausgehoben werden:

x Die teilweise Inkompatibilität der vielfältigen unterschiedlichen Fachmodelle x Die unterschiedlichen Abstraktionsgrade der Fachmodelle x Strukturelle Unterschiede in der semantischen Definitionsschärfe der die Fachmodelle konstituierenden Entitäten Hinsichtlich der Planungsprozesse Konstruktion und Montage wurden Methoden zur vernetzt-kooperativen Konstruktion über Module zur automatischen Generierung von Konstruktionsplänen für einzelne Fachplaner prototypisch entwickelt und implementiert. Schwerpunkt ist hierbei die transparente Darstellung von Planungsentscheidungen der einzelnen Fachplaner im Gesamtzusammenhang. So können Abhängigkeiten in den verschiedenen Fachmodellen auch für spätere Pha-

274

Manfred Krafczyk, Jonas Tölke, Torsten Fahrig

sen der Planung erkannt und negative wie positive Konsequenzen ermittelt werden. Ein zusätzlicher Schwerpunkt liegt in der praxisnahen Konzeption und Optimierung von HVAC-Systemen (Heating, Ventilation and Air Conditioning). Dieses setzt neben einer durchdachten Positionierung und Bemessung der Bauteile wesentlich die Einbeziehung mess-, steuer- und regelungstechnischer Prozesse (MSR-Technik (DIN 1994)) voraus. Ausgehend von sensorisch zu erfassenden Größen wird die ein- und ausströmende Luft durch Software-Module entsprechend angepasst. Diese dynamisch variierenden Zustände innerhalb eines Simulationslaufes sollen in den Optimierungsprozess einbezogen werden. Dies erfolgt über einen agentenbasierten Ansatz (Fahrig et al. 2005, 2006).

3.2 Stand der Forschung 3.2.1 Produktmodelle und vernetzt-kooperative Planungsprozesse Methoden zur konsistenten Verwaltung von Produktmodelldaten für verteilte, kooperative Projektabläufe sind ein langjähriger Forschungsschwerpunkt der Bauinformatik (s. z.B. (Scherer 1996; Wassermann 1996)). Dazu wurden objektorientierte Partialproduktmodelle für die jeweiligen Fachplaner entwickelt, welche z.B. durch Referenzen zwischen den beteiligten Objekten verknüpft werden können. Bei Modifikationen der Partialproduktmodelle unterstützen Konfliktmanagementansätze eines zentralen Kernmodells die Integrität des Gesamtmodells (Wender et al. 2006; Willenbacher et al. 2006). Im Konstruktions- und Facility-Management-Sektor existieren zwei Kerntechnologien zur Abbildung von Bauwerksinhalten in standardisierten Datenstrukturen: die ISO 12006-2 (ISO 2002) für die Klassifizierung von Informationen sowie die Industry Foundation Classes (IFC 2006) der IAI (IAI 2005). Beide besitzen ein ähnliches Klassensystem. Der Anwendungsbereich der ISO 12006-2 bezieht sich auf den gesamten Konstruktionszyklus, spezifiziert aber im Gegensatz zur IAI nicht die Interoperabilität von Informations- und Kommunikationstechnologien (Ekholm 2005). Es herrscht zunehmend Konsens, dass die IFC grundsätzlich eine geeignete, wenn auch unvollständige Basis für die informationstechnische Repräsentation kooperativer Planungs- und Konstruktionsaufgaben im Bauwesen darstellt. Mittlerweile bieten die Marktführer für CAD-Software, wie z.B. Nemetschek, Graphisoft, Bentley und Autodesk entsprechende Schnittstellen für ihre Produkte (IAI's Software Implementer Support Group 2006). Es gibt Bemühungen, Probleme der Numerischen Simulation aus dem Bereich der Strukturanalyse in das IFC Datenmodell zu integrieren (ST-7 Extension Project 2005; Serror et al. 2006). Hinsichtlich der geometrischen Beschreibung von Objekten ist die IFC z. T. ungenau und unvollständig, andere Produktmodelle wie das Autodesk AEC Mo-

Ein Prototyp für verteilte, interaktiv-kooperative Simulationen

275

dell auf Basis des OMF (Autodesk 2003) sind präziser und bieten mehr Möglichkeiten. Im Bereich des Maschinenbaus ist die Entwicklung und der Einsatz von Produktmodellen schon weiter fortgeschritten (Dayal 2005). 3.2.2 Volumenbasierte Simulation Da das gemeinsame Entwurfs- und Konstruktionsszenario prinzipiell in einem virtuellen dreidimensionalen Raum stattfindet, liegt der Einsatz dreidimensionaler Berechnungsansätze nahe. Im Bauingenieurwesen werden räumliche numerische Simulationen sowohl für struktur- als auch für strömungsmechanische Problemstellungen nur in Ausnahmefällen durchgeführt. Eine mögliche Richtung für Verbesserungen bzgl. der Struktursimulation scheint in der Verwendung der pVersion der FEM gegeben zu sein (s. dazu (Duester 2001) und die dort angegebene Literatur). Strömungsmechanische Problemstellungen widersetzen sich in noch stärkerem Masse einer raumzeitlichen Prognose, da hier zusätzlich zu der (bezogen auf strukturmechanische Probleme) genuin höheren Anzahl von Freiheitsgraden grundsätzliche Fragen der Modellierung (z.B. Turbulenz) noch nicht hinreichend geklärt sind. 3.2.3 Computational Steering Computational Steering stellt interaktive Mechanismen zur Integration von Simulation, Datenanalyse, Visualisierung und Nachbearbeitung zur Laufzeit eines Programms zur Verfügung (Krafczyk 2004). Die Realisation eines solchen Systems erfolgt oft (aber nicht notwendigerweise) im Rahmen einer dreidimensionalen Visualisierung unter Verwendung von Virtual Reality Hardware mit entsprechender Rechenleistung für den Simulationskernel z.B. in Form eines PC-Clusters. Die Entwicklung solcher Ansätze ist Gegenstand aktueller Forschungsprojekte (SCI Institute 2004; Eickermann et al. 2005; Kohl et al. 2006). Erste halbkommerzielle Prototypen sind in der Entwicklung (VISENSO GmbH 2005), obwohl noch kein industrieller Standard abzusehen ist.

3.3 Vernetzt-kooperativer Ansatz des Prototyps Ziel dieses Projektes war die Entwicklung eines Prototypen auf Basis des Computational Steering Ansatzes unter Einbezug eines Parallelrechners für eine verteilte, interaktive Simulationsumgebung, der es einer Gruppe von Fachplanern (Architekt, Innenarchitekt und Hausleittechniker) ermöglicht, gemeinsam und unabhängig vom jeweiligen Standort Simulationen an den relevanten Fachrepräsentationen eines Entwurfs- und Konstruktionsprojektes durchzuführen (s. Abb. 3.1).

276

Manfred Krafczyk, Jonas Tölke, Torsten Fahrig

Abb. 3.1. Vernetzt-kooperativer Planungsprozess

Beispielhaft wird dieser Ansatz an einem Entwurfs- und Optimierungsprozess für die klima- und lüftungstechnische Ausgestaltung eines Großraumbüros demonstriert (Abb. 3.2). Weiterführend werden mess-, steuer- und regeltechnische Elemente der Klimaanlageninstallation emuliert (DIN 1994; Fahrig et al. 2005, 2006). Somit können Regelkreise und Regelsteuerungen interaktiv vom Hausleittechniker innerhalb des Prototyps rein virtuell parametrisiert und optimiert werden.

Abb. 3.2. Virtueller Entwurfsraum: Luftströmungen innerhalb eines Großraumbüros

3.4 Aufbau und Funktion des Prototypen Die Abb. 3.3 beschreibt den Aufbau des Prototypen, welcher sich in verschiedene Module zur Modellierung, Berechnung, Visualisierung und HVAC Simulation sowie die notwendigen Kopplungsschnittstellen gliedert, welche den Datenaustausch zwischen den Modulen zur Modellierung und Berechnung sowie zwischen

Ein Prototyp für verteilte, interaktiv-kooperative Simulationen

277

Berechnung und Visualisierung gewährleisten. Für die Kommunikation wurden jeweils unterschiedliche Techniken zum Datenaustausch durch kontextabhängige Anforderungen gewählt.

Abb. 3.3. Systemaufbau des Software-Prototypen

Im Folgenden werden der Aufbau und die Funktion der jeweiligen Module erläutert. 3.4.1 Geometrischer Modellierer Das Architectural Desktop 2005 der Firma Autodesk (ADT) (Autodesk 2005) stellt die Basis für den virtuellen Konstruktionsraum des Prototypen dar. Die Mehrheit der innerhalb dieses Projektes notwendigen Funktionen wurde hiermit realisiert. Dies beinhaltet Kommunikationsschnittstellen, Überwachungswerkzeuge für den Konstruktionsprozess, Teile des Pre-Processings sowie die Integration eines Produktmodells. Der ADT, eine Erweiterung der bekannten Software AutoCAD (Autodesk 2005) ist ein De-facto-Standard im Bauingenieurwesen und bietet neben seinen leistungsfähigen Modellierungsfunktionalitäten auch mächtige objekt-orientierte Programmierschnittstellen, u. a. das Object Modeling Framework (OMF) (Autodesk 2003). Diese Schnittstelle, eine Erweiterung von Autodesk ObjectARX (Autodesk 2005) bietet einen effizienten Datenaustausch mit dem Konstruktionsprozess, Zugriff auf die Geometrie der einzelnen Elemente und das Autodeskeigene AEC Produktmodell (Autodesk 2003) welches stark an das IFC-Konzept anknüpft. Weitere Details zum Produktmodelltransfer werden in Kapitel 3.4.4 genauer erläutert. Mehrere der im ADT implementierten Überwachungsroutinen (Agenten) sind während des gesamten Konstruktionsprozesses aktiv und überprüfen kontinuierlich den virtuellen Entwurfsraum auf Inkonsistenzen bei der geometrischen Anordnung der Objekte, der Anordnung außerhalb des Simulationsgebietes und bei Eingaben für Randbedingungen für die CFD-Simulation und korrigieren diese automatisch. Das geometrische Verhalten zwischen zwei Objekten, wie z.B. Klimaeinlass zu Wand oder Boden, wird über die Kopplung an Ankerelemente (Autodesk 2003, 2005), welche Bestandteil des OMF sind, realisiert. Die Validie-

278

Manfred Krafczyk, Jonas Tölke, Torsten Fahrig

rung der Randbedingungen und anderer Attribute wird über automatische PropertySets realisiert (Autodesk 2005). Hierbei können Eingabewerte anhand von geometrischen Positionseigenschaften, Projekt-, Material- und Stileigenschaften sowie hinterlegten Formeln und Grenzwerten überprüft und korrigiert werden. Für die Realisierung der HVAC und CFD-Simulation werden zusätzliche Konstruktionsobjekte wie Klimaanlageneinlässe und -auslässe sowie Messsensoren mit speziellen Eigenschaften sowie Steuerungsfunktionen für den Simulationsprozess benötigt. Diese sind in Form von AEC-Objekten realisiert worden, welche sich über das OMF direkt in vorhandene Objektbibliotheken (Werkzeugpaletten (Autodesk 2005)) des ADT integrieren lassen. Innerhalb dieser Bibliotheken befinden sich auch alle weiteren Konstruktionsobjekte wie Wände, Türen und Fenster die vom ADT direkt zur Verfügung gestellt werden.

Abb. 3.4. Automatische Ableitung von Bauplänen

Der LayoutManager (Bindick 2006), eine zusätzliche, über die Programmierschnittstelle OMF entwickelte Erweiterung des Modellierers, bietet die automatische Erstellung von spezifischen Bauplänen für die jeweiligen, am Konstruktionsprozess beteiligten Fachplaner. Hierbei wird der objektorientierte Ansatz der Produktmodelle aufgegriffen, indem den Bauteilen zusätzliche fachplanerspezifische Filterattribute zugewiesen werden (Autodesk 2003). Da die geometrische Darstellung innerhalb des AEC Produktmodells als Attribut eines Objektes gehandhabt wird, ist es möglich mehrere Geometrien für jeden Aufgabenbereich (2D Bauplan, 3D Konstruktionsraum) und für alle Fachplaner an ein Bauteil anzuhängen. Das Bauplanmodul des Prototyps extrahiert die spezifischen Informationen und ordnet sie mit der jeweiligen Geometrie den Bauplänen zu (s. Abb. 3.4). Dies geschieht exemplarisch für die Bereiche Hausleittechnik (Leitungen, Klimaanlagenelemente), Architektur (Mauerwerk, Stürze, Durchbrüche) und Innenarchitektur (Trennwände, Möblierung).

Ein Prototyp für verteilte, interaktiv-kooperative Simulationen

279

Die Ausgabe der generierten Pläne kann neben der direkten Ausgabe auf einen angebundenen Plotter auch über verschiedene digitale Formate (wie z.B. Adobe Acrobat PDF) erfolgen. Ein Onlinezugriff ist über das automatische Hochladen aller relevanten Daten auf einen angebundenen Webserver möglich. 3.4.2 Volumenbasierte numerische Analyse und Paralleles Rechnen Der hier entwickelte CFD-Rechenkern des Software Prototyps basiert auf dem vergleichsweise neuartigen Lattice-Boltzmann (LB)-Ansatz welcher primär für die Simulation von Mehrphasen- und Mehrkomponentensystemen in komplexen Geometrien entwickelt wurde, sich aber auch mittlerweile bei der Simulation laminarer, turbulenter und thermischer Navier-Stokes Probleme bewährt hat (Krafczyk u. Rank 1995; Krafczyk et al. 2000; Tölke et al. 2000; Tölke 2001; Crouse et al. 2002). Diese Algorithmen wurden für drei Raumdimensionen weiterentwickelt und auf unterschiedliche parallele Hardware unter Benutzung der MessagePassing Software MPI (MPI-Forum 1997) portiert. Messungen der Parallelisierungseffizienz wurden auf verschiedenen Hardware-Plattformen durchgeführt und zeigten durchweg sehr gute Ergebnisse. Die Simulation des thermischen Problems erfolgt mit einem neu entwickelten Lattice-Boltzmann Ansatz, welcher in (Tölke 2006) beschrieben ist. Der Computational Steering Ansatz stellt durch die Einbindung von komplexer Simulation, Datenanalyse, Visualisierung und Nachbearbeitung sehr hohe Anforderungen an die unterstützende Hardware. Aus diesem Grund wurde in dieses Projekt eine Virtual Reality Umgebung zur Visualisierung sowie ein PC-Cluster mit 122 AMD Opteron CPUs und einer Peakperformance von 370 GFLOPS für die Simulation eingebunden. 3.4.3 Visualisierer Die multimediale Visualisierung komplexer Vorgänge in Struktur- und Strömungsmechanik insbesondere unter Verwendung von Methoden des visuellen Programmierens und auch in Virtual Reality Umgebungen stellen ein weiteres Arbeitsgebiet dar. Neben entsprechenden Publikationen (Kühner u. Krafczyk 2000; Kühner et al. 2001) befasst sich das Projekt mit dem Aufbau einer kombinierten HPC-VR-Umgebung, in welcher Ansätze des Virtual Engineering implementiert und evaluiert werden (Tölke et al. 2003). Zur Visualisierung und zum Post-Processing wird hierbei die Software AVS/EXPRESS (Advanced Visual Systems Inc. (AVS) 2005) eingesetzt, welche eine mächtige Programmierschnittstelle besitzt und die effiziente Darstellung und die Manipulation von Skalaren und Vektorfeldern für mehrere Millionen Knotenpunkte erlaubt. Die umfangreiche Modulbibliothek bietet z.B. Isoflächen, Isovolumen und Stromlinien zur Visualisierung der Luftströmungen.

280

Manfred Krafczyk, Jonas Tölke, Torsten Fahrig

3.4.4 Modelltransfer innerhalb des Software Prototyps In Abb. 3.5 und 3.6 wird der automatisierte Modelltransfer innerhalb des Software-Prototyps veranschaulicht. Die Grafiken zeigen die Konvertierung des Basismodells sowie der entsprechenden Objektattribute und Randbedingungen, die dafür zuständigen interaktiven Schnittstellen und Softwaremodule sowie die entsprechende Hardware auf der die Prozesse ausgeführt werden. Als Datenbasis dient ein IFC Produktmodell. Dieses unterstützt aktuell keine direkte Implementierung von Randbedingungen für CFD-Simulationen oder anderer notwendiger Parameter und Objektattribute, welche für den interaktiven Simulator notwendig sind wie:

x Attribute für die numerische Berechnung, z.B. Randbedingungen wie Temperatur, Geschwindigkeit, Druck, Strahlung und Materialeigenschaften

x Attribute für die Visualisierung der Geometrie, z.B. Farbe und Transparenz x Attribute für das HVAC Agenten Framework, z.B. Parameter für Regelglieder, Grenzwerte x Attribute für die Überwachungswerkzeuge des Konstruktions- und Entwurfsprozesses wie z.B. Grenzwerte von Eingabeparametern für Randbedingungen, HVAC Parametern oder Ankerelemente x Eine genaue Definition der Geometrie eines Objektes in Form eines konsistenten Volumenmodells x Attribute für die spezifische Objektzuordnung je Fachplaner z.B. für die automatische Erstellung von Bauplänen

Ein Prototyp für verteilte, interaktiv-kooperative Simulationen

Abb. 3.5. Automatisierter Modelltransfer innerhalb des Prototyps, Teil 1

281

282

Manfred Krafczyk, Jonas Tölke, Torsten Fahrig

Abb. 3.6. Automatisierter Modelltransfer innerhalb des Prototyps, Teil 2

Das IFC-Konzept verfolgt einen objektorientierten Ansatz und bietet alternativ die Möglichkeiten der Erweiterung von Objekten durch IfcPropertySets (IAI 2005), frei definierbare Eigenschaftssätze, welche jeweils eine im Prinzip unbegrenzte Anzahl von Attributen beinhalten können (s. Abb. 3.7).

Ein Prototyp für verteilte, interaktiv-kooperative Simulationen

283

Abb. 3.7. Aufbau eines IfcPropertySets

Jedes Objekt kann über eine eindeutige Objekt-ID, die GUID (Globaly Unique Identifier, (OMG 2006)) zugeordnet werden, welche über die gesamte Lebensdauer ihre Gültigkeit behält und konsistent in den ADT importiert und exportiert werden kann. Die Abb. 3.8 zeigt die ID sowie eine exemplarische Auswahl von Attributen eines Klimaauslasses für die CFD-Simulation als IFC-Datei sowie als Eigenschaftssatz innerhalb des ADT.

Abb. 3.8. Konsistente Konvertierung von AEC zu IFC Objekten

Der ADT 2005 erlaubt somit die konsistente Überführung eines IFC Produktmodells in das im ADT integrierte AEC Produktmodell über ein zusätzliches ADT Plug-In (G.E.M. Team Solutions und Inopso GmbH 2005). Während des Importvorganges werden die IfcPropertySets in Autodesk-konforme AECPropertySets konvertiert. Ein Software-Agent prüft hierbei, ob die notwendigen Objektattribute innerhalb der IFC Produktmodells vorliegen und vorgegebene Grenzwerte eingehalten wurden. Bei Abweichungen werden automatisch neue Werte gesetzt und fehlende Attribute bzw. fehlende Eigenschaftssätze hinzugefügt. Hierbei greift der Agent auf Standardvorgabewerte zurück, welche in einer XML-Datenbank (World Wide Web Consortium (W3C) 1996) hinterlegt sind. Der Agent identifiziert hier-

284

Manfred Krafczyk, Jonas Tölke, Torsten Fahrig

bei das importierte Objekt über seine Typ- oder Stilzuordnung und fügt den passenden Standarddatensatz an. Bei geometrischen Modifikationen innerhalb des Konstruktionsraumes welche für den Simulationsprozess relevant sind (verschieben, hinzufügen, löschen von Objekten), wird die Geometrie automatisch in einem Hintergrundprozess der Modellierers in ein volumenorientiertes Facettenmodell (Brep-Modell (Neuberg 2004; Autodesk 2005)) konvertiert und an die für die Weiterverarbeitung zuständigen Module übertragen. Zur besseren Verarbeitung geometrischer Daten wird ein auf einem Oktalbaum (Brüggemann u. Holz 2004) basierender automatisierter Gittergenerator als PreProcessor eingesetzt, welcher für den Computational Steering Ansatz optimiert wurde (Zhuang 2006). Dieses Modul erhält das Oberflächenmodell sowie eine Eigenschaftsliste aller Objektattribute und Randbedingungen. Jedes Dreieck des Oberflächenmodells erhält eine vom ADT zugewiesene ID, welche einem spezifischen Eigenschaftssatz innerhalb der Liste zugeordnet werden kann. Bei nichtgeometrischen Modifikationen (z.B. Änderung der globalen Randbedingungen oder Objekteigenschaften) werden nur die Eigenschaftssätze der entsprechenden Objekte ohne das geometrische Modell an den Kern übertragen. Für diese Art der fallspezifischen Datenübertragung wurde ein eigenes, effizientes Kommunikationsprotokoll (Zhuang 2006) auf Basis von TCP/IP Socket-Kommunikation und Qt (Trolltech 2005) entwickelt. Auf Basis der Oberflächendaten des Modells generiert der Pre-Processor einen Oktalbaum und konvertiert diesen in ein Voxel-Modell. Hierbei erhalten die IDs der Voxel-Punkte den Wert der IDs der jeweiligen Dreiecke aus denen sie erzeugt wurden. Die Eigenschaftslisten der Objekte können somit direkt übernommen und zusammen mit dem Voxel-Modell an den CFD-Kern übertragen werden. Der CFD-Kern bipartitioniert das Voxel-Modell rekursiv (Gun 2002) für eine parallele Berechnung (Rauber u. Rüger 2000) auf den Knoten des PC-Clusters. Der Kern besteht hierbei aus mehreren Teilprozessen, welche mittels MPI (MPIForum 1997) untereinander kommunizieren. Alle Programmteile des Kerns sind unter dem Fokus der Performancesteigerung in der Programmiersprache Fortran95 (ISO - International Standard Organisation 1996) entwickelt worden. Die Ergebnisdaten der Berechnung ohne geometrische Informationen werden nach einer Anzahl von Rechenschritten automatisch als vierdimensionales Feld, welches die Raumkoordinaten und einen Vektor der Strömungsdaten ohne geometrische Informationen beinhaltet, an das Visualisierungsmodul gesendet. Zwischen dem Simulationskern und AVS/EXPRESS (Advanced Visual Systems Inc. (AVS) 2005) ist aufgrund der großen Datenmengen eine hohe Bandbreite sowie eine effiziente Kommunikation notwendig. Hierfür wurde das vom Forschungszentrum Jülich entwickelte Programm VISIT (Eickermann et al. 2001) herangezogen. Dieses „Visualization Interface Toolkit“, basierend auf der TCP SocketKommunikation und wurde speziell für den Transfer von Ergebnisdaten numerischer Simulationen innerhalb einer Computational Steering Umgebung entwickelt. Ein weiteres AVS-Modul erhält die geometrischen Daten als Oberflächenmodell aus dem Modellieren als UCD Dateiformat (Advanced Visual Systems Inc. (AVS) 1991). Strömungsdaten und geometrisches Modell werden innerhalb des

Ein Prototyp für verteilte, interaktiv-kooperative Simulationen

285

Visualisierers zusammengeführt und über die VR-Anlage bzw. die verteilten Displays der Fachplaner ausgegeben. Arbeiten zum vernetzt-kooperativen Modelltransfer auf Basis eines IFC Produktmodells wurden in Zusammenarbeit mit anderen Projekten des SSP 1103 veröffentlicht (Fahrig et al. 2005; Krafczyk et al. 2006). Arbeiten zum automatisierten Modelltransfer wurden in (Fahrig et al. 2004) veröffentlicht. 3.4.5 Einbeziehung mess-, steuer-, regeltechnischer Anlagen (MSRTechnik) über agentenbasierte Systeme Eine praxisnahe Konzeption und Optimierung von HVAC-Systemen setzt neben einer durchdachten Positionierung und Bemessung der Bauteile wesentlich die Einbeziehung mess-, steuer- und regelungstechnischer Prozesse (MSR-Technik) (Ritschel 1994, 1995) voraus. Ausgehend von sensorisch zu erfassenden Größen wie z.B. Temperatur, Luftfeuchtigkeit oder Turbulenzintensität werden die Geschwindigkeit, die Temperatur und der Einfallswinkel der einströmenden Luft aus den Klimamodulen in den Raum entsprechend angepasst. Diese dynamisch variierenden Zustände innerhalb einer Simulationslaufes werden in den Optimierungsprozess einbezogen. Dies erfolgt über einen agentenbasierten Ansatz, indem eine entsprechende Anzahl von Wrapper-Agenten (Arlt 2000) zur Sensorik und Steuerung an die geometrischen Objekte, welche die HVAC Komponenten repräsentieren, angehängt und somit in den Simulationsprozess eingebunden werden. Ein direkter Vergleich der Funktionalität von MSR-Techniken mit der Funktionalität von Software-Agenten nach der Definition von (Wooldridge u. Jennings 1994) unterstreicht das ideale Anwendungsgebiet dieser Technologie zur Emulation der Verhaltenseigenschaften von Regel- und Messgliedern innerhalb eines Regelkreises. Die Behaglichkeit im Raum definiert durch den PMV-Index (Predicted Mean Vote) (ISO 1984; Ritschel 1994, 1995) wird stark durch den temperierten Lufteinfluss aus dem Klimaanlagenauslass beeinflusst. Der Regelkreis dieses Auslasses, repräsentiert durch eine spezifische Kennlinie, wird durch ein autonomes Agentensystem gesteuert. Der Agent fragt in Abständen benötigte Regelgrößen über eine definierte Schnittstelle von virtuellen, im Gebäude verteilten Messsensoren ab, welche ebenfalls agentenbasiert sind. Regel- sowie Messagenten können während der Laufzeit der Simulation dynamisch generiert und entfernt werden. Die Kopplung dieser Agenten an das Netzwerk der virtuellen HVAC Installation erfolgt hierbei ebenfalls automatisch. Entsprechend der integrierten Verhaltensregeln und Führungsgrößen wird der Luftausstrom adaptiv den aus der Steuerung ermittelten Sollwerten angepasst. Die optimierten Parameter für das Behaglichkeitsfeld aus der Simulation können aus dem Agentensystem exportiert werden und dienen als Profil zur Festlegung der Regelungsstrategie für das zu installierende Steuersystem der Klimaanlage.

286

Manfred Krafczyk, Jonas Tölke, Torsten Fahrig

Implementierung Für eine interaktive Simulation der HVAC MSR-Technik werden die SoftwareAgenten über eine bidirektionale COM-Schnittstelle (Microsoft 2006) an den interaktiven geometrischen Modellierer angebunden. Der Modellierer überwacht permanent geometrische Modifikationen innerhalb des Entwurfsraumes und übermittelt automatisch relevante Informationen für die HVAC Installation an die Agenten. Entsprechende Modifikationen des zur Laufzeit berechneten Luftstromes der Klimaanlageneinlässe werden ebenfalls über die COM-Schnittstelle von den Agenten an den Modellierer übertragen. Diese übermittelten Informationen werden als neue Randbedingungen für den CFD-Kern innerhalb der PropertySets des jeweiligen HVAC Elementes gesetzt und periodisch aktualisiert. Abbildung 3.9 zeigt das Implementierungsschema der Software Agenten bestehend aus zwei Typen: Der Sensor-Agent fragt periodisch Daten zum Klimakomfort abhängig von seiner Position im virtuellen Konstruktionsraum vom CFDKern über eine Socket-Verbindung (Trolltech 2005) ab. Mehrere Sensor-Agenten können an einen oder mehrere Inlet-Agenten gekoppelt werden. Der Inlet-Agent repräsentiert einen Klimaanlagenauslass der HVACInstallation sowie die jeweilige Implementierung der Regeltechnik. Basierend auf der charakteristischen Kennlinie des Einlasses wird der Luftstrom in den Raum über Geschwindigkeit, Temperatur, Feuchte und Einfallswinkel reguliert. Die Parameter können während des Simulationslaufes über die Benutzeroberfläche vom Regeltechniker direkt modifiziert werden ohne die Berechnungen zu unterbrechen. Da die MSR-Technik zeitabhängige Steuerung voraussetzt, wird ein kontinuierlicher Zeitimpuls über den Rechenkern mit der tatsächlichen Simulationszeit an das HVAC Framework gesendet.

Abb. 3.9. Schema der HVAC Agenten Implementierung

Ein Prototyp für verteilte, interaktiv-kooperative Simulationen

287

Regeltechnik Das nachfolgende Zitat (Recknagel et al. 2005) beschreibt die Regelgüte von Regelkreisen: „Eine Regeleinrichtung hat die Aufgabe, die Regelgröße x möglichst genau auf einen vorgegebenen, zeitlich konstanten oder veränderlichen Wert zu halten und den Einfluss von Störgrößen auf ein Mindestmaß zu beschränken. Außerdem ist zu fordern, dass das Ausregeln […] in kurzer Zeit erfolgt. Weiterhin sollen sie […] Überschwingungen innerhalb bestimmter Grenzen halten. Die Erfüllung dieser Forderungen ist nicht möglich, so dass hierbei Kompromisse geschlossen werden müssen.“ In der Praxis müssen hierbei aufwendige und dadurch kostenintensive manuelle Parametrisierungen der einzelnen Regeleinrichtungen basierend auf lokalen Messdaten durchgeführt werden. Dieser Sachverhalt zeigt das enorme Potenzial von computergestützter Vorparametrisierung und Optimierung in der praktischen Anwendung. Nach (Schleicher u. Blasinger 2004) stellen sich die wichtigsten Aufgaben für einen Regelungstechniker wie folgt dar:

x x x x x x

Festlegung der Regelgröße Prüfung der Vorteile einer Regelung Festlegung des Messortes sowie Feststellung der Störgrößen Wahl des Stellgliedes und eines geeigneten Regelgerätes Positionierung der Regelgeräte Inbetriebnahme, parametrisieren, optimieren

Über den Prototypen ist eine vollständig virtuelle Realisierung der hier aufgeführten Aufgaben einschließlich der Optimierung der geometrischen Anordnung der Anlagenelemente möglich. Regelwerke Das Regeln ist ein Vorgang, bei dem die fortlaufend erfasste Regelgröße mit einer Führungsgröße verglichen und im Sinne einer Angleichung an die Führungsgröße beeinflusst wird. Der sich daraus ergebende Wirkungsablauf findet im Regelkreis statt. Bei allen Regelkreisen ist von Bedeutung, wie der Regler bei einer Abweichung der Regelgröße vom Sollwert unterschiedlich eingreifen soll (z.B. schnell oder langsam, stark oder schwach). Dies hängt von den regelungstechnischen Eigenschaften der Regelstrecke ab, weshalb man das statische und dynamische Verhalten der einzelnen Teile (Glieder) des Regelkreises genau kennen muss. Die Wahl eines passenden Regelgliedes hängt vom Anwendungsfeld ab. Der HVAC Inlet-Agent beinhaltet eine Reihe von gängigen Regelgliedern (P-, I-, PD-, PI-, PID-Regler) resultierend aus der Kombination von Proportional-, Integral- und Differenzial-Elementen (Abb. 3.10).

288

Manfred Krafczyk, Jonas Tölke, Torsten Fahrig

Abb. 3.10. Auszug implementierter Regelglieder für die HVAC Simulation

Entsprechende Parameter dieser Elemente (Regelstärke, Reaktionszeit, Vor- und Nachlaufzeiten) können hierbei innerhalb des Simulationslaufes über eine grafische Oberfläche vom Hausleittechniker optimiert werden (s. Abb. 3.11). Für die Analyse werden Messdaten von Sensoren und Auslässen in Echtzeit über eine Plot-Funktion ausgegeben (s. Abb. 3.10 unten). Die Simulation mess-, steuer-, regeltechnischer Anlagen über agentenbasierte Systeme ist in (Fahrig et al. 2006) genauer beschrieben.

Abb. 3.11. GUI des HVAC Agenten-Frameworks

Ein Prototyp für verteilte, interaktiv-kooperative Simulationen

289

3.4.6 Multi-User-Umgebung Die Integration der Software VNC (RealVNC 2002) erlaubt die Realisierung einer Muli-User-Umgebung für einen kooperativen verteilten Zugriff von verschiedenen Fachplanern auf ein gemeinsames Display. Der virtuelle Konstruktionsraum des Modellierers bzw. die Visualisierung können als Fensterapplikation von der Workstation aus an beliebig viele Client-Rechner der einzelnen Benutzer übertragen werden (s. Abb. 3.1 und 3.3). Hierbei wird die Kontrolle jeweils nur einem Planer übertragen, welcher über Maus und Tastatur den Prozess steuern kann. Durch den Wegfall eines simultanen Zugriffs („one at a time“) wird hierdurch das Problem einer redundanten Datenhaltung und einem damit verbundenen möglichen Versionskonflikt umgangen. Die Software VNC ist plattformunabhängig und kann ohne vorinstallierte Software als serverseitige Java-Applikation über einen beliebigen Browser gestartet werden. Eine verzögerungsfreie Bildübertragung ist allerdings nur bei Netzanbindungen mit höherer Bandbreite gewährleistet. Die heutzutage gängigen Internet-Anbindungen mit DSL oder mobiler UMTS Technik sind hierfür in der Regel ausreichend. Die Effizienz des kooperativen Planungsprozesses in der Multi-UserUmgebung wird durch die Einbindung von internetbasierter Audio- und Videounterstützung verstärkt. Hierbei wurde auf die freie Software Skype (Skype Ltd. 2006), welche auch den Gebrauch von mobilen Geräten unterstützt, zurückgegriffen.

3.5 Simulationsbeispiel Als Demonstrationsproblem dient im Folgenden die Optimierung der Behaglichkeit an den einzelnen Arbeitsplätzen eines Großraumbüros. Diese berechnet sich aus dem PMV-Index (Predicted Mean Vote) (ISO 1984; Ritschel 1994, 1995) und ist abhängig von Temperatur, Luftdichte, Strömungsgeschwindigkeit sowie weiteren benutzerspezifischen Parametern. Als Geometrie wurde ein Stockwerk des Wiener Uniqua-Towers (UNIQA Versicherungen AG 2004 ) gewählt, welches mit einer agentengesteuerten Klimaanlageninstallation ausgestattet wurde. Hierbei wurden Klimaeinlässe, in einer Reihenanordnung über die gesamte Fensterfront in Form einer Bodeninstallation gewählt. Klimaauslässe wurden an jeweils vier Seiten der beiden Gebäudekerne in einer Höhe von 2,40 m (bei einer Deckenhöhe von 2,70 m) installiert. Die Einblasgeschwindigkeit von 0,0–3,0 m/s, die Temperatur von 18,0–32,0 °C und der Einfallswinkel von 0,0–80,0° werden über die HVAC Agenten während des Simulationslaufes dynamisch angepasst. Mehrere Messsensoren befinden sich im Bereich der Arbeitsplätze.

290

Manfred Krafczyk, Jonas Tölke, Torsten Fahrig

Abb. 3.12. Visualisierung der Ergebnisse des Simulationslaufes „Uniqua-Tower“

Die Abb. 3.12 zeigt die Klimaverhältnisse im Raum nach ca. 40 realen Minuten nach einer initialen Raumtemperatur von 20° C. Ein Isovolumen innerhalb der rechten Grafik umhüllt die Bereiche, in denen der PMV-Index einen akzeptablen Behaglichkeitswert liefert. Die linke Grafik der Abb. 3.12 stellt über eine visuelle Codierung die Temperaturentwicklung als Schnittebene dar, die Vektorpfeile repräsentieren die Geschwindigkeit im Raum.

3.6 Zusammenfassung und Ausblick Der hier vorgestellte Software-Prototyp auf Basis eines Computational Steering Ansatzes kann das benötigte Zeitaufkommen für die Durchführung vieler Optimierungsprozesse, welche normalerweise an manuelle und iterative Interaktionen während der Planungsphase gebunden sind, wesentlich reduzieren. Die effektive Kommunikation zwischen den Fachplanern und der direkten Visualisierung der Ergebnisdaten reduziert Entwurfs- und Konstruktionsfehler nachweislich. Das innerhalb des Schwerpunktprogramms in Zusammenarbeit mit anderen Projekten vorgestellte Kooperationsmodell zeigt erfolgreich eine Methode auf prototypischer Basis, um einen domänenübergreifenden Austausch von Daten auf Basis eines IFC Produktmodells erfolgreich zu realisieren. Die Integration von Mess-, Steuer- und Regeltechniken erweitert die Möglichkeiten der HVAC Simulation und erhöht die Genauigkeit der erzielten Ergebnisse. Das transiente Verhalten von Regelkreisen und Regelgliedern kann intuitiv analysiert und optimiert werden. In Kombination mit dem Computational Steering Ansatz erhält der Hausleittechniker die Möglichkeit, die Parameter der HVACAnlagensteuerung bei direkter Visualisierung der Auswirkungen durch direkte Interaktion mit den Objekten seiner Anschauung zu variieren. Durch den kombinierten Optimierungsprozess von Anordnung einer Klimaanlageninstallation und der genauen Abstimmung der Regeltechnik können enorme Mengen an Energiekosten eingespart werden. Dieses Potenzial begründet eine Weiterentwicklung in diesem Bereich.

Ein Prototyp für verteilte, interaktiv-kooperative Simulationen

291

Literatur Advanced Visual Systems Inc. (AVS) (1991) Unstructured Cell Data (UCD) (http://www.iavsc.org) Advanced Visual Systems Inc. (AVS) (2005) AVS/EXPRESS (http://www.avs.com) Arlt M (2000) Agentenbasierte Systemarchitekturen für Produktdaten-ManagementSysteme. Hrsg Shaker-Verlag, Aachen Autodesk (2003) OMF Developer's Guide 3.3 (http://adn.autodesk.com) Autodesk (2005a) Autodesk Architectural Desktop (http://www.autodesk.com) Autodesk (2005b) Autodesk ObjectARX Developer's Guide (http://adn.autodesk.com) Bindick S (2006) Ein Prototyp zur rechnergestützten Kraneinsatzplanung mit dem Autodesk Architectural Desktop 2005. Studienarbeit, TU Braunschweig Brüggemann BM, Holz K-P (2004). Quadtree based hydroinformatics simulation sys-tems: A component-oriented finite volume toolkit for shallow water equations. 6th International Conference on Hydroinformatics. World Scientific Publishing Co. Pte. Ltd., Singapore Crouse B, Krafczyk M, Kühner S, Rank E, Treeck CV (2002) Indoor air flow analysis based on lattice Boltzmann methods. Int. J. Energy and Buildings, Elsevier Dayal M (2005) Analyse des 3D-Datenaustausches via IFC-Modell am Beispiel komplexer Objektdokumentation in der Automobilindustrie. Hrsg Irb-Verlag DIN Deutsches Institut für Normung e.V. (1994a) DIN 19226, Teil 2 – Leittechnik, Regelungstechnik und Steuertechnik, Begriffe zum Verhalten dynamischer Systeme. Beuth Verlag GmbH DIN Deutsches Institut für Normung e.V. (1994b) DIN 19226, Teil 5 – Leittechnik, Regelungstechnik und Steuertechnik, Funktionelle Begriffe. Beuth Verlag GmbH Duester A (2001) High order finite elements for three-dimensional, thin-walled nonlinear continua. Dissertation, Technische Universität München Eickermann T, Frings W, Gibbon P, Kirtchakova L, Mallmann D, Visser A (2005) Steering UNICORE applications with VISIT. Philosophical Transactions of the Royal Society A: Mathematical, Physical and Engineering Sciences 363 (Nr. 1833 / August 15, 2005):1855–1865 Eickermann T, Frings W, Visser A (2001) VISIT – a Visualization Interface Toolkit. Juelich, Germany (http://www.fz-juelich.de/zam/visit/) Ekholm A (2005) ISO 12006-2 AND IFC – PREREQUISITES FOR COORDINATION OF STANDARDS FOR CLASSIFICATION AND INTEROPERABILITY. ITcon 10:275–289 Fahrig T, Nachtwey B, Geller S, Tölke J, Krafczyk M (2004) Automatic Model transfer in a Computational Steering Environment. Deutsch-Russisches Bauinformatik Symposium, Moskau und St. Petersburg, Russia Fahrig T, Lähr A, Niggl A (2005a) Multidisziplinäre Analyse und kooperative Simulation auf Grundlage eines Bauwerksmodells. 17. Forum Bauinformatik, Cottbus Fahrig T, Tölke J, Krafczyk M (2005b) Agent-based Measuring, Control and Regulation Techniques for HVAC-Simulations. Building Simulations Conference, Montreal, Canada Fahrig T, Krafczyk M, Nachtwey B, Tölke J (2006a) Enhanced Computational HVAC Simulations using Software Agent Technology. Joint International Conference on Computing and Decision Making in Civil and Building Engineering, Montreal, Canada Fahrig T, Krafczyk M, Nachtwey B, Tölke J (2006b) Interaktive Optimierung mess-, steuer- und Regelungstechnischer Anlagen für die technische Gebäudeausrüstung. BauSim, München

292

Manfred Krafczyk, Jonas Tölke, Torsten Fahrig

G.E.M. Team Solutions und Inopso GmbH (2005) IFC-Utility 2x for ADT 2005 ( http://www.inopso.com/) Gun A (2002) Ein Gebietszerleger für parallele Lattice Boltzmann Applikationen auf der Basis von rekursiv-bipartiven Algorithmen für equidistante teilgefüllte 3D-Gitter. Diplomarbeit, TU München IAI's Software Implementer Support Group (2006) IFC2x3-Software Implementation Certification. http://129.187.85.207:8080/fb02/IAI-ISG-Portal/ IAI (International Alliance for Interoperability) (2005) IFC / ifcXML IFC (2006) http://www.buildingsmart.de/ ISO (International Standards Organization) (1984) ISO Standard 7730 "Moderate Thermal Environments – Determination of the PMV and PPD Indices and Specification of the Conditions for Thermal Comfort" ISO (International Standard Organisation) (1996) ISO/IEC DIS 1539-1 (Fortran 95) ISO (International Standard Organisation) (2002) ISO 12006-2:2001 Hochbau – Organisation des Austausches von Informationen über die Durchführung von Hoch- und Tiefbauten – Teil 2: Struktur für die Klassifizierung von Informationen. 2001-11 Kohl JA, Wilde T, Bernholdt DE (2006) Cumulvs: Interacting with High-Performance Scientific Simulations, for Visualization, Steering and Fault Tolerance. International Journal of High Performance Computing Applications 20:255–285 Krafczyk M (2004) Computersimulation und Technologiefortschritt – eine symbiotische Beziehung. Journal der Deutschen Akademien der Wissenschaften Krafczyk M, Rank E (1995) A Parallelized Lattice-Gas Solver for Transient Navier-StokesFlow: Implementation and Simulation Results. Int. Journal for Num. Methods in Eng. vol. 38:1243–1258 Krafczyk M, Lehmann P, Schulz M, Tölke J, Rank E (2000) Direct Computation of MultiPhase Flow in Reconstructed Soil. CIMENICS, Puerto La Cruz Krafczyk M, Fahrig T, Tölke J, Niggl A, Rank E, Lähr A, Bletzinger U (2006) A generalized product-model based framework for multidisciplinary sensitivity analysis and optimization in civil engineering. Joint International Conference on Computing and Decision Making in Civil and Building Engineering, Montreal, Canada Kühner S, Krafczyk M (2000) Virtual Fluids - An environment for integral visualisation and analysis of CAD and simulation data. 5th International Fall Workshop VISION, MODELING, AND VISUALIZATION, Saarbrücken Kühner S, Rank E, Krafczyk M (2001) Efficient reduction of 3D simulation results based on spacetree data structures for data analysis in Virtual Reality environments Applied Virtual Reality in Engineering and Construction. Tullberg D, Connell. Goteborg, Sweden Microsoft (2006) COM/COM+ (Component Object Model) (http://microsoft.com) MPI-Forum (1997) MPI – Message Passing Interface (http://www.mpi-forum.org) Neuberg F (2004) Ein Softwarekonzept zur Internet-basierten Simulation des Ressourcenbedarfs von Bauwerken. Dissertation, TU München OMG NWG (2006) UUID/GUID Definition Rauber T, Rünger G (2000) Parallele und verteilte Programmierung, Hrsg Springer-Verlag, Berlin/Heidelberg RealVNC (2002) VNC (Virtual Network Computing). UK, http://www.realvnc.com/ Recknagel H, Sprenger E, Schramek E-R (2005) Taschenbuch für Heizung und Klimatechnik 2005/2006. Hrsg Oldenbourg Industrieverlag, München Ritschel H (1994/1995) Raumklimatechnik. Bd 1, Hrsg Springer Verlag, Berlin Scherer RJ (1996) Objektorientierte Produktmodellierung im Bauwesen als Grundlage eines durchgängigen CAD/CAM-Konzeptes. Hartmann D (Hrsg), Bochum

Ein Prototyp für verteilte, interaktiv-kooperative Simulationen

293

Schleicher M, Blasinger M (2004) Regelungstechnik für den Praktiker. Hrsg JUMO GmbH & Co. KG, Fulda SCI Institute UoU (2004) Scientific Computing, Scientific Visualization, Imaging Serror MH, Inoue J, Adachi Y, Fujino Y (2006) Building on IFC: E-Interaction with/within Structural Design Domain. Joint International Conference on Computing and Decision Making in Civil and Building Engineering, Montreal, Canada Skype Ltd. (2006) Skype. Luxembourg (http://www.skype.com/intl/de/) ST-7 Extension Project (2005) ST-7 Version 2.0 Release (http://groups.yahoo.com/group/ST-7) Tölke J (2001) Gitter-Boltzmann-Verfahren zur Simulation von Zweiphasenströmungen. Dissertation, TU München Tölke J (2006) A thermal model based on the lattice Boltzmann method for low Mach number compressible flows. Journal of Computational and Theoretical Nanoscience 3(4):579–587 Tölke J, Krafczyk M, Schulz M, Rank E (2000) Discretization of the Boltzmann-Equation in velocity space using a Galerkin approach. Journal of Computer Physics Communications 129:91–99 Tölke J, Fahrig T, Nachtwey B, Krafczyk M (2003) Computational Steering in Civil Engineering. IKM Conference, Weimar Trolltech (2005) Klassenbibliothek Qt (http://www.trolltech.com/products/qt/index.html) UNIQA Versicherungen AG (2004) UNIQA Tower (http://tower.uniqa.at/) VISENSO GmbH (2005) VISiT Projekt / basierend auf COVISE (http://www.visenso.de/) Wassermann K (1996) Integration raum- und bauteilorientierter Daten in der Gebäudeplanung in einem zentralen Objektmodell. Hartmann D (Hrsg), Bochum Wender K, Hübler R, Willenbacher H (2006) Information retrieval in Building Life Cycle Modular navigation tools for a dynamic integration base. Joint International Conference on Computing and Decision Making in Civil and Building Engineering, Montreal, Canada Willenbacher H, Hübler R, Wender K (2006) GIS functionality for building model integration and analysis. ICCCBE-XI, Montreal, Canada Wooldridge M und Jennings NR (1994) Agent Theories, Architectures, and Languages: A Survey, Intelligent Agents. ECAI-94 Workshop on Agent Theories, Architecture, and Languages. Springer-Verlag, Amsterdam, Netherlands World Wide Web Consortium (W3C) (1996) XML – Extensible Markup Language Zhuang L (2006) An Automatic Mesh Generator for a Computational Steering Framework. Studienarbeit, TU Braunschweig

4 Volumenorientierte Modellierung als Grundlage einer vernetzt-kooperativen Planung im Konstruktiven Ingenieurbau

Ernst Rank, Richard Romberg, Andreas Niggl Technische Universität München, Lehrstuhl für Bauinformatik {rank | romberg | niggl}@inf.bv.tum.de

Hans-Joachim Bungartz, Ralf-Peter Mundani Technische Universität München, Institut für Informatik {bungartz | mundani}@in.tum.de

4.1 Einführung Planung im Konstruktiven Ingenieurbau geschieht in einer kooperativen Zusammenarbeit verschiedener Personen, die raum-zeitlich verteilt arbeiten und aus unterschiedlichen Fachdisziplinen stammen. Zusätzlich ist zu erkennen, dass die beteiligten Planer ein Modell meist gleichzeitig in unterschiedlichen Detaillierungsstufen bearbeiten müssen. Derzeitige Anwendungen und die darin verwendeten Datenmodelle sind in der Regel nur für den isolierten Einsatz in einem bestimmten Fachbereich entwickelt worden. Für die Verwendung in einer kooperativen Arbeitsumgebung sind diese daher strukturell nur bedingt geeignet. Aus dieser Motivation heraus wird in dem hier vorliegenden Beitrag ein neuer Ansatz vorgeschlagen, in welchem im Bereich des Konstruktiven Ingenieurbaus als Grundlage der kooperativen Arbeit durchgängig ein strikt dreidimensionales, volumenorientiertes Modell verwendet werden soll. Grundlegende Annahme ist, dass die kooperative Arbeit verschiedener Planer über ein gemeinsames, zentral verwaltetes Modell organisiert werden soll. Dieses liegt als attributiertes, geometrisches Modell des Gesamtsystems vor, wobei bei Bedarf Teilmodelle und Sichten davon abgeleitet werden. Insbesondere bei konkurrierenden Zugriffen kann damit eine Konsistenz  geometrisch sowie mecha-

296

E. Rank, H.-J. Bungartz, R. Romberg, R.-P. Mundani, A. Niggl

nisch  des Datenbestandes besser gewährleistet werden. Für die Organisation dieses Modells sowie in den verwendeten Berechnungsverfahren spielen vor allem Konzepte der Hierarchie, der Graphentheorie sowie Finite-Elemente-Methoden hoher Ordnung eine wichtige Rolle. 4.1.1 Rechnen am Gesamtsystem im Konstruktiven Ingenieurbau Grundlegendes Ziel dieses Beitrags ist die Verbesserung einer kooperativen Zusammenarbeit vor allem im Hinblick auf die Tragwerksplanung im Konstruktiven Ingenieurbau. Zwei Punkte stehen hierbei im Zentrum der Diskussion: eine strikte Modellierung mittels volumenbasierter Strukturen und das Rechnen am Gesamtsystem. Das in der Tragwerksplanung übliche Vorgehen besteht darin, Gebäude in einzelne Tragstrukturen zu untergliedern und diese weitgehend unabhängig voneinander zu berechnen und zu bemessen. Dabei kommen für jeden Typ von Tragstruktur unterschiedliche Verfahren und Programme zum Einsatz. Die anzunehmenden Lasten werden durch Idealisierung des Gesamtmodells beziehungsweise durch sukzessive Übernahme von Lasten und Gegenkräften von oben durch das ganze Tragwerk hindurch bis zu den Auflagern bestimmt. Dieses primär sequenzielle Vorgehen erschwert jedoch eine parallele Arbeitsweise seitens verschiedener Planer. Aufgrund der Vielzahl unterschiedlicher Tragwerkssysteme lassen sich diese Aufgaben auch nur schwer automatisieren. Ganz besonders deutlich werden die Nachteile, wenn Änderungen am System vorgenommen werden müssen. In diesem Falle müssen alle Abhängigkeiten wiederum neu überprüft und die betroffenen Tragwerksteile nochmals neu durchgerechnet werden. Die stete Betrachtung eines Bauwerks am Gesamtmodell stellt gegenüber einer klassischen Vorgehensweise mittels Positionsstatik einen umfassenderen Ansatz in der Berechnung von Tragwerksstrukturen dar. Es ist dabei zu beobachten, dass in der Praxis zunehmend Bedarf besteht, Gebäude als Ganzes zu modellieren und zu berechnen. Prinzipiell ist natürlich ein höherer Aufwand damit verbunden, das Modell im Ganzen zu erstellen. Die Vorteile, die sich dann jedoch hinsichtlich des gesamten Planungsprozesses ergeben, überwiegen diesen Aufwand bei weitem:

x Sicherung der Konsistenz: Durch die Modellierung des Systems als Ganzes kann die Konsistenz des Datenbestandes besser gewährleistet werden. Um etwaige geometrische Fehler – Überschneidungen sowie unerwünschte Spalten – automatisch zu detektieren, wurde hierzu ein Verfahren entwickelt (Mundani 2006). Neben einer geometrischen Konsistenz ist durch die Berechnung am Gesamtsystem jederzeit auch eine mechanische Konsistenz sichergestellt. x Erkennen komplexer Tragwirkungen: Bei einer Berechnung mittels Positionsstatik müssen die gegenseitigen Abhängigkeiten (Lasten) immer vom Ingenieur, meist manuell, berücksichtigt werden. Bei komplexen Tragwerksstrukturen können eventuell vorhandene Tragwir-

Volumenorientierte Modellierung zur vernetzt-kooperativen Planung

297

kungen jedoch sehr leicht übersehen werden, was unter Umständen zu völlig falschen Lastannahmen und Ergebnissen führen kann. x Änderungsmanagement: Ist das Tragwerksmodell einmal komplett aufgebaut, lassen sich Änderungen sehr leicht übernehmen und die sich daraus ergebenden Auswirkungen schneller untersuchen. Dies führt zu einer erheblichen Zeitersparnis, insbesondere, wenn mehrere Personen an einem Projekt gemeinsam arbeiten. x Visuelle Darstellung: Die Möglichkeit einer umfassenden visuellen Darstellung der gesamten Struktur ist nicht zu unterschätzen. Im Umgang mit anderen Planungsbeteiligten, aber auch mit Bauherren, kann eine Visualisierung der Tragstruktur ein wichtiges Hilfsmittel zur Kommunikation und zur Darstellung komplexer Sachverhalte sein. Ergebnisse lassen sich anderen Personengruppen leichter zugänglich machen, wodurch Entscheidungen schneller getroffen werden können und so die kooperative Zusammenarbeit wesentlich verbessert werden kann. Dieser Umstand ist dabei nicht nur im Bereich der Tragwerksplanung, sondern auch bei der Darstellung von Bauabläufen im Rahmen einer so genannten 4Doder nD-Modellierung von großem Interesse. Siehe hierzu auch in einem späteren Abschnitt. Grundsätzlich ist zu betonen, dass der Ansatz, alle Berechnungen immer am Gesamtsystem durchzuführen, erheblich höhere Anforderungen an ein Softwaresystem stellt, insbesondere was die Fähigkeiten der Darstellung, der Interaktion mit dem Modell und die verwendeten Datenstrukturen und Berechnungsverfahren betrifft. Wir sind davon überzeugt, dass die in diesem Projekt vorgestellten Konzepte der Hierarchie und der Einbettung von Simulationsaufgaben einen wichtigen Beitrag dazu leisten, effiziente und flexible Softwaresysteme zu entwickeln, die nicht nur diesen Anforderungen gerecht werden, sondern darüber hinaus Untersuchungen am Gesamtsystem trotz der damit verbundenen hohen Komplexität erst erlauben.

4.2 Vom Bauwerksmodell zur volumenorientierten Tragwerksanalyse Bevor in den nachfolgenden Abschnitten die in diesem Projekt erzielten Ergebnisse sowie damit erworbenen Erkenntnisse im Detail vorgestellt werden, sind hier noch einmal alle durchgeführten Schritte kurz aufgeführt:

x Generierung eines Volumenmodells auf Grundlage der IFC x Entwicklung eines oktalbaumbasierten Frameworks als Kooperationsgrundlage zur Regulierung konkurrierender Zugriffe und globalen Konsistenzsicherung einer gemeinsam benutzen Datenbasis

298

E. Rank, H.-J. Bungartz, R. Romberg, R.-P. Mundani, A. Niggl

x Entwicklung einer echtzeitfähigen Kollisionserkennung für unterschiedliche x x x x

Inkonsistenzfälle (Überschneidung, Spalt und Kontakt) des geometrischen Modells Entwicklung agentenbasierter Benachrichtigungsdienste zur Kommunikation von Änderungen am zu Grunde liegenden Modell Entwicklung einer graphbasierten Dekomposition als Vernetzungsgrundlage für die Struktursimulation (p-Version FEM) Hierarchische Organisation der Struktursimulation zur Einbettung ins Framework sowie zur Steuerung der Berechnung Entwicklung einer 4D-Bauphasensimulation auf Grundlage der Steuerung der Berechnung

4.2.1 Ein standardisiertes Bauwerksmodell als Grundlage Die von der International Alliance for Interoperability (IAI 2006) ins Leben gerufenen Industry Foundation Classes (IFC) stellen eine wichtige Grundlage des Datenaustauschs im Bauwesen dar. Ziel der IAI ist es, einen einheitlichen Standard für die digitale Beschreibung von Informationen, die während der gesamten Lebensdauer eines Bauwerks anfallen können, zu schaffen. Das Objektmodell der IFC enthält dabei unter anderem Beschreibungen für die Gebäudestruktur, Räume, Bauelemente und deren gegenseitige Abhängigkeiten und Attribute. Die IFC bieten eine gute Basis für die Beschreibung und den Austausch von Produktmodelldaten, die beispielsweise als Ausgangspunkt für weitergehende Aufgaben wie einer Simulation des Ressourcenbedarfs von Bauwerken dienen können (Wassouf et al. 2006). Für numerische Simulationen ist jedoch eine direkte Verwendung der IFC oft mit Schwierigkeiten verbunden. Das Produktmodell der IFC basiert auf einer komponentenorientierten Sichtweise einzelner Bauteile, wobei für die geometrische Form unterschiedliche Darstellungen möglich sind (Produktionsmodelle, Constructive Solid Geometry, Halbraummodelle). Eine Wand kann zum Beispiel durch die Parameter Grundlinie, Dicke und Stockwerkshöhe beschrieben sein. Für eine numerische Simulation ist aber eine andere Darstellung der Geometrie, meist in Form einer Oberflächen- (B-Rep) oder zellbasierten Darstellung Voraussetzung. Um etwa Randbedingungen setzen zu können, ist es zudem nötig, dass neben den Objekten selbst auch ihre Begrenzungsflächen oder Kanten unmittelbar zugänglich sind. Für derartige Simulationsaufgaben müssen die Daten der IFC daher zunächst ausgewertet und in eine explizite geometrische Form überführt werden. Eine Konvertierung vor jedem einzelnen Simulationsdurchlauf ist jedoch in der Regel sehr aufwändig. Weiterhin ist diese Umwandlung der geometrischen Daten nicht immer eindeutig und birgt somit die Gefahr einer unterschiedlichen Interpretation in verschiedenen Anwendungsprogrammen. Aus diesem Grunde wird in diesem Beitrag als Grundlage der Kooperation innerhalb verschiedener Simulationsanwendungen ein explizites geometrisches Volumenmodell verwendet. Dieses wird zu Beginn verschiedener Simulationsdurch-

Volumenorientierte Modellierung zur vernetzt-kooperativen Planung

299

läufe aus einem standardisierten Bauwerksmodell abgeleitet (Romberg 2005, Romberg et al. 2004). Dabei werden Bauteile der IFC in geometrische B-Rep Objekte umgewandelt, semantische Objektinformationen werden als Attribute übernommen und über einen eindeutigen Objektschlüssel in einer korrespondierenden Datenbank gespeichert. 4.2.2 Analyse und Aufbereitung der Gebäudestruktur Es zeigt sich, dass die topologische Struktur eine zentrale Grundlage für die Unterstützung kooperativer Arbeit im Konstruktiven Ingenieurbau darstellt. Erst mit dem Wissen aller Nachbarschaftsbeziehungen zwischen Objekten lassen sich weitere Schritte wie eine Vernetzung für die Finite-Elemente-Berechnung, eine Erkennung von Räumen oder effektive Lösungsverfahren realisieren. Auch konkurrierende Zugriffe verschiedener Bearbeiter lassen sich nur dann sinnvoll organisieren, wenn die topologischen Abhängigkeiten zwischen den bearbeiteten Objektmengen genau bekannt sind. In dem hier vorgestellten Ansatz werden dazu vier verschiedene Typen von Relationen definiert (Abb. 4.1):

x Bauteilgraph: Dieser beschreibt Relationen zwischen Bauteilen, die in einer bestimmten Form (vollflächig, an einer Kante, an einem Knoten) geometrisch benachbart sind. x Verbindungsgraph: Dieser definiert Nachbarschaften in einem so genannten Verbindungsmodell, welches aus dem ursprünglichen IFC-Modell abgeleitet wurde und als gemeinsamer Startpunkt verschiedener Analysen dient. x Raumflächengraph: Dieser beschreibt Beziehungen zwischen Bauteilflächen und stellt eine Grundlage zur Erkennung von Räumen dar. x Raumgraph: Dieser beschreibt Relationen zwischen einzelnen Räumen.

Abb. 4.1. Bauteilgraph (links), Raumflächengraph (Mitte), Raumgraph (rechts)

300

E. Rank, H.-J. Bungartz, R. Romberg, R.-P. Mundani, A. Niggl

Die Bedeutung der topologischen Beziehungen in einem Gebäudemodell geht weit über den Konstruktiven Ingenieurbau hinaus. In (van Treeck 2004) wurde aufbauend auf dem hier entwickelten Modell eine thermische Gebäudeanalyse durchgeführt. Dazu müssen für die Diskretisierung des Strömungsgebietes Räume als geometrische Objekte im Bauwerksmodell identifizierbar sein. Grundlage des von van Treeck vorgestellten Verfahrens sind die in Abb. 4.1 dargestellten Nachbarschaftsbeziehungen. Räume und Bauteile können damit als explizite Objekte parallel in einem Bauwerksmodell vorgehalten werden. Insgesamt ist es möglich, auf der Grundlage der topologischen Gebäudestruktur verschiedenartige Simulationsaufgaben zu bedienen. Durch die Möglichkeit der Ableitung der jeweiligen topologischen „Sichten“ aus einem gemeinsamen Gesamtmodell ist aber eine Konsistenz zu jeder Zeit gegeben. Bevor sich die obigen topologischen Beziehungen herstellen lassen, muss die Gebäudestruktur in geeigneter Weise aufbereitet werden. Oft sind jedoch aufgrund von Rundungsfehlern oder Ungenauigkeiten in der Modellierung saubere geometrische Übergänge zwischen einzelnen Bauteilen nicht immer gegeben. Bauteile können sich überschneiden, daneben können aber auch kleine Abstände zwischen Objekten vorhanden sein. Geringe Abstände lassen sich jedoch mit herkömmlichen Verfahren der Kollisionserkennung nicht mehr aufspüren. Um aber auch derartige Inkonsistenzen erkennen zu können, wurde ein Verfahren entwickelt, mit dem sich gleichzeitig Überschneidungen und Spalten zwischen Objekten detektieren lassen (Mundani 2006). Siehe hierzu auch den entsprechenden Abschnitt in diesem Bericht. 4.2.3 Dekomposition und Vernetzung des Modells Zum Aufbau der topologischen Struktur wird das geometrische Bauwerksmodell zunächst in ein so genanntes Verbindungsmodell zerlegt. Dieses Modell enthält zwei Klassen von Objekten, die einige wichtige Eigenschaften hinsichtlich der weiteren Vorgehensweise besitzen. Um das Modell zu erzeugen, werden zwischen benachbarten Objekten dazu mittels Boolescher Operationen so genannte Verbindungsobjekte abgespalten, sodass Nachbarschaftsbeziehungen nur noch über eindeutige gemeinsame Flächen gegeben sind. Die resultierenden Differenzobjekte haben damit keine vollflächigen Verbindungen mehr, sodass diese, was die gemeinsamen Flächen betrifft, voneinander isoliert sind. Details des Verfahrens und exakte Definitionen der Objekte sind in (Romberg 2005) zu finden. Die Eigenschaft der Trennung von Differenzobjekten kann nun bei der Generierung des Finite-Elemente-Netzes ausgenutzt werden, indem diese zunächst unabhängig voneinander vernetzt werden und die Konformität des Netzes allein über die dazwischen liegenden Verbindungsobjekte sichergestellt werden kann. Abbildung 4.2 zeigt beispielhaft die Zerlegung einer Raumecke. Für das weitere Vorgehen nehmen wir an, dass Verbindungsobjekte eine hexaederartige Struktur aufweisen, während Differenzobjekte als Extrusionskörper eines ebenen, polygonalen Gebietes beschrieben werden können. Diese Annahme gilt zwar nicht für völlig allgemeine Strukturen, für die hier betrachteten typischen

Volumenorientierte Modellierung zur vernetzt-kooperativen Planung

301

Gebäudemodelle, bestehend aus Platten, Scheiben oder Stützen, ist sie aber in der Regel erfüllt.

Abb. 4.2. Zerlegung von drei benachbarten Objekten in Verbindungs- und Differenzobjekte

Der Algorithmus der Vernetzung folgt einer zweistufigen Strategie, um ein kompatibles Netz für die gesamte Bauwerksstruktur zu erzeugen. Zunächst werden alle zerlegten Objekte unabhängig voneinander vernetzt, wobei je nach geometrischer Form der Struktur unterschiedliche Verfahren zur Anwendung kommen. Die plattenartigen Differenzobjekte werden mithilfe eines 2D-Flächenvernetzers mit Extrusion in z-Richtung, die stabartigen Strukturen der Differenzobjekte unter Verwendung spezieller Makros vernetzt. In einem zweiten Schritt wird auf den Verbindungsobjekten, die an der Begrenzung zweier Differenzobjekte liegen, eine kompatible Einteilung bestimmt. Diese Einteilung wird als Rand-Zwangsknoten auf die Differenzobjekte übertragen, die danach ein zweites Mal vernetzt werden. Abbildung 4.3 zeigt schließlich das Finite-Elemente-Netz eines mit diesem Verfahren diskretisierten komplexen Bauwerks.

Abb. 4.3. Finite-Elemente-Modell eines mehrstöckigen Gebäudes bestehend aus 11.762 Hexaederelementen

302

E. Rank, H.-J. Bungartz, R. Romberg, R.-P. Mundani, A. Niggl

4.2.4 Die p-Version der FEM zur Berechnung volumenbasierter Strukturen Die statische Berechnung des Bauwerksmodells erfolgt in dieser Arbeit unter Verwendung höherpolynomialer Ansätze der so genannten p-Version der FEM (Szabó u. Babuska 1991, Szabó et al. 2004). Diese hat gegenüber einem klassischen Vorgehen, bei dem nur lineare oder quadratische Elementansätze verwendet werden, einige entscheidende Vorteile. Elemente niedriger Ordnung der h-Version müssen, damit eine ausreichende Genauigkeit gewährleistet werden kann, ungefähr gleiche Seiten aufweisen. Für eine strikt volumenorientierte Modellierung müsste bei den in Bauwerksstrukturen vorhandenen stab- und plattenartigen Bauteilen hierzu eine sehr hohe Anzahl von Elementen verwendet werden. Zudem müssten in der Regel immer mehrere Elemente in einer Schicht angeordnet werden, um zumindest eine lineare Spannungsverteilung über die Dicke darstellen zu können. Da die somit sehr hohe Anzahl an Elementen einen kaum zu rechtfertigenden Aufwand mit sich bringen würde, werden zur Berechnung von Bauwerksstrukturen üblicherweise immer dimensionsreduzierte Modelle mit Platten- oder Schalenelementen verwendet. Elemente höherer Ordnung verhalten sich im Gegensatz dazu hinsichtlich großer Seitenverhältnisse (bis zu 1:1000) sehr robust. Komplexe Spannungsverläufe innerhalb einer Elementschicht können zudem leicht dargestellt und beliebig in der Genauigkeit angepasst werden. Mit Hilfe der p-Version der FEM ist es damit möglich, sehr effizient gemischt dick- und dünnwandige Strukturen einheitlich mit Volumenelementen zu berechnen (Düster et al. 2001). Eine weitere Verbesserung des Verfahrens ergibt sich zudem durch Verwendung anisotroper Ansätze (Düster 2001), bei denen sich der Polynomgrad in die verschiedenen Raumrichtungen je nach Genauigkeitsanforderung anpassen und auch adaptiv steuern (Scholz et al. 2006) lässt. Die Anwendung der p-Version der FEM erlaubt daher, auch große Bauwerksstrukturen einheitlich mit Volumenstrukturen zu berechnen. Damit ist keine Unterscheidung hinsichtlich verschiedener dimensionsreduzierter Modelle mehr zu treffen, die mit aufwändigen Kopplungselementen zu einem Gesamtsystem zusammengefügt werden müssten. Die Gefahr von Modellierfehlern lässt sich verringern, da die Auswahl des richtigen mechanischen Modells nicht mehr vor der Berechnung getroffen werden muss – was prinzipiell ja erst nach der Berechnung möglich wäre. Diese Eigenschaft ist insbesondere bei Veränderungen am System von großem Vorteil, da immer dasselbe mechanische Modell verwendet werden kann. Die Verwendung eines einheitlichen Modells ist zudem vorteilhaft, wenn Größen von einem Bauzustand zum nächsten übernommen werden müssen. Ein weiterer Vorteil, der insbesondere aus der Möglichkeit erfolgt, lokal den Polynomgrad der Ansatzfunktionen zu erhöhen, besteht darin, dass bei Untersuchungen verschiedener Detaillierungsgrade kein Wechsel des Modells notwendig ist. Eine aufwändige Übernahme beispielsweise von Lasten vom globalen ins lokale System sowie von Ergebnissen wieder zurück ist nicht mehr nötig. Damit kann wesentlich leichter eine Konsistenz auch zwischen verschiedenen Detaillie-

Volumenorientierte Modellierung zur vernetzt-kooperativen Planung

303

rungsgraden gewährleistet werden, was vor allem dann von großer Bedeutung ist, wenn verschiedene Bearbeiter gleichzeitig an einem Modell arbeiten. 4.2.5 Volumenmodellierung im Konstruktiven Ingenieurbau Wesentliche Fragen stellen sich bei volumenorientierten Berechnungen hinsichtlich der Bemessung im Stahlbetonbau. Hier ist zunächst festzustellen, dass die realen Spannungsverhältnisse im Verbundbaustoff Stahlbeton bei höheren Belastungen grundsätzlich von denen einer linearelastischen Berechnung abweichen. Während die Druckspannungen vom Beton aufgenommen werden, konzentrieren sich die Zugspannung weitgehend auf die Stahleinlage. Für eine Bemessung nach Standardverfahren kann dieser innere Spannungszustand aus den Schnittgrößen (Normalkraft und Moment) am Querschnitt abgeleitet werden. Voraussetzung ist jedoch, dass die Gültigkeit der Bernoulli-Hypothese vom Ebenbleiben der Querschnitte ausreichend genau erfüllt ist. Dies tritt im Wesentlichen bei Strukturen mit annähernd gleich bleibender Dicke und gleich verteilten Lasten auf. Man spricht in diesem Fall auch von so genannten B-Zonen (Bernoulli-Zonen) innerhalb eines Tragwerks (Schlaich u. Schäfer 2001). In allen anderen Fällen (Scheiben, Volumenstrukturen) ist aufgrund der primär unbekannten Dehnungsverteilung eine unmittelbare Bestimmung des inneren Spannungszustandes aus Querschnittsgrößen nicht mehr möglich. In diesen Fällen mit diskontinuierlicher Spannungsverteilung werden üblicherweise in der Praxis konstruktive Bemessungsregeln angewandt oder es wird ein innerer Spannungszustand mithilfe eines Stabwerkmodells nachgebildet, welches die Zug- und Druckkräfte innerhalb des Betons bzw. Stahls repräsentiert. Die Modellierung der Stabwerke soll sich dabei primär an den Hauptzug- und Druckspannungen einer Berechnung nach der linearen Elastizitätstheorie orientieren (Schlaich u. Schäfer 2001). Geht man von einer durchgängigen Volumenorientierung aus, ist es natürlich kein Problem, die für das Standardbemessungsverfahren notwendigen Querschnittswerte aus den dreidimensionalen Spannungsgrößen durch Integration zu bestimmen. Aus der strikt volumenorientierten Herangehensweise ergeben sich nun aber zusätzliche Möglichkeiten. So lässt sich aus den Ergebnissen der Berechnung zunächst die grundlegende Annahme vom Ebenbleiben der Querschnitte überprüfen. Abbildung 4.4 zeigt dazu ein Beispiel, in dem diejenigen Bereiche gekennzeichnet sind, in denen die tatsächlichen Spannungen um mehr als 5 Prozent von einem linearen, mit den berechneten Spannungen im Gleichgewicht stehendem Verlauf, abweichen. Die Reduktion der dreidimensionalen Spannungsgrößen auf Querschnittsgrößen ist prinzipiell ein Postprocessing-Schritt, der nach einer Finite-ElementeBerechnung mit entsprechenden Algorithmen in Echtzeit und interaktiv stattfinden kann. Hierzu wurden Verfahren implementiert, die die Form einer Struktur erkennen und die entsprechenden Querschnittsgrößen vorschlagen.

304

E. Rank, H.-J. Bungartz, R. Romberg, R.-P. Mundani, A. Niggl

Abb. 4.4. Darstellung von Bereichen mit mehr als 5 Prozent Abweichung vom linearen Spannungsverlauf über dem Querschnitt

Aufgrund der Tatsache, dass die Dimensionsreduktion nicht mehr vor, sondern nach einer Berechnung stattfindet, ergibt sich ein entscheidender Vorteil: Der Ingenieur ist nicht mehr auf ein Modell festgelegt. Er kann die Spannungen auf beliebige integrale Größen reduzieren. Dies ist insbesondere dann von großer Bedeutung, wenn sich durch Modifikationen an der Struktur die Voraussetzungen für ein bestimmtes Modell ändern. Beispielsweise kann es passieren, dass bei Änderung der Höhe eines Unterzuges dieser nicht mehr als Balken, sondern als Scheibe bemessen werden muss. Sind die Größen primär immer im 3D-Spannungszustand gegeben, ist in diesem Falle nur noch eine andere Art der Ergebnisauswertung vorzunehmen. In Bereichen mit diskontinuierlichen Dehnungsverteilungen über dem Querschnitt der so genannten D-Zonen sind die Ergebnisse aus der volumenorientierten Berechnung Ausgangspunkt für das weitere Vorgehen. Hierzu existieren verschiedene Methoden, die auch eine teilweise automatische Generierung von Stabwerkmodellen erlauben (Rückert 1992).

4.3 Oktalbaumbasiertes CSCW-Framework Als zentrale Instanz zur Koordination und Organisation der Kooperation wurde ein oktalbaumbasiertes Framework entwickelt, das Zugriffe und globale Konsistenz gemeinsam benutzter Ressourcen in einer verteilten Arbeitsumgebung sicherstellt. Dazu wurde ein neuartiges Verfahren zur Generierung volumenorientierter Modelle entwickelt, das neben der Echtzeitfähigkeit auch eine Generierung onthe-fly erlaubt, sodass die Ergebnisdaten bereits zur Laufzeit in nachgeschalteten Applikationen weiterverwendet werden können. Eine darauf basierende Anwendung und zugleich Kernstück des Frameworks ist die Kollisionserkennung zur Detektion geometrischer Inkonsistenzen modifizierter Bauteile. 4.3.1 Generierung von Oktalbäumen Oktalbäume sind gegenüber anderen raumpartitionierenden Verfahren im Hinblick auf Speicherbedarf, Adaptivität, Flexibilität und Zellzugriff konzeptionell überlegen. Leider scheitern bekannte Verfahren zur Generierung von Oktalbäumen bei

Volumenorientierte Modellierung zur vernetzt-kooperativen Planung

305

feinen Auflösungen, d. h. mehreren Millionen Zellen, oftmals an sehr langen Laufzeiten, sodass diese für eine Generierung in Echtzeit nicht infrage kommen. Hier wurde im Projekt ein neues Verfahren basierend auf dem Durchschnitt von Halbräumen entwickelt (Mundani et al. 2003), das eine Generierung in Echtzeit erlaubt. Beispielsweise benötigt das Volumenmodell mit fünf Stockwerken eines Bürogebäudes (Zentrale der UNIQA-Versicherung in Wien) auf einer Tiefe von 8 – dies entspricht einer Auflösung von 256 Zellen je Raumrichtung bei äquidistanter Diskretisierung – gerade 0,289 s bei 944.980 Oktalbaumzellen bzw. auf einer Tiefe von 10 – dies entspricht einer Auflösung von 1.024 Zellen je Raumrichtung bei äquidistanter Diskretisierung – gerade 5,426 s bei 18.930.087 Oktalbaumzellen. Selbst bei einer Tiefe von 14 – dies entspricht einer Auflösung von 16.384 Zellen je Raumrichtung bei äquidistanter Diskretisierung bzw. einer Auflösung von ca. 1 mm pro Zelle bei einer Modelllänge von 20 m – konnte das Volumenmodell mit seinen 4.957.041.321 Oktalbaumzellen problemlos berechnet werden, obgleich derartig feine Auflösung zurzeit nur für Simulationsaufgaben infrage kommen, für deren Ausführung auch Rechner mit einer hinreichend großen Rechenleistung zur Verfügung stehen. Durch eine gleichzeitige Linearisierung der Oktalbäume können diese nicht nur Platz sparend gespeichert, sondern auch als Binärstrom kodiert bereits zur Laufzeit in nachgeschalteten Applikationen für weitergehende Berechnungen eingesetzt werden (Mundani et al. 2004a). Dazu werden die drei Zelltypen des Oktalbaums Innen (Inhalt eines Körpers), Rand (Oberfläche eines Körpers) und Aussen (Rest) auf entsprechende Binärdarstellungen abgebildet und mithilfe eines depthfirst-Baumdurchlaufs (Tiefensuche) in Präfixnotation gespeichert. Da sich diese Binärströme formal durch eine Chomsky-2-Grammatik beschreiben lassen, können sie durch entsprechende Kellerautomaten schnell und effizient – insbesondere zur Laufzeit der Oktalbaumgenerierung – verarbeitet und auf Fehler (etwa durch „Bitkipper“ bei der Übertragung über ein Netzwerk) hin untersucht werden (Mundani 2006). 4.3.2 Kollisionserkennung und globale Datenkonsistenz Als eine der fundamentalen Komponenten des Frameworks ist die oktalbaumbasierte Kollisionserkennung zu benennen. Kollisionen zwischen Bauteilen können dabei in drei unterschiedlichen Fällen auftreten: Überschneidung, Spalt und Kontakt. Während die Überschneidung von Bauteilen unmittelbar als Kollision zu verstehen ist, sind die beiden Fälle Spalt und Kontakt stark vom Kontext abhängig. Generell existiert zwischen zwei disjunkten Bauteilen immer ein Spalt, jedoch ist dieser nicht grundsätzlich als Kollision (z. B. zwei gegenüberliegende Wände) zu verstehen. Hier ist also Zusatzwissen (durch den Benutzer) erforderlich, um einen Spalt automatisch durch das Framework als Kollision zu identifizieren. Ähnliches gilt für den Fall Kontakt, der – wie bereits der Typ Spalt – im geometrischen Modell erwünscht oder aber auch unerwünscht sein kann. Im vorliegenden Anwendungsfall ist der Typ Kontakt sogar notwendig, um damit topologische Beziehungen (siehe Abschnitt 4.2.2) aufbauen zu können.

306

E. Rank, H.-J. Bungartz, R. Romberg, R.-P. Mundani, A. Niggl

Abb. 4.5. Kollisionsüberprüfung am geometrischen Modell – hier wurde ein Spalt der Größe 0,5 mm zwischen den hervorgehobenen Bauteilen gefunden

Die Kollisionsdetektion zwischen zwei Bauteilen wird dabei mithilfe der zugehörigen volumenorientierten Darstellungen durchgeführt. Eine Anwendung des Booleschen Operators Durchschnitt auf zwei als Binärstrom vorliegenden Bauteilen liefert gerade das Ergebnis der Kollisionsdetektion. Enthält dieses eine Zelle vom Typ Innen, so liegt eine Überschneidung vor. Praktisch kann nach dem ersten Auftreten einer Zelle vom Typ Innen die Kollisionserkennung abgebrochen werden. Enthält das Ergebnis keine Zellen vom Typ Innen, aber dafür vom Typ Rand, so besteht ein Kontakt zwischen den beiden Bauteilen. Ein Kontakt kann dabei zwischen zwei Flächen, einer Fläche und einer Kante oder einer Ecke, einer Kante und einer Ecke sowie zwischen zwei Kanten oder zwei Ecken auftreten. Da der Typ Kontakt im vorliegenden Anwendungsfall gerade den Idealzustand darstellt, wird er nicht als Kollision gewertet. Eine Identifizierung dieses Falls ist aber durch die Kollisionsdetektion möglich. Eine Kollision vom Typ Spalt liegt genau dann vor, wenn das Ergebnis der Kollisionsdetektion nur Zellen vom Typ Aussen enthält. Hier kann durch Unterbzw. Überschreitung einer vom Benutzer vorgegebenen Mindestspaltbreite selbstständig entschieden werden, ob ein Spalt als Kollision zu identifizieren ist. Dies filtert zwar einen Großteil der auftretenden Spalte heraus, entbindet jedoch nicht vor einer Rückfrage beim Benutzer, da ein Spalt durchaus erwünscht, d. h. absichtlich modelliert worden sein kann. Unerwünschte Spalte zwischen Bauteilen sind insofern besonders störend, da sie topologische Beziehung beeinträchtigen und somit eine korrekte Vernetzung des Gesamtmodells zur statischen Analyse behindern. Soll für ein modifiziertes Bauteil festgestellt werden, ob eine Verletzung der globalen Konsistenz vorliegt, so muss dieses mit allen übrigen Bauteilen hinsicht-

Volumenorientierte Modellierung zur vernetzt-kooperativen Planung

307

lich potenzieller Kollisionen untersucht werden. Wird hier die Boolesche Operation zur Steuerung der Oktalbaumgenerierung verwendet anstatt a priori die beiden Binärströme zu berechnen und im Anschluss miteinander zu verknüpfen, so lässt sich für die Kollisionsdetektion neben einer on-the-fly-Berechnung die bereits oben gestellte Forderung nach Echtzeit auch hier erfüllen (Mundani 2006). Das fünfstöckige Modell des UNIQA-Towers besteht bspw. aus 216 Bauteilen. Eine Komplettüberprüfung, d. h. jedes Bauteil mit allen übrigen 215 Bauteilen, benötigt bei einer Auflösung von 2,5 mm pro Zelle (Tiefe 13) gerade 12,565 Sekunden. Die Überprüfung eines Bauteils mit allen übrigen 215 Bauteilen benötigt bei einer Auflösung von 0,3 mm pro Zelle (Tiefe 16) gerade 3,459 Sekunden. Um eine globale Konsistenz des zu Grunde liegenden Modells durch das Framework zu gewährleisten, werden (lokal) modifizierte Bauteile, die persistent (zur globalen Sichtbarkeit) gespeichert werden sollen, stets einer Kollisionsdetektion unterworfen. Wird dabei eine Kollision zwischen dem modifizierten Bauteil und einem anderen Bauteil des Modells festgestellt, so wird der Benutzer unter Angabe der interferierenden Bauteile sowie dem identifizierten Kollisionstyp auf diesen Umstand hingewiesen und eine Überschreibung des obsoleten Bauteils durch seine modifizierte Version verweigert. Im Fall des Kollisionstyps Spalt kann eine Überschreibung nach Rückfrage beim Benutzer durch dessen explizite Freigabe erfolgen. 4.3.3 Regulierung von Zugriffen Um die Zugriffe auf die gemeinsam benutzte Datenbasis effizient durch das Framework zu regulieren, wurde ein dem CVS verwandtes Verfahren entwickelt (Mundani et al. 2004b). Ein Benutzer kann dabei mittels check-out lokale Kopien von Teilen des zu Grunde liegenden Gebäudemodells erstellen und diese je nach gewählter Zugriffsart – nur lesend, schreibend oder exklusiv schreibend – lokal modifizieren. Zur persistenten Speicherung und globalen Sichtbarkeit lokaler Änderungen können diese mittels check-in an das Framework zurückgeschrieben werden. Um dabei die globale Konsistenz nicht zu verletzen, müssen modifizierte Bauteile zuerst oben aufgeführte Kollisionsüberprüfung durchlaufen. Sollte keine Kollision festgestellt worden sein, so werden die obsoleten Versionen der Bauteile durch ihre neuen Versionen überschrieben. Andernfalls wird die Speicherung verweigert (Überschneidung) oder erfolgt erst nach Rückfrage und Freigabe durch den Benutzer (Spalt). 4.3.4 Agentenbasierte Benachrichtigungsdienste Zur weiteren Unterstützung der Kooperation wurden agentenbasierte Benachrichtigungsdienste entwickelt, die Transparenz hinsichtlich gemeinsam benutzter Ressourcen schaffen (Mundani et al. 2004b). Wird die lokale Kopie eines Bauteils vorgehalten, so bleiben globale Änderungen an diesem Bauteil lokal unsichtbar, bis der Benutzer das nächste Mal auf die globale Instanz dieser Ressource zu-

308

E. Rank, H.-J. Bungartz, R. Romberg, R.-P. Mundani, A. Niggl

greift. Mithilfe agentenbasierter Benachrichtigungsdienste lassen sich globale Modifikationen lokal vorgehaltener Bauteile einfach verfolgen, filtern und dem jeweiligen Benutzer mitteilen. Ein Agent überwacht dabei für sämtliche in Kopie vorgehaltenen Bauteile deren globalen Zustand. Sollte sich dieser durch Modifikationen seitens anderer Benutzer ändern, so wird der Eigentümer des Agenten darüber informiert, um zu entscheiden, ob er seine lokale Kopie durch ihre neue Version ersetzen möchte. Zur Vermeidung einer „Überschwemmung“ mit Änderungsnachrichten kann der Benutzer den Agenten anweisen, Änderungen nach bestimmten Merkmalen (Geometrie, Attribute, Randbedingungen zur numerischen Simulation etc.) zu filtern und ggf. zu verwerfen. Zusätzlich lassen sich die Benachrichtigungsdienste für Abfragen nach weiteren Zustandsinformationen wie etwa Datum und Benutzername der letzten Modifikation eines Bauteils oder allen Benutzern, die eine lokale Kopie dieses Bauteils vorhalten, Gewinn bringend einsetzen.

4.4 Oktalbaum als grundlegendes Organisationsschema In diesem Projekt sollte des Weiteren untersucht werden, wie sich neben einer durchgängig volumenorientierten Betrachtungsweise von Prozessen im Konstruktiven Ingenieurbau das hierarchisch rekursive Verfahren der Oktalbäume als grundlegendes Organisationsschema für unterschiedliche Aufgaben im Rahmen von Planungs- und Entwicklungsprozessen etablieren und sich darüber hinaus Gewinn bringend für die Integration und Einbettung sowie für die Steuerung von Simulationsaufgaben nutzen lässt. Mithilfe der Oktalbäume können unterschiedliche Aspekte im Hinblick auf das Anwendungs- und Datenmanagement adressiert werden, die eine effizientere Handhabung im Umgang mit Simulationsaufgaben erlauben und die Türe zu modernen Algorithmen wie etwa dem hierarchischen Gleichungslöser basierend auf dem Nested-Dissection-Ansatz öffnen. 4.4.1 Hierarchische Organisation des Gebäudeinformationsmodells Das zu Grunde liegende Gebäudeinformationsmodell der Industry Foundation Classes (IAI 2006) beinhaltet per se keinerlei Information über räumliche Zusammenhänge und Abhängigkeiten hinsichtlich der Geometrie. Durch hierarchische Organisation der einzelnen Bauteile des Gebäudeinformationsmodells lässt sich dieser Zusammenhang herstellen und für weiterführende Fragestellungen unter Einbeziehung des räumlichen Kontexts nutzen. Dazu wird ein Oktalbaum über allen Bauteilen des Modells aufgespannt, der gerade so weit verfeinert wird, wie ein Bauteil noch komplett in einer Zelle zu liegen kommt. Ein Knoten kann auch mehrere Bauteile enthalten. Das Modell selbst wird zur persistenten Speicherung (als attributierter vef-Graph (Mundani 2006)) in einer Datenbank hinterlegt, deren Primärschlüssel (als Bauteilidentifikator) in den zugehörigen Knoten des Oktalbaums vorgehalten werden. Die durch den Oktal-

Volumenorientierte Modellierung zur vernetzt-kooperativen Planung

309

baum induzierte Hierarchie erlaubt nun komplexe Datenbankabfragen mit räumlichem Kontext, die ohne den Oktalbaum in dieser Art nicht möglich wären. Über den Oktalbaum lassen sich somit zu einem Ausgangsobjekt alle assoziierten, d. h. benachbarten Objekte identifizieren, deren tatsächliche Information im Anschluss durch die gefundenen Primärschlüssel (geomID) aus der Datenbank gelesen werden kann. Daneben sind natürlich auch klassische Datenbankabfragen wie „alle Objekte einer bestimmten Materialklasse“ oder „alle Objekte, die eine bestimmte Randbedingung hinsichtlich der numerischen Simulation aufweisen“ möglich. Eine Kombination aus beiden erlaubt nun die Einbettung von SQLAbfragen nach Merkmalen in einen räumlichen Kontext, bei der Fragestellungen wie bspw. SELECT geomID FROM modelDatabase WHERE material = ’matClass’ and geomID = NEIGHBOUR(object)

nach allen Objekten, die einer Materialklasse matClass zugeordnet und mit dem Bauteil object benachbart sind, schnell und effizient beantwortet werden können. Ein derartiges Vorgehen spielt insbesondere bei der Verarbeitung großer Datensätze eine entscheidende Rolle. Die Nachbarschaftssuche kann dabei zwei unterschiedlichen Ansätzen folgend nach horizontalen sowie vertikalen Relationen erfolgen. Während horizontale Relationen sich mit der räumlichen Nähe von Objekten beschäftigen, werden mit vertikalen Relationen Aspekte von Teilmengeneigenschaften adressiert. Wird die räumliche Nähe als Suchparameter definiert, so lassen sich durch eine horizontale Suche (weil der Oktalbaum bildlich auf gleichen Levels, d. h. horizontal durchsucht wird) Objekte mit einem bestimmten Abstand zum Ausgangsobjekt detektieren. Dies kann bspw. Bauteilen gelten, die in engem oder direktem Kontakt zueinander stehen. Bei der vertikalen Suche wird je nach Baumauf- oder Baumabstieg ausgehend von einer Zelle x (repräsentativ für ein Bauteil) die Fragestellung x Ž y bzw. x ‹ y gelöst. Damit lassen sich Fragen der räumlichen Zugehörigkeit wie bspw. „gehört eine bestimmte Wand x zu einem Zimmer“ (x Ž y) oder „enthält dieses Zimmer ein bestimmte Wand x“ (x ‹ y) beantworten. Durch Kombination beider Ansätze sind darüber hinaus auch komplexe Fragestellungen wie bspw. „alle Bauteile des x-ten Stockwerks“ oder „alle Bauteile der Gebäudeaußenhaut“ denkbar, die ohne hierarchische Organisation nur mithilfe weiterer, oftmals aufwändiger Kontextinformation möglich wären. Das aufgezeigte Verfahren der hierarchischen Organisation von Gebäudeinformationsmodellen lässt sich generell äußerst Gewinn bringend für Aufgaben einsetzen, die sich mit Fragestellungen der so genannten Location Awareness (Narasimhan et al. 2006) befassen. 4.4.2 Integration und Einbettung von Simulationsaufgaben Der maßgebliche Erfolg bei der Einbindung unterschiedlicher, oftmals bereits vorhandener Simulationsaufgaben in eine gemeinsame Softwareumgebung hängt

310

E. Rank, H.-J. Bungartz, R. Romberg, R.-P. Mundani, A. Niggl

primär von den verwendeten Schnittstellen sowie deren Flexibilität beim Umgang mit verschiedenen Modellrepräsentationen ab. Ein wichtiger Faktor zur Unterstützung beider – oberflächen- und volumenorientierter – Modellwelten ist das Vorhandensein geeigneter Schnittstellen, die einen schnellen und effizienten Zugriff auf das jeweilige Darstellungsformat erlauben. Durch den gewählten Ansatz lässt sich die geforderte Repräsentation – als B-Rep- bzw. Oktalbaummodell – einfach zur Laufzeit aus dem attributierten vef-Graphen generieren, um damit unterschiedliche Simulationsaufgaben an das Framework zu koppeln. Diese Kopplung über vorbezeichnete (duale) Schnittstelle kann entweder als Integration oder als Einbettung von Simulationsaufgaben erfolgen. Unter Integration wird dabei der Zugriff einer Simulationsaufgabe auf gemeinsam benutzte Daten des Frameworks verstanden, während bei der Einbettung die Simulationsaufgabe selbst zu einem Teil des Frameworks wird, d. h. dessen Funktionalität erweitert, und damit letztendlich anderen Aufgaben als Dienst zur Verfügung steht. Im Rahmen des Forschungsvorhabens konnten unterschiedliche Simulationsaufgaben erfolgreich in das Framework integriert werden, die darüber hinaus eine weitreichendere Bestimmung des Konsistenzbegriffs zuließen. Hier ist bspw. die Strömungssimulation zu nennen, mithilfe derer sich Fragestellungen der Gebäudeaußenumströmung etwa zur Bestimmung von Interferenzen zwischen benachbarten Gebäuden als auch der Innenraumströmung etwa zu Fragestellungen der Raumklimatisierung beantworten lassen. Im Gegensatz zur Struktursimulation, die eine oberflächenorientierte Darstellung des zu Grunde liegenden Gebäudeinformationsmodells verarbeitet, setzt die Strömungssimulation direkt auf dem zellbasierten Konzept der Oktalbäume auf (Brenk et al. 2005). Im Unterschied zur Integration steht die Einbettung von Simulationsaufgaben, um neben dem Zugriff auf gemeinsam benutzte Daten die Funktionalität des Frameworks zu erweitern. Durch Einbettung lässt sich eine Aufgabe als zusätzlicher Dienst des Frameworks anbieten, der von anderen Aufgaben in Anspruch genommen werden kann. Dadurch kann eine Simulationsaufgabe direkt auf die Ergebnisse einer anderen Simulationsaufgabe zugreifen und diese im Rahmen ihrer eigenen Berechnungen berücksichtigen. Des Weiteren können unter Ausnutzung des dieser Arbeit zu Grunde liegenden Oktalbaumschemas Simulationsaufgaben äußerst effizient organisiert werden, um bspw. den Berechnungsprozess zu steuern und damit redundante Neuberechnungen im Fall von Änderungen am Gebäudeinformationsmodell zu vermeiden. Eine weiterführende Betrachtung hierzu folgt im nächsten Abschnitt. 4.4.3 Hierarchische Organisation und Einbettung einer Simulationsaufgabe In der Praxis läuft kein Planungsprozess strikt „linear“ ab; jede Planung ist dadurch gekennzeichnet, dass Veränderungen zu berücksichtigen sind, dass bereits gefundene Lösungen verworfen und neue eingebunden werden müssen. Das hier vorgeschlagene Ordnungsschema kann dazu verwendet werden, dass lokale Ände-

Volumenorientierte Modellierung zur vernetzt-kooperativen Planung

311

rungen des Modells mit einem erheblich geringeren Aufwand als mit einer völligen Neuberechnung analysiert werden können. Zur hierarchischen Organisation sowie prototypischen Einbettung einer Simulationsaufgabe in das Framework wurde die Struktursimulation (p-Version FEM) gewählt. Zielsetzung war, diese mithilfe von Oktalbäumen dergestalt zu organisieren, dass sich das raumpartitionierende Konzept der Oktalbäume Gewinn bringend zur Lösung der Struktursimulation sowie zur Steuerung des Berechnungsprozesses einsetzen lässt (Mundani u. Bungartz et al. 2005). Hierarchische Organisation der Struktursimulation Nach erfolgter FEM-Diskretisierung (siehe Abschnitt Dekomposition und Vernetzung des Modells) müssen in einem ersten Schritt die Hexaederelemente in einen Oktalbaum eingeordnet werden. Dazu wird für jedes Element ein eindeutiger Repräsentant, z. B. der Mittelpunkt p mit x-, y- und z-Koordinate bestimmt und für diese Punktemenge P aller Repräsentanten p der zugehörige Oktalbaum generiert, wobei jede Zelle maximal ein Element beinhalten darf. Im Anschluss werden in allen Zellen, die mit einem Element i belegt sind, die zugehörigen Elementsteifigkeiten Ki und rechten Seiten di gespeichert.

Abb. 4.6. Hierarchische Organisation einer einfachen Geometrie mit zehn Elementen (links) anhand der Elementmittelpunkte (rechts)

Im nächsten Schritt sind analog die Freiheitsgrade in den soeben erzeugten Oktalbaum einzuordnen. Ein Freiheitsgrad ist dabei gerade in dem Baumknoten zu speichern, von dem aus alle zum Freiheitsgrad gehörenden Elemente durch einen Baumabstieg zu erreichen sind. Je tiefer ein Freiheitsgrad im Baum eingeordnet werden kann, desto früher lässt er sich im Anschluss bei der Lösung des Gesamtgleichungssystems eliminieren. Im worst case ist ein Freiheitsgrad auf dem hierarchisch höchsten Level, dem Wurzelknoten, zu speichern, im best case wird er einem Blatt zugeschrieben, d. h. er ist elementlokal. Für die untersuchten Modelle hat sich gezeigt, dass etwa ein Anteil von 10–20 % aller Freiheitsgrade im Wurzelknoten auftritt. Dieser Wert korreliert aber stark mit dem zu Grunde liegenden Problem, d. h. mit der Organisation der Elemente im Oktalbaum, und sinkt mit zunehmender Erhöhung des Polynomgrades.

312

E. Rank, H.-J. Bungartz, R. Romberg, R.-P. Mundani, A. Niggl

Abb. 4.7. Einordnung der Freiheitsgrade (Kreise) in den durch die Elemente aufgespannten Oktalbaum aus Abb. 4.6

Damit ist die Initialisierung abgeschlossen, und das Gesamtgleichungssystem kann mithilfe eines hierarchischen Gleichunglösers basierend auf dem NestedDissection-Prinzip (George 1973) gelöst werden. Dieses besteht aus den drei grundlegenden Schritten Substrukturierung, Assemblierung und Lösung, wobei der erste Schritt, die Substrukturierung, bereits durch die FEM-Diskretisierung und zugehörige Einordnung der Elemente und Freiheitsgrade in den Oktalbaum erfolgt ist. Im zweiten Schritt, der Assemblierung, wird in einem Bottom-upProzess zunächst für jedes Element das lokale Gleichungssystem Ki˜u = di aufgestellt, das innere und äußere Unbekannte enthält. Innere Unbekannte treten nur lokal auf, d. h. die zugehörigen Zeilen des Gleichungssystems sind bereits vollständig aufgebaut. Äußere Unbekannte, auch als Separatorunbekannte bezeichnet, treten auch in anderen Elementen auf und liegen daher nur gewichtet vor, die entsprechenden Zeilen des Gleichungssystems sind noch unvollständig und das Gleichungssystem kann an dieser Stelle nicht gelöst werden. Um die Separatorunbekannten später auf einem höheren Level berechnen zu können, müssen die Kopplungen zwischen den inneren und äußeren Unbekannten eliminiert werden. Dies geschieht durch statische Kondensation (SCHUR-Komplement-Bildung, siehe z. B. (George 1973)), sodass das reduzierte Gleichungssystem nur noch von den Separatorunbekannten abhängt. SCHUR-Komplement und neue rechte Seite werden an den Vaterknoten weitergereicht und dort mit den Ergebnissen von allen anderen Sohnknoten zu einem neuen Gleichungssystem zusammengesetzt. Sukzessive Wiederholung dieses Vorgehens bis zum Wurzelknoten liefert letztendlich ein Gleichungssystem, das nur noch von inneren Unbekannten abhängt und somit gelöst werden kann. Im dritten Schritt, der Lösung, wird in einem Top-down-Prozess ausgehend vom obersten Level die Lösung der dort gespeicherten Unbekannten berechnet und anschließend an die Sohnknoten weitergereicht. Durch rekursive Fortführung ist am Ende in allen Knoten die Lösung bekannt. Auch wenn bei diesem Ansatz ein direkter Gleichungslöser (GAUSS-Algorithmus zur Berechnung der SCHURKomplemente) zu Grunde liegt, so ist das aufgezeigte Verfahren gegenüber „klassischen“ Ansätzen – im Vergleich zu einem cg-Algorithmus zur Lösung des Gesamtgleichungssystems war in vielen Beispielen ein Laufzeitunterschied von etwa einem Faktor 2 zu beobachten – durchaus wettbewerbsfähig und aufgrund seiner inhärenten Verteilung durch einen klaren Speichervorteil und damit einer wesentlich besseren Skalierbarkeit diesen auch deutlich überlegen. Gegenwärtig wird das

Volumenorientierte Modellierung zur vernetzt-kooperativen Planung

313

Potenzial des vorgestellten Verfahrens nur zu einem Bruchteil ausgeschöpft, durch Übergang zu iterativen Lösungsverfahren oder zu Mehrgitterverfahren ist eine deutliche Leistungssteigerung zu erwarten. Einbettung der Struktursimulation in das Framework Basierend auf der in dieser Arbeit vorgestellten Vernetzung mit Hexaederelementen sowie dem aufgezeigten Ansatz zur hierarchischen Organisation der Struktursimulation kann diese als eigenständige Applikation in das Framework eingebettet werden, sodass sie anderen Aufgaben als Dienst zur Verfügung steht (Mundani u. Bungartz et al. 2006). Ein Dienstaufruf erfolgt über die Zugriffsmethoden des Frameworks. Dazu werden von der aufrufenden Anwendung lokale Änderungen etwa am geometrischen Modell und/oder an den Randbedingungen zur numerischen Simulation vorgenommen und über vorbezeichnete Schnittstellen an das Framework kommuniziert. Mit diesen Parametern wird die Struktursimulation durch das Framework (möglicherweise auf einem (entfernten) leistungsstarken Rechner) gestartet und nach erfolgter Berechnung deren Ergebnis direkt an die aufrufende Anwendung zurückgegeben. Demzufolge lassen sich Auswirkungen und Seiteneffekte der lokalen Änderungen auf die Gebäudestatik leicht aufdecken, bevor diese Änderungen zur globalen Sichtbarkeit und persistenten Speicherung mittels check-in – nach erfolgter geometrischer Konsistenzprüfung – an das Framework zurückgeschrieben werden. Durch die Einbettung der Struktursimulation lässt sich wie bereits durch die Integration von Simulationsaufgaben der Konsistenzbegriff erweitern, sodass eine umfassendere Betrachtung von Planungsprozessen möglich ist. Dabei können Implementierungsdetails der eingebetteten Aufgabe – analog zu den Problem Solving Environments – vor dem Benutzer verschattet werden, dieser muss lediglich die Schnittstellendefinition, d. h. die korrekte Syntax zum Aufrufen des Dienstes kennen. Steuerung der Berechnung Um im Fall einer Änderung am zu Grunde liegenden Modell den Aufwand einer Neuberechnung zu minimieren, lässt sich die hierarchische Organisation der Struktursimulation an dieser Stelle äußerst Gewinn bringend nutzen. Änderungen am Modell (etwa das Anbringen eines zusätzlichen Fensters oder die Modifikation eines Materialparameters) haben i. d. R. nur einen lokalen Einfluss, sodass eine komplette Neuberechnung nicht nur aufwändig, sondern auch überflüssig ist. Unter Ausnutzung der Hierarchie lassen sich Bereiche, die einer Neuberechnung bedürfen, einfach und schnell bestimmen, aus den übrigen Bereichen werden die bereits bekannten Ergebnisse direkt übernommen. Damit ist eine gezielte Steuerung der Berechnung möglich, die im Gegensatz zu einer kompletten Neuberechnung den Aufwand auf die relevanten Teilbereiche beschränkt.

314

E. Rank, H.-J. Bungartz, R. Romberg, R.-P. Mundani, A. Niggl

Abb. 4.8. Modifikation zweier Elemente: Im Fall einer Neuassemblierung ist nur entlang der gestrichelten Äste ein Berechnungsaufwand erforderlich. Die zur Berechnung notwendigen SCHUR-Komplemente der benachbarten Ästen (schraffierte Teilbereiche) können dagegen direkt übernommen werden

Bei Änderungen am Modell sind diese zunächst in den Oktalbaum zu übertragen, bevor eine Neuassemblierung durchgeführt werden kann. Neue Elemente und Freiheitsgrade sind nach oben aufgezeigtem Schema in den Oktalbaum einzufügen, gelöschte Elemente und Freiheitsgrade entsprechend zu entfernen. Außerdem sind für alle modifizierten Elemente neue Steifigkeitsmatrizen zu berechnen und gegen ihre obsoleten Versionen in den Knoten des Baumes zu tauschen. Im Anschluss kann eine Neuassemblierung (Bottom-up-Prozess) erfolgen, wobei hier nur Berechnungen entlang der Äste mit modifizierten Knoten stattfinden. Von allen anderen Ästen können die bereits vorliegenden Ergebnisse (d. h. SCHURKomplemente) direkt zur Assemblierung übernommen werden. Damit reduziert sich der Aufwand einer Neuassemblierung auf das erforderliche Minimum, in Einzelfällen konnte hier eine Reduzierung bis auf 4 % einer kompletten Assemblierung erreicht werden. Nach erfolgter Assemblierung wird im anschließenden Top-down-Prozess die neue Lösung in allen Knoten des Baumes berechnet. Damit sind die Auswirkungen auf die Gebäudestatik infolge der Änderung bekannt. Gerade hier bildet sich durch Kombination aus hierarchischer Organisation und pVersion der größte Synergieeffekt, da sowohl beim Hinzufügen neuer Bauteile (resp. Elemente) zum Studium des Baufortschrittes als auch bei lokalen Verfeinerungen durch Erhöhung des Polynomgrades zum Studium detaillierter, hoch aufgelöster Belastungsanalysen schnelle Neuberechnungen hinsichtlich geänderter Szenarien in einem kooperativen Umfeld durchgeführt werden können. Des Weiteren ist durch die hierarchische Organisation inhärent eine Verteilung gegeben, die im Gegensatz zu klassischen Substrukturierungsverfahren auch die Geometrie berücksichtigt. Die einzelnen Äste des Oktalbaums entsprechen dabei gerade unterschiedlichen benachbarten Bauteilen (bspw. Stockwerken eines Gebäudes), die gleichzeitig von unterschiedlichen Tragwerksplanern bearbeitet werden können. Lokale Änderungen können durch das aufgezeigte Verfahren schnell und effizient in einem globalen Gesamtrahmen untersucht werden, ohne dabei die globale Konsistenz infrage zu stellen. Erst nach erfolgreicher (lokaler) Statikanalyse werden die Änderungen zur globalen Sichtbarkeit persistent durch das Framework gespeichert und fortan in allen Berechnungen zur Gebäudestatik berück-

Volumenorientierte Modellierung zur vernetzt-kooperativen Planung

315

sichtigt. Durch diese zu Grunde liegende Verteilung lassen sich darüber hinaus auch hervorragend Aspekte einer verteilten Berechnung adressieren, die unter Zuhilfenahme der Grid-Technologie die Tür zu ganz neuen Möglichkeiten öffnen. Erste Ergebnisse diesbezüglich sind äußerst viel versprechend (Mundani u. Muntean et al. 2005). Zusammenfassend konnte hier am Beispiel der Struktursimulation gezeigt werden, wie sich durch die hierarchische Organisation einer Simulationsaufgabe effiziente Verfahren zur numerischen Gleichungslösung entwickeln lassen, die neben der Einbettung, d. h. der Inanspruchnahme als Dienst, und der Steuerung, d. h. der gezielten Berechnung zur Aufwandsminimierung, einer Simulationsaufgabe darüber hinaus zur Kooperation in einer verteilten Arbeitsumgebung beitragen und damit nachhaltig der Konsistenzsicherung einer gemeinsam benutzen Datenbasis dienen. 4.4.4 Steuerung der Berechnung am Beispiel der Bauphasensimulation Wie im vorhergehenden Abschnitt gezeigt, eignet sich der hierarchische Ansatz ideal zur Steuerung der Berechnung bei wiederholten Änderungen am System, ohne jedes Mal das ganze Modell neu analysieren zu müssen. Diese Vorteile lassen sich zur Simulation eines Bauwerks während verschiedener Bauphasen ausnutzen. Das statische Modell eines Bauwerks wird zu verschiedenen Zeitpunkten während des Baufortschrittes analysiert, wobei ein Schritt von einem Zeitpunkt zum nächsten keine vollständige Neuberechnung des gesamten Modells erfordert. Zweckmäßigerweise soll ein Berechnungsdurchlauf aber nicht jedes Mal eine manuelle Interaktion mit dem Finite-Elemente-Modell erfordern. Für die zeitliche Organisation einer Baumaßnahme wird man vielmehr ein Projektplanungswerkzeug verwenden, welches den Bauablauf zum Beispiel in Form eines Balkenplanes darstellt. Um dieses auch zu einer Steuerung der Berechnung zu verwenden, ist eine Verbindung der Bauablaufinformation mit den räumlichen Daten der Bauwerksgeometrie herzustellen. Eine derartige Erweiterung von Bauwerksmodellen um zeitliche Informationen ist unter dem Begriff 4D-CAD bekannt, welcher sich neben der Forschung (McKinney u. Fischer 1998) in letzter Zeit zunehmend auch in der Praxis etabliert (Hochtief 2006). Mit dem hier vorgestellten Framework bietet es sich nun an, in ähnlicher Weise die zentrale Datenbasis um zeitliche Informationen des Bauablaufes zu erweitern. Auf Basis dieser Daten lässt sich dann sehr einfach die eingebettete FiniteElemente-Anwendung steuern. Dazu wurde mit MS Project ein Werkzeug zur Prozessplanung in das Framework integriert. In dieser Anwendung wird zunächst ein Ablaufplan der Baumaßnahme z. B. in Form eines Netzplanes formuliert. Um nun eine Verbindung mit den geometrischen Daten herzustellen, werden in einer graphisch interaktiven Anwendung Bauteile einzelnen Planungsphasen zugeordnet und diese als Relation innerhalb der Datenbank abgelegt. Mit diesen Informationen können nun beliebige Zusammenhänge zwischen Bauablauf und FiniteElemente-Modell abgeleitet und das Tragwerksmodell zu unterschiedlichen Bau-

316

E. Rank, H.-J. Bungartz, R. Romberg, R.-P. Mundani, A. Niggl

zeitpunkten visualisiert oder unter Verwendung des hierarchischen Lösers neu berechnet werden.

Abb. 4.9. Einbindung einer Prozessplanungssoftware zur Bauphasensimulation. Durch Ausnutzung der Hierarchie können schnell Änderungen auf das Modell abgebildet und eine Neuberechnung veranlasst werden.

Mit einem derartigen 4D-Modell lässt sich nun der Aufbau des Tragwerks zu bestimmten Zeitpunkten während der Baumaßnahme einfach über Interaktion mit dem Prozessmodell steuern. Dies ermöglicht dem Bearbeiter, unterschiedliche Planungsalternativen im Bauablauf schnell hinsichtlich ihrer Auswirkungen auf die Statik eines Gebäudes zu untersuchen. Auch unvorhergesehene Änderungen am Ablauf – zum Beispiel durch zeitliche Verzögerungen – lassen sich schnell auf die Tragstruktur abbilden und untersuchen. Die Steuerung der Berechnung geschieht dabei immer auf der abstrakten Ebene des Prozessmodells, die Berechnung erfolgt transparent für den Benutzer. Ein ganz entscheidender Vorteil von derartigen Systemen ist, dass durch die Erweiterung des Bauwerksmodells um zeitliche, aber durchaus auch andere Informationen ein gemeinsamer Projektarbeitsraum für verschiedene Fachdomänen geschaffen werden kann. Man spricht in dem Zusammenhang auch von nDmodeling (Aouad et al. 2005). Durch die Integration verschiedener Fachinformationen kann jederzeit auf die Daten des anderen Bereiches zugegriffen und durch eine Verknüpfung ein Mehrwert geschaffen werden. Es werden ursprünglich getrennt geplante Fachgewerke in einem gemeinsamen Modell zusammengeführt, was die Kommunikation, die Koordination und die Abstimmung in der Planungsphase wirkungsvoll unterstützt. Beispielsweise kann der Bauablauf einer Maßnahme zunächst in herkömmlicher Weise geplant werden. Mit den Daten eines 4D-Modells ist es nun aber ohne weiteres möglich, diesen Ablauf auch visuell darzustellen, wodurch sich eventuell vorhandene Konflikte leichter erkennen und beheben lassen. Eine visuelle Darstellung ist ein nicht zu unterschätzender Vorteil, welcher gerade im Umgang mit Bauauftraggebern oder der Öffentlichkeit sehr wichtig sein kann (Fischer et al. 2003).

Volumenorientierte Modellierung zur vernetzt-kooperativen Planung

317

Mit dem in diesem Beitrag vorgestellten Konzept kann ein derartiger Projektarbeitsraum nun um die Fachdomäne der Tragwerksplanung erweitert werden. Mit der Verknüpfung von zeitlichen Informationen mit dem Berechnungsmodell lässt sich ein zusätzlicher Mehrwert schaffen, was die Akzeptanz einer derartig integrierten Planungsweise sicherlich erhöhen wird. Einzelheiten dieser Erweiterung sind in (Niggl 2006) beschrieben.

4.5 Vernetzt-kooperative Planung Mit dem in diesem Beitrag beschriebenen Framework lassen sich unterschiedliche Simulationsverfahren ausgehend von einem gemeinsamen Modell durchführen. Ein wesentliches Ziel war dabei, die Dynamik im Planungsprozess, also wiederkehrende Veränderungen des Modells, zu unterstützen. Hierzu sollen vor allem die Konzepte der Konsistenzerhaltung sowie die hierarchischen Datenstrukturen dienen, mit denen zum Beispiel Neuberechnungen schneller durchgeführt werden können. Innerhalb des Schwerpunktprogramms und im Wesentlichen innerhalb der Arbeitsgruppe Verteilte Simulation lassen sich die hier gezeigten Vorteile auch in anderen Projekten sinnvoll nutzen. In Beitrag IV.2 „Sensitivitätsanalyse netzwerkübergreifender Produkt- und Strukturmodelle bei Planungsprozessen des Konstruktiven Ingenieurbaus“ wird eine Methodik vorgeschlagen, mit der sich die Auswirkungen der Variation verschiedener Eingangsparameter hinsichtlich eines Ergebniskriteriums bei der Planung von Bauwerken untersuchen lassen. Dabei sollen vor allem Auswirkungen von Entscheidungen hinsichtlich verschiedener Fachbereiche miteinander verglichen werden. Eingangswerte für die Sensitivitätsanalyse sind Ergebnisdatensätze von Berechnungsdurchläufen mit unterschiedlichen Parametern. Hierzu ist einerseits eine schnelle Neuberechnung nach Änderung von Parametern sehr wichtig sowie andererseits die Ansteuerung unterschiedlicher Simulationsverfahren. In weiterer Kooperation mit dem in Abschnitt IV.3 vorgestellten Projekt wurde dazu in einem Beitrag (Krafczyk et al. 2006) ein Konzept zur domänenübergreifenden Sensitivitätsanalyse basierend auf einem Austausch mittels standardisierter Produktmodelle vorgestellt.

4.6 Zusammenfassung und Ausblick Dieser Beitrag beschreibt Aspekte eines Forschungsprojekts, welches im Rahmen des Schwerpunktprogramms „Vernetzt-kooperative Planungsprozesse im Konstruktiven Ingenieurbau“ entstand. Zentraler Ausgangspunkt der Untersuchungen war die Hypothese, dass eine Verbesserung der kooperativen Zusammenarbeit erreicht werden kann, wenn die Modellierung und Berechnung von Bauwerken an einem strikt volumenorientierten Modell des Gesamtsystems durchgeführt werden.

318

E. Rank, H.-J. Bungartz, R. Romberg, R.-P. Mundani, A. Niggl

Ein besonderes Augenmerk lag darin, die dem Planungsprozess innewohnende iterative Vorgehensweise und Dynamik zu unterstützen. Im Rahmen des Projekts konnte gezeigt werden, dass das hierarchisch rekursive Oktalbaumschema als grundlegendes Organisationsschema sich vielseitig und Gewinn bringend für unterschiedliche Aufgaben einsetzen lässt, die nicht nur zur Förderung der kooperativen Zusammenarbeit sowie deren Nachhaltigkeit beitragen, sondern darüber hinaus neue Synergien schaffen und letztendlich eine ganzheitliche Betrachtung von Planungsprozessen erlauben. Es bleibt zu zeigen, mit welchem Aufwand sich die entwickelten Verfahren erfolgreich für weitere Simulationsaufgaben oder in Industrieprojekten umsetzen und welche Vorteile sich durch die strikte volumenorientierte Betrachtungsweise daraus ableiten lassen.

Literatur Aouad G, Lee A, Wu S (2005) From 3D to nD modelling, ITcon 10: 15–16, http://www.itcon.org/2005/2 Brenk M, Bungartz H-J, Mehl M, Mundani R-P, Düster A, Scholz S (2005) Efficient Interface Treatment for Fluid-Structure Interaction on Cartesian Grids. In Proc. of ECCOMAS Thematic Conf. on Computational Methods for Coupled Problems in Science and Engineering Düster A (2001) High order finite elements for three-dimensional thin-walled nonlinear continua. Dissertation, Technische Universität München Düster A, Bröker H, Rank E (2001) The p-version of the finite element method for threedimensional curved thin-walled structures. International Journal for Numerical Methods in Engineering 52: pp 673–703 Fischer M, Haymaker J, Liston, K (2003) Benefits of 3D and 4D Models for Facility Managers and AEC Service Providers. In: Issa RR, Flood I, O'Brien WJ (eds), 4D CAD and Visualization in Construction: Developments and Applications. A.A. Balkema Publishers, pp 1–32 George JA (1973) Nested Dissection of a Regular Finite Element Mesh. SIAM Journal on Numerical Analysis 10: pp 345–363 Hochtief AG (2006) ViCon – Build digitally first: Virtuelle Produktentwicklung für die Welt von morgen, Produktinformation. http://www.hochtief-vicon.de IAI- International Alliance for Interoperability (2006) http://www.iai-international.org Krafczyk M, Fahrig T, Toelke J, Niggl A, Rank E, Lähr A, Bletzinger K-U (2006) A generalized product model-based framework for multidisciplinary interactive sensitivity analysis and optimization in civil engineering. In: Proc. of the 11th Int. Conf. on Computing in Civil and Building Engineering, Montréal, Kanada McKinney K, Fischer M (1998) Generating, evaluating and visualizing construction schedules with CAD tools. Automation in Construction 7: pp 433–447 Mundani R-P (2006) Hierarchische Geometriemodelle zur Einbettung verteilter Simulationsaufgaben. Shaker Verlag Mundani R-P, Bungartz H-J (2004a) An Octree-Based Framework for Process Integration in Structural Engineering. In Proc. of the 8th World Multi-Conf. on Systemics, Cybernetics and Informatics, Orlando, Florida, USA, pp 197–202 Mundani R-P, Bungartz H-J (2004b) Octrees for Cooperative Work in a Network-Based Environment. In Proc. of the 10th Int. Conf. on Computing in Civil and Building Engineering, Weimar

Volumenorientierte Modellierung zur vernetzt-kooperativen Planung

319

Mundani R-P, Bungartz H-J, Rank E, Romberg R, Niggl A (2003) Efficient Algorithms for Octree-Based Geometric Modelling. In: Proc. of the Ninth Int. Conf. on Civil and Structural Engineering Comp., Egmond aan Zee, Netherlands Mundani R-P, Bungartz H-J, Rank E, Niggl A, Romberg R (2005) Extending the p-Version of Finite Elements by an Octree-Based Hierarchy. In Proc. of the 16th Int. Conf. on Domain Decomposition Methods, New York City, New York, USA Mundani R-P, Muntean I L, Bungartz H-J, Niggl A, Rank E (2005) Applying Grid Techniques to an Octree-Based CSCW Framework. In: Proc. of the 12th European Parallel Virtual Machine and Message Passing Interface Conference, Sorrento, Italy, pp 504– 511 Mundani R-P, Bungartz H-J, Niggl A, Rank E (2006) Embedding, Organization and Control of Simulation Processes in an Octree-Based CSCW Framework. In: Proc. of the 11th Int. Conf. on Computing in Civil and Building Engineering, Montréal, Kanada, pp 3208–3215 Narasimhan S, Mundani R-P, Bungartz H-J (2006) An Octree- and a Graph-Based Approach to Support Location Aware Navigation Services. In: Proc. of the 2006 Int. Conf. on Pervasive Systems and Computing, Las Vegas, Nevada, USA, pp 24–30 Niggl A (2006) Tragwerkssimulation am volumenorientierten Gesamtmodell. Dissertation in Vorbereitung, Lehrstuhl für Bauinformatik, Technische Universität München Niggl A, Romberg R, Rank E, Mundani R-P, Bungartz H-J (2004) A Framework for Concurrent Structure Analysis in Building Industry. In Proc. of the 5th European Conf. on Product and Process Modelling in the AEC Industry, Istanbul, Turkey Niggl A, Rank E, Mundani R-P, Bungartz H-J (2005) Organizing a p-Version Finite Element Computation by an Octree-Based Hierarchy. In Proc. of the Int. Conf. on Adaptive Modeling and Simulation, Barcelona, Spain Niggl A, Rank E, Mundani R-P, Bungartz H-J (2006) A Framework for Embedded Structural Simulation: Benefits in Building Design. In Proc. of the 11th Int. Conf. on Comp. in Civil and Building Engineering, Montréal, Kanada, pp 1768–1777 Romberg R (2005) Gebäudemodell-basierte Strukturanalyse im Bauwesen. Dissertation, Lehrstuhl für Bauinformatik, Technische Universität München Romberg R, Niggl A, van Treeck C, Rank E (2004) Structural analysis based on the product model standard IFC. In: Proc. of ICCCBE-X, Weimar Rückert KJ (1992) Entwicklung eines CAD-Programmsystems zur Bemessung von Stahlbetontragwerken mit Stabwerkmodellen. Dissertation, Universität Stuttgart Schlaich J, Schäfer K (2001) Konstruieren im Stahlbetonbau. Betonkalender, Bd 2, S 311– 492 Scholz D, Düster A, Rank E (2006) Anisotropic p-adaptivity for thin-walled and massive structures. Part I: Elastostatic problems. International Journal for Numerical Methods in Engineering, to appear Szabó B, Babuska I (1991) Finite element analysis. John Wiley & Sons Szabó B, Düster A, Rank E (2004) The p-version of the Finite Element Method. In: Stein E, de Borst R, Hughes TJR (eds) Encyclopedia of Computational Mechanics, John Wiley & Sons, vol 1, pp 119–139 Van Treeck C (2004) Gebäudemodell-basierte Simulation von Raumluftströmungen. Dissertation, Lehrstuhl für Bauinformatik, Technische Universität München Wassouf Z, Egger M, Neuberg F, van Treeck C, Rank E (2006) Produktmodell basierte Simulation des Ressourcenbedarfs von Bauwerken. Bauingenieur 81

Teil V Agentensysteme

1 Überblick zum Themenbereich Agentensysteme

Dietrich Hartmann Ruhr-Universität Bochum, Lehrstuhl für Ingenieurinformatik im Bauwesen [email protected]

1.1 Einleitende Bemerkungen Durch die im DFG Schwerpunktprogramm SPP 1103 durchgeführten Forschungsarbeiten zur agentenbasierten Software-Entwicklung wurde der Nachweis erbracht, dass die in der modernen Informatik entstandene Agententechnologie auch für den Bereich der vernetzt-kooperativen Bauplanung hervorragend als Problemlösungsstrategie geeignet ist. Das Planen, das Entwerfen, das Konstruieren und die sich daran anschließende Bauausführung werden auf eine neue tragfähige Grundlage gestellt. Es ist klar geworden, dass die in der Bauplanung anstehenden großen Zukunftsaufgaben, d. h. komplexe und durch viele Beteiligte geprägte Arbeitsprozesse bzw. Aktivitäten des Bauwesens fristgerecht, technisch und wirtschaftlich optimal abzuwickeln, durch die Agententechnologie – wie durch keine andere Technologie zuvor – adäquat unterstützt werden. Es ist nunmehr möglich, die in der Wirklichkeit ablaufenden Arbeitsabläufe weitgehend frei von Informationsverlusten in ein Computermodell zu übertragen; die Übertragung erfolgt anschaulich sowie plausibel und kann jederzeit leicht nachgeprüft werden. Dem normalen Sprachgebrauch folgend, wird dabei ein „Agent“ auch in der Informatik als „etwas“ angesehen, das – weitgehend selbstständig – im Auftrag oder im Interesse einer Person, einer Institution oder einer Organisation handelt.

1.2 Einordnung der Agententechnologie Agentensysteme und die bei praktischen Ingenieuranwendungen erforderlichen Multiagentensysteme, bei denen immer mehrere Softwareagenten interagierend an einer Problemlösung arbeiten, stellen in der Evolution des Software Engineering die zurzeit höchste Entwicklungsstufe dar. Die einzelnen Evolutionsschritte des

324

Dietrich Hartmann

Software Engineering sind dabei durch einen sich zunehmend verbessernden Abstraktionsgrad geprägt: Von der Maschinensprache über Assembler, über die maschinenunabhängige Programmierung, über die prozedurale/imperative Programmierung mit Subroutinen und Funktionen bis hin zu abstrakten Datentypen und – darauf aufbauend – Objekten und Klassen. In diese Kette von Schritten reihen sich die Agenten als neueste Abstraktionsstufe nahtlos ein. Die Agentensysteme können des Weiteren als konsequente Fortschreibung und Fortentwicklung der Künstlichen Intelligenz (KI) Forschung angesehen werden. Insbesondere erweitern sie Ansätze der Symbolverarbeitung, bei der Wissen mit symbolischen Strukturen dargestellt wird, vor allem aber der subsymbolischen KI, mit der Wissenseinheiten (Begriffe oder Konzepte) nicht in einzelnen Symbolen lokalisiert sind, sondern über ein Netz verteilt werden. Gleichzeitig wird der evolutionäre Fortschritt im Software Engineering dabei durch immer leistungsfähigere Hardwaresysteme, sowohl sequentielle als auch parallele/verteilte Hardware, vor allem aber auch durch die großen Fortschritte, die sich mit Rechnernetzen, insbesondere dem Internet, verbinden. Fünf große, noch nicht zum Abschluss gekommene Trends konnten sich dabei als Folge der oben beschriebenen evolutionären Entwicklung in der Informatik erkennbar herausbilden: Ubiquität (Ubiquity), Vernetzung (Interconnection), Zunahme an Intelligenz (Intelligence), Delegation von Aufgaben an Software (Delegation) und Einbindung menschenbezogener Aspekte in das Software Engineering (Human Orientation/Anthropocentricity). Ubiquität meint dabei, dass Computersysteme inzwischen, in Geräte eingebettet, vielfach verfügbar sind. Vernetzung hat zur Folge, dass Computer nicht länger nur alleine nutzbar sind, sie stehen miteinander im Verbund, so dass das Rechnernetz (das Internet als Beispiel) der „Computer“ geworden ist. Es besteht auch kein Zweifel daran, dass Computer immer mehr leisten können, auch wenn der Begriff „Intelligenz“ angesichts der enormen Komplexität, die sich mit menschlicher Intelligenz verknüpft, mit Vorsicht verwendet werden sollte. Viele Beispiele im täglichen Leben zeigen jedoch, dass bisher allein von Menschen wahrgenommene Aufgaben an den Computer delegiert werden können (erwähnt seien beispielsweise der elektronische Flugnavigator bei Flugzeugen oder auch Konstruktionsroboter, wie sie typischerweise etwa im Automobilbau eingesetzt werden). Klar erkenntlich geworden ist in letzter Zeit auch, dass die Erstellung von Software mit Sicherheit nicht nur eine rein technische Aufgabe ist, sondern die Einbindung menschenbezogener bzw. „sozialer“ Aspekte verlangt; ein überzeugendes, einfaches Beispiel hierfür sind die vielen grafischen Benutzungsoberflächen moderner Programmsysteme, die – ergonomisch gestaltet – auf Benutzerfreundlichkeit und leichte Bedienung hin ausgelegt sind.

Überblick zum Themenbereich Agentensysteme

325

1.3 Agententechnologie für vernetzt-kooperative Planungsprozesse Das Paradigma der Agentensysteme eignet sich in besonderer Weise für sehr komplexe und umfangreich verteilte Softwaresysteme, die immer dann benötigt werden, wenn Problemstellungen vielschichtig sind, mehrere Ebenen in Raum und Zeit umfassen, durch ein komplexes Beziehungsgeflecht von Fachexperten geprägt sind, und zudem mit Veränderungen der verschiedensten Art (systemischen, organisatorischen, auftragsbezogenen, stochastischen, unscharfen Veränderungen) zu rechnen ist. Die Projektbearbeitung in der Tragwerks- und Gebäudeplanung ist in der Tat durch die oben beschriebene hohe Komplexität gekennzeichnet, sowohl vom ingenieurtechnischen als auch vom informatischen Standpunkt aus betrachtet. Angesichts der im Bauwesen zu beachtenden neuen Regularien und der ansteigenden Normenflut nimmt die Komplexität dabei noch ständig zu. Man ist allein schon deswegen dringend gezwungen, neue Lösungsansätze und neue Formen der Unterstützung durch Computerhardware und -software zu finden. Die Komplexität selbst ist dabei vielschichtig; sie hängt damit zusammen, dass

x größere Bauwerke/Tragwerke per se komplex sind, bzgl. der Systemwahl, der Auswahl von Werkstoffen, des Entwurfs, der Bemessung und der Konstruktion sowie der Herstellung und im Betrieb, x Interdisziplinarität gefordert ist (Architekt, Statiker, Bauphysiker, Baumanager, Bauherr, Betreiber etc. sind die Beteiligten) und x Organisations- und Kommunikationsstrukturen der an der Projektierung Beteiligten durch eine enorme Heterogenität, Zeitvarianz, durch konkurrierende Interessen, Konfliktszenarien und Unwägbarkeiten geprägt sind. Fundamental wichtig ist, dass entsprechende Lösungsansätze über eine hinreichende Flexibilität bzw. Offenheit verfügen. Flexibilität bezieht sich dabei auf eine ganze Reihe von Aspekten: Für die einzelnen Teilgebiete des Mehrebenenproblems müssen die jeweils effektivsten Lösungsmethoden bzw. -paradigmen bereit stehen, wobei man im Voraus nicht genau weiß, was wirklich am effektivsten ist. Auch das heterogene, nur temporär bestehende, oft ad-hoc sich bildende Beziehungsgeflecht der Fachexperten ist nicht a priori genau festlegbar. Es kann über die Zeit schrumpfen oder anwachsen, es sind unvorhersehbare Ausfälle möglich, und auch die Fachkompetenz der beteiligten Partner kann sich wandeln. Unwägbarkeiten, sowohl Stochastizität als auch Unschärfe (informelle, lexikalische, datenbezogene), treten neben deterministische Konzepte und sind im Hinblick auf die Akzeptanz von Ergebnissen sinnvoll zu berücksichtigen. Offenheit bedeutet, dass jederzeit Systemkomponenten wegfallen oder neue Komponenten hinzukommen können, so dass die Interaktionsmechanismen zwischen den einzelnen Komponenten nicht zu restriktiv definiert sein dürfen. Zu starre Kopplungen von Komponenten würden die Anpassungsfähigkeit eines Systems zur Laufzeit verringern.

326

Dietrich Hartmann

Die Umsetzung komplexer Arbeitsmodelle für die Bauplanung (bestehend aus Produktmodellen, Arbeitsprozessen, Aufgabenträgern und ihrer Organisationsstruktur) in agentenbasierte Softwaresysteme orientiert sich demnach also weit mehr als alle bisher gekannten Ansätze der Informatik an der technischen, soziologischen und menschenbezogenen Problemrealität. Softwaresysteme für komplexe Arbeitsmodelle in der Bauplanung durch eine Ansammlung interagierender, autonomer Software-Einheiten auf Computernetzen abzubilden, hat sich dabei als die natürlichste und direkteste Art erwiesen, um die Teamarbeit im Ingenieurwesen abzubilden – ohne schwerwiegende semantische Verluste durch inadäquate informatische Formalisierungskonzepte hinnehmen zu müssen. Auf diese Weise war es in den agentenorientierten Teilprojekten im SPP 1103 möglich, die bei Beginn des Forschungsverbundes gehegte Erwartung voll zu erfüllen, neue, dem Internet angemessene, computerbasierte Arbeitsplattformen zu schaffen und die Qualität der Ingenieurarbeit nachhaltig zu verbessern. Mit der intensiven, fachspezifisch geprägten Erforschung der Agententechnologie für die vernetzt-kooperative Bauplanung befasst waren dabei insbesondere

x das Teilprojekt an der TU Darmstadt (Prof. Rüppel, Prof. Meißner) zum agentenbasierten Modellverbund für die kooperative Gebäudeplanung, x das Teilprojekt an der Ruhr-Universität Bochum (Prof. Hartmann) zur kooperativen Tragwerksplanung basierend auf Multiagentensystemen und adaptiven Assoziationsnetzen, x das Teilprojekt an der Universität Bonn (Prof. Cremers) zur komponentenbasierten Plattform für anpassbare, vernetzte Systeme im Bauwesen. Im weiteren Verlauf der SPP 1103-Forschung haben dann auch zwei weitere Teilprojekte aus dem Bereich „Verteilte Simulation“ zunehmend Konzepte der Agentensysteme in die eigene Arbeit einbezogen:

x das Teilprojekt an der TU München (Prof. Bletzinger) zur Sensitivitätsanalyse netzübergreifender Produkt- und Strukturmodelle bei Planungsprozessen des Konstruktiven Ingenieurbaus, x das Teilprojekt an der TU Braunschweig (Prof. Krafczyk) zur verteilten, interaktiv-kooperativen Simulation zur Beschleunigung von Entwurfszyklen im Konstruktiven Ingenieurbau.

1.4 Verwendete Agentendefinitionen Was versteht man aus Sicht der Informatik bzw. Ingenieurinformatik unter dem Begriff „Agenten“? Für die gemeinsame Forschungsarbeit im SPP 1103 bildete die einheitliche Begriffsdefinition eine wichtige Arbeits- und Verständigungsgrundlage. Eine allgemein akzeptierte, generell gültige Begriffsdefinition ist jedoch schwierig, da höchst unterschiedliche Begriffsdefinitionen existieren. Die im Gebrauch befindlichen Definitionen hängen jeweils davon ab, welche Informatik-

Überblick zum Themenbereich Agentensysteme

327

schule durchlaufen wurde und welche Sichtweise eingenommen wird. Anhänger der Künstlichen Intelligenz (KI) verwenden dabei völlig andere Definitionen als mehr technisch orientierte Forscher aus der Ingenieurinformatik, die hier hauptsächlich im Zentrum des Interesses steht. Für die Forschungsarbeit im SPP 1103 wurde es deshalb als sinnvoll angesehen, im Hinblick auf die praktische Realisierung von folgenden Eigenschaften für Agenten auszugehen:

x Agenten vertreten menschliche Aufgabenträger in ausgewählten, formalisierbax x x x x x

x

ren Tätigkeitsbereichen (z.B. Grundlagenermittlung, Statik, Konstruktion). Agenten besitzen Problemlösungs- und Planungsfähigkeiten. Agenten haben kommunikative und ggf. perzeptive Fähigkeiten. Agenten verfügen über relevantes Hintergrundwissen ihrer Auftraggeber. Agenten setzen ggf. Dienstleistungsprogramme (Serverkomponenten) ein. Agenten arbeiten mit anderen Agenten zusammen (Multiagentensysteme). Agenten bilden unter Nutzung des Internet-Computing das Beziehungsgeflecht der personellen Aufgabenträger ab; zu erfassen dabei sind: Organisationsstrukturen (transient, virtuell), Ressourcenmanagement (Prioritäten, Zeiten/ Termine, Personalbedarfe), Ausnahmebehandlungen etc. Agenten verkörpern Wechselwirkungsmechanismen auf der Basis einer präzisen, formalen und grafisch darstellbaren Notation und Symbolik.

Agentensysteme für die Bauplanung sind also so auszulegen, dass sie von Ingenieuren dazu beauftragt werden können, ganz bestimmte Tätigkeiten selbstständig (autonom) auszuführen, weshalb Agentensysteme auch ein „Autonomous Computing“ repräsentieren. Typische Tätigkeiten sind dabei, etwas zu planen, zu entwerfen, zu berechnen, zu bemessen, zu konstruieren, zu erstellen, zu überwachen, zu steuern etc. Die bislang erzielten Erfolge mit Agenten demonstrieren, dass autonom agierende Systeme nicht mehr länger nur Utopie sind. Es gibt sie inzwischen in vielfältiger Weise: Systeme, die im Sinne der „Heinzelmännchen-Metapher“ als „dienstbare Geister“, als Assistenten oder als „künstliche Diener“ tätig werden. Um die Forschungsarbeit im SPP 1103 zu harmonisieren, ohne unnötige Einschränkungen oder Hürden aufzubauen, kam man überein, sich sinngemäß in den agentenbezogenen Teilprojekten im Wesentlichen an folgenden, anerkannten Begriffsdefinitionen zu orientieren.

x Russel und Norwig (Russel u. Norwig 1995) (vgl. Abb. 1.1): “An agent is anything that can be viewed as perceiving its environment through sensors and acting upon that environment through effectors.” x Hayes-Roth (Hayes u. Washington 1992) (vgl. Abb. 1.2): “Intelligent agents continuously perform three functions: 1. perceptions of dynamic conditions in the environment; 2. actions to affect these conditions; 3. and reasoning to interpret perceptions, solve problems, draw inferences and determinate actions”.

328

Dietrich Hartmann

Abb. 1.1. Agentendefinition und -struktur nach Russel und Norwig

Abb. 1.2. Agentendefinition und -struktur nach Hayes-Roth

x Ferber (Ferber 2001) und Hartmann (Bilek u. Hartmann 2002) (vgl. Abb. 1.3): “Agents can be regarded as powerful objects that can say YES or NO as well as STOP and GO.”

Abb. 1.3. Agentendefinition und -struktur nach Ferber/Hartmann

Überblick zum Themenbereich Agentensysteme

329

x Woolridge und Jennings (Woolridge u. Jennings 1994): “Light-weight agents are hardware/software units possessing autonomy (stationary/mobile), communication ability, reactivity and proactivity. Heavy-weight agents incorporate at least one further ability of the three following properties -

menthal abilities (beliefs, interactions) artifical abilities (avartars) learning abilities”.

Die Wirkungsweise eines einzelnen Softwareagenten kann in Anlehnung an die von Woolridge vorgeschlagene mathematische Notation auch als allgemeine Abbildungsvorschrift (1.1)

Ag : ƒ ( o Ac E

betrachtet werden, durch die so genannten „runs“ ƒ in „actions“ Ac überführt werden. Mit andern Worten: Ein Agent entscheidet über seine Einbettung in eine Umgebung (Environment Ǽ) aufgrund seiner Wahrnehmungen bezogen auf eine Zeitspanne t, welche „action“ durchzuführen ist. Die Umgebung Ǽ besteht dabei aus einer Menge von diskreten Zuständen ei

E

^ e0 , e1 , , ei , `

(1.2)

während ein einzelner Agent Ag über ein Repertoire von möglichen „actions“ Dj verfügt, die den Zustand der Umgebung Ǽ verändern.

Ac

^D

0

,D1 , ,D j , `

(1.3)

Ein „run“ r  Ac definiert sich dabei als „Zustands-Aktions-Sequenz“ der Form D0

r : e0

o

D1

e1

o

D3

D2

e2

o

e3

o

D u 1

 o eu  ƒ

(1.4)

wobei ƒ die Menge aller möglichen Sequenzen zu Ǽ und Ac ist. Die Gesamtmenge ƒ wird dabei noch durch die Teilmengen ƒAc sowie ƒE unterteilt, wobei ƒAc die Untermenge der „runs“ darstellt, die mit einer „action“ enden. ƒE definiert die Untermenge aller „runs“, die einen Zustand in Ǽ erzeugen, womit die Abbildungsvorschrift (1.1) vollständig erklärt ist.

1.5 Gruppierung von Agenten zu Multiagentensystemen Zur Lösung praktischer Problemstellungen reicht es – wie jedem sofort einleuchtet – nicht aus, nur „einen einzelnen“ Agenten zu entwickeln. Wegen der Problemkomplexität sind vielmehr immer mehrere Agenten erforderlich, die kooperativ untereinander und in Wechselwirkung mit menschlichen Aufgabenträgern, ggf.

330

Dietrich Hartmann

auch sich in Computernetzen bewegend, zur Problemlösung beitragen. Aus diesem Grunde ist man gezwungen, mehrere Agenten zu einem Multiagentensystem zusammenzuführen. Alle Teilprojekte im SPP 1103, die das Agentenparadigma einsetzen, mussten infolgedessen die für die Lösung von bestimmten Problembereichen aufgebauten Agenten zu einem Multiagentensystem zusammenfügen. Hierbei ist eine sich an der jeweiligen Struktur des Gesamtproblems orientierende Konstruktionssystematik (Architektur) zu beachten. Es hat sich dabei als zweckmäßig erwiesen, beim Zusammenbau der Einzelagenten zu einem funktionierenden Multiagentensystem ebenfalls einer formalen Begriffsdefinition für ein Multiagentensystem zu folgen, die Notationen aus der Definition des Agentenbegriffs aufgreift. Demnach ist ein Multiagentensystem (MAS) durch folgende Eigenschaften gekennzeichnet:

x Eine sich dynamisch verändernde Umgebung (Environment) E mit Volumen V. x Eine Menge von Objekten Obj die in E mit V geometrisch situiert ist und miteinander durch ein Produktmodell assoziert sind; die Objekte können dabei von den Agenten Ag des MAS wahrgenommen werden, ebenso kann auf ihnen mit Hilfe von „runs“ r agiert werden. x Eine Menge von Agenten Ag, die ihrerseits über ein zeitabhängiges Beziehungsgeflecht B = B(t), mit t als Zeitparameter, organisiert sind. x Eine Menge von Methoden M für die Agenten Ag. x Eine Menge von Operatoren Op, über die sich Gesetzmäßigkeiten im MAS definieren lassen. Die einfache Zusammenführung der Einzelagenten durch das Summationssymbol 6 mit

MAS

¦ Ag i , i 1, 2 ,3,

(1.5)

i

kann somit konkretisiert werden und lässt sich symbolisch darstellen als

MAS

(§¨ V, Obj ·¸ † ¦ Ag i Obj , Bt † ¦ M i  Ag i † Op i i ¹ © i

(1.6)

wobei das † - Symbol die Aggregation der einzelnen Bestandteile des MAS charakterisieren soll. Im Laufe der Projektbearbeitung im SPP 1103 hat sich dabei herausgestellt, dass sich die MAS-Architektur in der Bauplanung soweit wie möglich an die Struktur des tatsächlichen Beziehungsgeflechts der am Planungsprozess Beteiligten anzulehnen hat. Diese Erkenntnis hat dazu geführt, dass die MAS-Architektur diskriminatorisch in ressourcenorientierte Agenten, in aufgabenorientierte Agenten und Kooperationsagenten zu zerlegen ist. Über ressourcenorientierte Agenten werden gezielt datengetriebene Prozesse der Bauplanung unterstützt. Aufgabenorientierte Agenten sorgen durch Anwendung von so genanntem Software-Wrapping für die Bereitstellung von Werkzeugen bzw. existierender Software (CAD, FEM, DBMS etc.), so dass Software-

Überblick zum Themenbereich Agentensysteme

331

Prozesse (S-Prozesse) im Vordergrund des Interesses stehen; aber auch Prozesse allgemein, die Phänomene zeitlich-räumlicher Veränderungen beispielsweise durch numerische Simulation beschreiben, lassen sich gut durch aufgabenorientierte Agenten erfassen. Für die Koordinierung, Synchronisation und Navigation von Arbeitsabläufen werden Kooperationsagenten beauftragt, die zum Teil auch als persönliche Agenten für den einzelnen Benutzer konzipiert sind und als Mensch-Maschine-Schnittstelle dienen. Die an typischen Planungsaufgaben orientierte Mehr-Schichten-Architektur hat sich in allen Teilprojekten zur Agententechnologie als nützlich erwiesen; sie diente naturgemäß insbesondere auch als Brückenschlag zu den Nichtagentenbereichen im SPP 1103 (verteilte Produktmodelle, netzwerkgerechte Prozessmodellierung, verteilte Simulation) und führte zu zahlreichen Verknüpfungen.

1.6 Realisierung und Implementierung Für die Realisierung des Agentenparadigmas und für die softwaremäßige Implementierung der Agenten in ein MAS stehen zur Erleichterung des Software Engineering seit langem so genannte Agentenplattformen bereit, die auf anerkannten Standards der Foundation for Intelligent Physical Agents (FIPA) und der Object Management Group (OMG) beruhen. Eine direkt auf die Programmierung von MAS abgestellte Programmiersprache fehlt dagegen noch; diese ist nach wie vor Gegenstand der aktuellen Informatikforschung. Wichtige Voraussetzung für eine zügige und zuverlässige Umsetzung von Konzepten in gebrauchstaugliche Software ist dabei – wie schon in der traditionellen Softwareentwicklung – eine formal korrekte, in sich konsistente Modellierung, passend zur jeweiligen Problemstellung. In allen sich mit Agenten befassenden Teilprojekten des SPP 1103 wurde deshalb konsequenterweise die agentenbasierte Analysephase (Designphase) der eigentlichen Programmierung und Implementierung vorangestellt. Bei der agentenbasierten Analyse wurde sowohl vom Konzept nach Burmeister (Burmeister 1996) Gebrauch gemacht als auch von der Agent Unified Modeling Language (AUML), die ein auf Agentensysteme erweitertes Beschreibungskalkül der weltweit als Standard anerkannten UML darstellt (Huget et al. 2004). Im ersten Fall basiert die Modellierung auf drei Submodellen, erstens dem Agentenmodell zur Darstellung des Verhaltens und der Struktur der Einzelagenten, zweitens dem Organisationsmodell zur Beschreibung des Beziehungsgeflechts zwischen den einzelnen Agenten unter Ausnutzung objektorientierter Prinzipe (Vererbung, Aggregation etc.), und drittens dem die Systemdynamik abbildenden Kooperationsmodell, das durch Nachrichtenaustausch Interaktionen und Kommunikationen regelt. Im Fall der AUML werden bekannte Modelliermechanismen der Objektorientierung, insbesondere Klassen-, Zustands-, Sequenz-, Kollabaration- und Aktivitätsdiagramme (u. a. m.) für die Zwecke der Agentenmodellierung ergänzt und verbessert.

332

Dietrich Hartmann

Größte Bedeutung kommt der Kommunikation zwischen den Agenten zu, wobei so genannte Sprechakten eingeführt werden, die ihrerseits die verwendete subsymbolische Wissensverarbeitung unterstützen (Sprechakte lassen sich dabei als wissensabhängige, zielgerichtete Handlungsanweisungen auffassen, die „intelligente“ Mechanismen bewirken). Damit die sprechaktbasierte Kommunikation durch Nachrichtenaustausch funktionieren kann, wurde übereinstimmend in allen agentenbezogenen Teilprojekten des SPP 1103 mit Fachontologien gearbeitet. Ontologien definieren eindeutig fachspezifische Begrifflichkeiten und semantische Zusammenhänge, so dass für alle beteiligten Agenten ein gemeinsamer Wortschatz geprägt werden kann. Mögliche Missverständnisse werden somit (weitgehend) vermieden. Im Rahmen der Forschungsarbeiten hat sich zudem herausgestellt, dass eine Mischung von Fachontologien und Interaktionsprotokollen mit standardisierten Kommunikationssprachen (hier neben der Knowledge Query Manipulation Language (KQML) vor allem die FIPA-Agent Communication Language (ACL)) für die spätere Softwareimplementierung äußerst förderlich ist; alle technischen Aspekte beim Austausch von Daten und Wissen über Nachrichten lassen sich damit berücksichtigen. Basierend auf dem oben beschriebenen konzeptuellen „Grundgerüst“ hat sich die Implementierung der im SPP 1103 aufgebauten Agentensysteme – mangels geeigneter direkter Agentenprogrammiersprachen – auf verfügbare, so genannte Agentenplattformen abgestützt. Derartige Plattformen sind in den letzten Jahren sowohl durch die Informatikforschung als auch durch kommerzielle Entwicklung in größerer Zahl entstanden und stellen sowohl eine Entwicklungsumgebung als auch eine Agentenlaufzeitumgebung bereit. Nach einer Test- und Erprobungsphase mit mehreren Agentenplattformen zu Beginn der SPP 1103-Förderphase wurde überwiegend dem Java Agent Development Framework (JADE) der Vorzug gegeben. JADE ist – vorteilhaft für ohnehin schon objektorientiert umgesetzte Ingenieursoftwarelösungen – vollständig in JAVA implementiert; zudem werden alle FIPA-Agentenstandards konsequent eingehalten. Darüber hinausgehend lassen sich mit JADE aufgebaute Agenten auch mit mobilen Fähigkeiten ausstatten, die insbesondere im Teilprojekt an der TUDarmstadt erforderlich waren. Die derzeit von JADE vorgegebene Mobilitätseinschränkung, nach der Agenten nur innerhalb einer Plattform, wenn auch über ein Rechnernetzwerk, „migrieren“ dürfen, konnte dabei durch eigene Erweiterungen der Forscher in Darmstadt kompensiert werden. Bei der Implementierung der Agenten kam der Bereitstellung von Fachwissen unterschiedlicher Domänen eine große Bedeutung zu, da „Wissen“ ursächlich reaktives, proaktives und naturgemäß intelligentes Verhalten der Agenten bestimmt und somit das Antwortverhalten bei Problemlösungen beschleunigt. Die im SPP 1103 dominant eingesetzte Agentenkommunikationssprache ACL wird dabei durch das Knowledge Interchange Format (KIF) erreicht, durch das „Wissen“ in geeigneter Form kodiert werden kann. Vorrangig diente das KIF als eine Zwischensprache, um die Anzahl notwendiger Übersetzungsmodule für den Austausch zwischen verschiedenen Agenten-Wissensbasen auf ein Mindestmaß von

Überblick zum Themenbereich Agentensysteme

333

zwei pro Wissensbasis zu reduzieren, da nur noch „nach“ und „von“ KIF zu transformieren ist. Durch Ausnutzung der gerade erläuterten symbolischen Art der Wissensverarbeitung (Symbolverarbeitung) ist es gelungen, bekannte Ansätze aus der verteilten KI bzw. Konzepte der kooperativen Expertensysteme in die Agententechnologie einzubringen. Dies ist ein klares Indiz dafür, dass die Agententechnologie als Fortschreibung und Weiterentwicklung der „klassischen“ Wissensverarbeitung angesehen werden kann. Für die Implementierung auf JADE-Basis nützlich war dabei die Tatsache, dass mit der Java Expert System Shell (JESS) ein ebenfalls in JAVA geschriebenes Wissensbasiertes System (WBS) existiert, über das sich prozedurales, objektorientiertes und regelbasiertes Wissen verarbeiten lässt. Als Inferenzmechanismus wird dabei ein besonders effizienter Rete-Algorithmus eingesetzt. Intelligentes Verhalten bei Agentensystemen bzw. MAS muss aber – wie die Forschungsergebnisse aus dem SPP 1103 deutlich belegen – nicht nur allein an die symbolische Wissensverarbeitung geknüpft sein. Das heißt, nicht jeder intelligente Agent muss auf der Symbolverarbeitung der KI gegründet sein. Intelligentes Verhalten kann vielmehr auch aus dem auf Kommunikation beruhenden Multiagentenansatz herrühren. Die einzelnen Agenten müssen somit nicht in jedem Fall ein „Expertensystem“ enthalten – oder ein Künstliches Neuronales Netzwerk (KNN) repräsentieren. Die Intelligenz in einem MAS beruht im Gegenteil zu einem Großteil auf Interaktion, Kooperation, Abstimmung der Agenten untereinander – gestützt auf ein klar konzipiertes Kommunikationskalkül. Die von einem MAS erbrachte Leistung beruht folglich ganz wesentlich auf subsymbolischen KIKonzepten, bei denen die flexible Zusammenarbeit mehrerer einfacher Einzelagenten komplexe Problemlösungen bewirkt (emergentes System / kenetisches Konzept). Ein ebenfalls nicht unerheblicher Teil der Intelligenz eines MAS wird außerdem durch die Interaktion der (persönlichen) Agenten mit ihren Auftraggebern (Fachexperten) eingetragen: Durch die Benutzerführung über eine grafische Benutzeroberfläche (GUI) lässt sich im Dialog gezielt „Wissen“ erfragen.

1.7 Ausblick Die in jüngster Zeit auf dem Gebiet der Agententechnologie gemachten Fortschritte in der Informatikforschung lassen weitere Verbesserungen für die agentenbasierte Bauplanung erkennen. Insbesondere die softwaretechnische Implementierung von MAS wird zunehmend erleichtert, da – nachdem die Analyse, die Spezifikation und der Entwurf von Agentensystemen bzw. MAS hinreichend erforscht worden sind – inzwischen eine stärkere Betonung der Implementierungsund Programmierungsaspekte erfolgt. Die Arbeiten von Fisher (Fisher 2005) und Winikoff (Winikoff 2005) belegen diesen Trend exemplarisch. Hierdurch werden der Weg und die Zeitspanne, aber auch die momentan noch bestehenden Lücken zwischen der Analyse- und der Entwurfs(Design)phase besser als bisher überbrückt. Durch die Bereitstellung verbesserter neuer MAS-Programmiersprachen

334

Dietrich Hartmann

mit eigenständiger Syntax und Semantik sind erhebliche Effizienzsteigerungen in der agentenbasierten Bauplanung zu erwarten. Agenten, die auf diesen neuen Konzepten aufbauen, lassen sich in sich konsistenter und gradliniger mit bereits existierender Software (Wrapping) verknüpfen. Organisations- und Beziehungsgeflechte, das „A“ und „O“ in den Arbeitsmodellen der Bauplanung, lassen sich besser als bisher – und auch feingranularer – realisieren. Dies betrifft auch die Programmierung mobiler im Rechnernetz migrierender Agenten, die unterschiedliche Plattformen nutzen. Nach den neuesten Erkenntnissen der Agentenforschung ist man sich zudem darüber einig, dass die Einbindung und zutreffende Abbildung der Umgebung, in die Agenten eingebettet sind, von zunehmend essentieller Bedeutung für den Gesamterfolg eines Projektes sind. Verbesserungen in dieser Richtung würden auch der agentenbasierten Bauplanung zugute kommen. Neue Impulse für die Agententechnologie im Bauwesen kann man des Weiteren durch bessere, lernfähige Agenten erwarten. Die Lernfähigkeit von einzelnen autonomen Agenten, die immer dann wichtig ist, wenn Ungewissheiten eine Entscheidungsfindung beeinflussen, wird bereits relativ gut verstanden und ist realisierbar. Probleme gibt es aber noch, wenn mehrere Agenten eines MAS zusammenarbeiten. In diesem Fall sind die Lernmechanismen komplexer, da unterschiedliche Ziele existieren und die einzelnen Agenten unterschiedliche Fähigkeiten besitzen. Forschungsresultate auf diesem Gebiet können in Zukunft weitere begrüßenswerte Zuschärfungen auch im Bereich der agentenbasierten Bauplanung bieten.

Literatur Bauer B, Odell J (2004) AUML – First Steps. Proceedings of the SCI/ISAS 2000, Orlando, USA Bilek J, Hartmann D (2002) Kooperative Tragwerksplanung basierend auf Multiagentensystemen. VDI-Berichte 1668, Bauen mit Computern Burmeister B (1996) Models and methodology for agent-oriented analysis and design. Working Notes of the KI ’94. Workshop on Agent-Oriented Programming, Fisher K (ed), DFKI Document D96-06 Ferber J (2001) Multiagentensysteme – Eine Einführung in die Verteilte Künstliche Intelligenz. Dtsch. Übersetzung Kirn S, Addison-Wesley Fisher M (2005) Programming Dynamic Agent Organisations. III. Int. Workshop on Programming Multi-Agent Systems, AAMAS Workshop (AC 2005) Hayes-Roth B, Washington R (eds) (1992) Guardian – a Prototype Intelligent Agent. Artifical Intelligence in Medicine 4(2) Russel S, Norwig P (1995) Artifical Intelligence – A modern Approach. Prentice Hall Winikoff M (2005) An Agent Speak Meta-Interpreter and its Applications. III. Int. Workshop on Programming Multi-Agent Systems, AAMAS Workshop (AC 2005) Woolridge M, Jennings N (1994) Towards a Theory of Cooperative Problem Solving. MAAMAN ’94, Springer Verlag, Odense, Danmark

2 Agentenbasierter Modellverbund für die kooperative Gebäudeplanung

Uwe Rüppel, Michael Lange, Mirko Theiß Technische Universität Darmstadt, Institut für Numerische Methoden und Informatik im Bauwesen {rueppel | lange | theiss}@iib.tu-darmstadt.de

2.1 Einleitung und Zielsetzung Die effiziente und qualitätsvolle Kooperation aller beteiligten Fachplaner ist die Voraussetzung für einen bestmöglichen Bauplanungsprozess. Die Bauprojektorganisation besteht in der Regel aus zahlreichen unabhängigen Planungspartnern, die örtlich verteilt spezifische Planungsaufgaben bearbeiten. Durch dieses hohe Maß an Arbeitsteilung muss eine große Zahl von Planungsinformationen ausgetauscht werden. Fehlende oder nicht vollständig ausgetauschte Informationen können in der Folge Planungsfehler hervorrufen. Des Weiteren ist es zur Sicherstellung der Konsistenz der Planung und der Qualität des Bauproduktes notwendig, dem einzelnen Fachplaner die Auswirkungen seiner Planungsentscheidungen auf das Gesamtbauwerk darzustellen. Ziel dieses Projekts war es, die Fachdomänen des Bauplanungsprozesses nicht isoliert, sondern in einem verteilten Modellverbund als Ganzes zu betrachten. Neu an diesem Ansatz ist die verteilte, modellbasierte Bereitstellung von Planungsinformationen in einer Multiagentenumgebung, wobei im Gegensatz zu bestehenden zentralen Ansätzen jeder Planer die Hoheit über seine Planungsinformationen behält und diese gezielt Partnern zur Durchführung ihrer Planungsaufgaben zur Verfügung stellt. Sämtliche Planungsinformationen werden modellbasiert zur ganzheitlichen Abbildung der Gebäudeplanung innerhalb des Modellverbundes bereitgestellt. Der modellbasierte Ansatz erlaubt eine rechnergestützte Plausibilitätsüberprüfung von einzelnen Planungsleistungen. Im Rahmen des Projekts wurde unter Nutzung des verteilten Modellverbundes eine Konsistenzüberprüfung zu anderen Fachmodellen realisiert, die jedem Planer eine Analyse der Korrektheit der eigenen Planungen ermöglicht und die Auswirkungen auf andere Planungen darstellt. Am Beispiel der

336

Uwe Rüppel, Michael Lange, Mirko Theiß

Überprüfung der Anforderungen des baulichen Brandschutzes wurde die Funktionsweise des entwickelten verteilten Modellverbundes erprobt.

2.2 Beitrag des Projekts zu den Gesamtzielen des SPP und den Zielen der Arbeitsgruppe Vorhandene Software-Methoden und Werkzeuge zum Austausch von Fachinformationen des Bauplanungsprozesses zwischen den Planungspartnern decken die Kommunikations- und Kooperationsbedürfnisse der Bauprojektorganisation nicht ausreichend ab. Sie ersetzen vielmehr bisherige analoge Kommunikationsmöglichkeiten wie Briefpost, Fax oder Telefon durch entsprechende digitale Varianten wie E-Mail und digitale Dokumente. Eine Abbildung der Bauprojektorganisation erfolgt hiermit nicht. Neue informatische Ansätze bieten die Möglichkeit, die starke Verteiltheit der Bauprojektorganisation mit Planungswerkzeugen abzubilden. Im Rahmen der Arbeitsgruppe „Agentensysteme“ wurden die Möglichkeiten von Softwareagenten bzw. Multiagentensystemen im Hinblick auf die Umsetzung der folgenden vier Hauptziele erforscht und weiterentwickelt: 1. Im Projekt wird der Agenten-Ansatz zur Integration verteilter Fachmodelle in heterogene Planungsstrukturen verfolgt. Im Gegensatz zu Projektkommunikationssystemen existiert hierbei kein zentraler Datenpool. Die Fachinformationen werden in einem Modellverbund verteilt zur Verfügung gestellt. Dieser Modellverbund spiegelt die reale Verteilung der Fachinformationen im Bauplanungsprozess wieder, wobei der Planer die Hoheit über die von ihm erzeugten Planungsinformationen behält und gezielt Planungspartnern zur Verfügung stellt. 2. Planungsentscheidungen betreffen nicht immer nur einen klar begrenzten Ausschnitt aus dem Gesamtbauprojekt. Dem Fachplaner muss es daher möglich sein, die verteilt vorliegenden Fachinformationen zu nutzen, um die Auswirkungen seiner Planungsentscheidungen abschätzen zu können. Im Projekt werden dem Fachplaner am Beispiel der Überprüfung der Anforderungen des baulichen Brandschutzes mobile Verarbeitungsmethoden zur interdisziplinären Nutzung von Fachinformationen zur Verfügung gestellt. Unter Nutzung der mobilen Verarbeitungsmethoden können Fachinformationen aus den verteilten Modellen beschafft und gemeinsam verarbeitet werden. Die Kommunikation zwischen den Beteiligten wird hierbei auf der Basis von Agenten durch so genannte Interaktionsprotokolle abgebildet. Beim Austausch der Fachinformationen werden in der Regel unterschiedliche Informationsschemata genutzt. Die semantische Beschreibung der Informationen erfolgt daher unter Nutzung von Fachontologien. 3. Eine Integration bestehender Ressourcen erfolgt durch das so genannte Wrapping. Zur Informationsbereitstellung nach außen wird eine Schnittstelle definiert, über die Informationsressourcen mit definierter Semantik im Pla-

Agentenbasierter Modellverbund für die kooperative Gebäudeplanung

337

nungsverbund zur Verfügung gestellt werden können. Diese Informationen können von mobilen Verarbeitungsmethoden weiterverarbeitet werden. 4. Die Funktionsweise des verteilten Modellverbundes wird am Beispiel der Überprüfung von Anforderungen des baulichen Brandschutzes in der Gebäudeplanung dargestellt. Hierzu sind agentenbasierte Verfahren zur Regelverarbeitung und die Bereitstellung von Regelwerken zur zielgerichteten Verarbeitung notwendig. Die textbasierten Regeln werden in einem Regelmodell abgebildet und durch einen Schlussfolgerungsmechanismus gemeinsam mit den Fachinformationen der verteilten Produktmodelle verarbeitet. Die Entwicklung der erarbeiteten Methoden geschah in enger Kooperation mit Forschungsprojekten aus dem DFG Schwerpunktprogramm 1103. Das in diesem Bericht vorgestellte Multiagentensystem wurde in enger Zusammenarbeit mit den Projekten der Arbeitsgruppe Agentensysteme konzipiert (Cremers et al. 2003; Hartmann et al. 2004). Besonders die Erforschung der Kommunikationsmechanismen auf der Basis von Interaktionsprotokollen und Ontologien wurde zusammen mit dem Projekt „Kooperative Tragwerksplanung basierend auf Multiagentensystemen und adaptiven Assoziationsnetzen“ durchgeführt. Bei der Entwicklung der Verfahren zur Regelverarbeitung fand ein reger Austausch mit dem Projekt „Neue Software-Werkzeuge zur Unterstützung des konzeptuellen Gebäudeentwurfs“ statt. Methoden zur Einbindung der agentenbasierten Methoden in die Planungsprozesse des Bauwesens wurden in Zusammenarbeit mit dem Projekt „Prozessorientierte Vernetzung von Ingenieurplanungen am Beispiel der Geotechnik“ erarbeitet (Meißner et al. 2003; Rüppel et al. 2003a).

2.3 Agentenbasierter Modellverbund Der Informationsaustausch erfolgt in der Gebäudeplanung traditionell auf der Basis relativ flacher Datenmodelle. Für eine effektive kooperative Planung in einem Computernetzwerk müssen diese Informationen semantisch interpretierbar sein. Die Interpretation eines Planes in der Gebäudeplanung ist jedoch ausschließlich durch das Wissen eines Fachplaners möglich. Die Planungsinformationen müssen für den zu entwickelnden Modellverbund in konsistenten Teilproduktmodellen gemäß dem objektorientierten Paradigma abgebildet und bereitgestellt werden (Rüppel 2002). Der bauliche Brandschutz stellt durch seine interdisziplinäre Ausprägung und aus baufachlicher Sicht besondere Ansprüche an die Modellierung. Die Elemente des baulichen Brandschutzes sind keine neuen Bauteile oder Elemente eines Gebäudes, sondern definieren vielmehr spezielle Anforderungen an vorhandene Bauteile. Eine Brandwand mit einer speziellen Feuerwiderstandsklasse legt bestimmte Anforderungen an das zu verwendende Material, die Geometrie und auch die bauliche Durchbildung fest. Die Überprüfung des baulichen Brandschutzes kann somit nur erfolgen, wenn Informationen aus den Teilproduktmodellen verschiedener Fachplaner zusammengeführt werden.

338

Uwe Rüppel, Michael Lange, Mirko Theiß

Zur Lösung der zuvor beschriebenen Aspekte wurde auf der Basis der AgentenEntwicklungs-Plattform JADE (Bellifemine 2006) das agentenbasierte Planungssystem MADITA (Multiagentsystem for Distributed Fire Engineering Tasks) entworfen (Theiß 2005). Abbildung 2.1 skizziert das Gesamtsystem. Die Arbeit mit dem Modellverbund ist durch vier zentrale Aspekte geprägt: 1) die Modellerzeugung, 2) die Modellbereitstellung, 3) den Modelltransport und 4) die Modellverarbeitung. Modellerzeugung

Modellbereitstellung Architekt

Modellerzeugung

Modellbereitstellung

Modellerzeugung

Modelltransport Modelltransport

Modellverarbeitung

Tragwerksplaner

Modelltransport

Modelltransport Modellbereitstellung

Modellbereitstellung Regelwerke

Modellerzeugung

Brandschutzplaner

Abb. 2.1. Agentenbasiertes Planungssystem MADITA

Jeder Planer stellt seine Informationen in einem eigenen Fachmodell zur Verfügung, zusätzlich werden die Vorschriften und Regeln der Landesbauordnungen in einem Regelmodell bereitgestellt. Gemeinsam bilden die verteilten Teilproduktmodelle den Modellverbund zur kooperativen Gebäudeplanung. Die kooperative Bearbeitung der Teilproduktmodelle wird durch Softwareagenten ermöglicht. Informationen aus den Teilmodellen werden den berechtigten Fachplanern des Modellverbundes mit Hilfe von Wrapper-Agenten zur Durchführung ihrer Planungen bereitgestellt (Rüppel et al. 2002a). Die kooperative Planung auf Basis des Modellverbundes wird am Beispiel der Überprüfung der Planungen hinsichtlich der Anforderungen des baulichen Brandschutzes vorgestellt. Der hierzu notwendige Informationsaustausch wird durch mobile Informations-Transport-Agenten unterstützt (Meißner et al. 2004). Diese werden beauftragt, bestimmte Informationen aus den Teilproduktmodellen der kooperierenden Planer zu ermitteln. Um eine konsistente Brandschutzplanung sicherzustellen, kann jeder Planer einen Brandschutz-Agenten zur Überprüfung seiner Planungsleistungen anfordern. Der Brandschutz-Agent benötigt zur Durchführung der Überprüfungen Informationen aus den Teilproduktmodellen. Diese werden unter Nutzung der InformationsTransport-Agenten und Wrapper-Agenten aus dem Modellverbund beschafft. Nach der Durchführung der Überprüfungen bekommt der Planer das Ergebnis dargestellt und kann, falls erforderlich, seine Planung frühzeitig korrigieren.

Agentenbasierter Modellverbund für die kooperative Gebäudeplanung

339

2.4 Fachmodelle zur verteilten Brandschutzplanung Im Gegensatz zum Gebäudeentwurf existieren für den baulichen Brandschutz keine modellbasierten Planungswerkzeuge. Die Planung des baulichen Brandschutzes erfolgt bisher durch das Einfügen von Symbolen in Plänen. Außerdem wird eine gesonderte textbasierte Beschreibung der Maßnahmen in einem Brandschutzkonzept vorgenommen. Im Rahmen dieser Arbeit wurde ein Fachmodell basierend auf den Industry Foundation Classes (IAI 2002) zur ganzheitlichen Abbildung des Brandschutzwissens und Fachanwendungen zur Bearbeitung dieses Fachmodells entwickelt. Die Brandschutzplanung definiert im Bauplanungsprozess keine neuen Gebäudeelemente, sondern formuliert Anforderungen an Elemente des Gebäudes. Die Abbildung des Brandschutzwissens in einem isolierten Modell ist nicht möglich, vielmehr müssen zur ganzheitlichen Planung des baulichen Brandschutzes die vorhandenen Teilproduktmodelle des Bauwesens integriert werden. Zu jedem Brandschutzelement müssen das zugehörige Element des Gebäudemodells und die entsprechenden Brandschutzregeln abgebildet werden. Abbildung 2.2 stellt die drei Elemente zur ganzheitlichen Betrachtung des Brandschutzwissens dar (Meißner u. Rüppel 2003). Im Folgenden wird näher auf die Anforderungen an diese Modelle eingegangen.

Brandschutzregeln

Brandschutzmodell

Gebäudemodell

Abb. 2.2. Elemente zur ganzheitlichen Betrachtung des Brandschutzwissens

2.4.1 Gebäudemodell Basis aller Planungen ist das digitale Gebäudemodell. Dieses Modell strukturiert das Gebäude nach dem objektorientierten Paradigma hierarchisch in seine Elemente. Der Architekt als Ersteller des Gebäudemodells legt in den frühen Planungsphasen der Gebäudemodellierung lediglich die grobe Strukturierung des Gebäudes fest und orientiert sich hierbei an der Nutzung des Gebäudes. Dies betrifft

340

Uwe Rüppel, Michael Lange, Mirko Theiß

vor allem Stockwerke, Räume, Flure und Bauteile. Diese Objekte werden hauptsächlich mit geometrischen Eigenschaften, Materialien oder auch im Fall von Räumen mit Nutzungseigenschaften attributiert. Das Gebäudemodell besitzt i.d.R. alle notwendigen Informationen, um auf dieser Basis die Planung des baulichen Brandschutzes durchzuführen. 2.4.2 Brandschutzmodell Für die Verarbeitung der Anforderungen des baulichen Brandschutzes müssen die bisher textbasierten Informationen eines Brandschutzkonzeptes in einem für die rechnergestützte Verarbeitung nutzbaren Modell abgebildet werden. Ein solches Modell existierte bisher noch nicht. Das Brandschutzmodell beschreibt die Anforderungen des baulichen Brandschutzes an Elemente des Gebäudemodells und anderer Teilproduktmodelle. Abbildung 2.3 illustriert einen Teil der zahlreichen Beziehungen zwischen Brandschutz- und Gebäudemodell. Dementsprechend ist es sinnvoll, Beziehungen zu dem vorhandenen Gebäudeobjekt zu modellieren. Das Brandschutzobjekt Brandwand besitzt beispielsweise keine eigene geometrische Ausprägung. Die Geometrie ist identisch mit der zugehörigen Wand des Gebäudemodells. Gebäudeelemente Nutzungszone Baustoff Decke, Wand

Brandschutzelemente Brandausbreitung Brandabschnitt

Brandwand Rettungsweg

Tür Treppe, Flur

Brandschutztür

Fenster

Brandschutzglas

...

...

Abb. 2.3. Beispielhafte Darstellung der Beziehungen von Elementen der Gebäudeplanung und des baulichen Brandschutzes

Durch die Modellierung der Beziehungen zwischen den korrespondierenden Objekten der Fachmodelle ist es möglich, Abhängigkeiten zwischen Objekten zu erkennen. Der Bearbeiter kann von seiner Fachanwendung auf vorhandene Beziehungen zu Objekten anderer Fachplaner hingewiesen werden. Hierdurch wird er bei der Bearbeitung des Modells aktiv zur Sicherstellung einer konsistenten Gebäudemodellierung, auch über seinen Wissensstand hinaus, unterstützt. Die entwickelte Fachanwendung zur Modellierung des baulichen Brandschutzes verhindert

Agentenbasierter Modellverbund für die kooperative Gebäudeplanung

341

beispielsweise das Löschen von Gebäudeelementen, solange Brandschutzelemente mit ihnen verknüpft sind. Das im Rahmen dieses Projekts realisierte Brandschutzmodell ist in Abb. 2.4 ausschnittsweise dargestellt. Die Darstellung des Modellverarbeitungskonzeptes in diesem Projekt wurde auf bauliche Elemente beschränkt. Weitere Elemente der Technischen Gebäudeausstattung wie Sprinkler und Brandmeldesysteme können durch die durchgängig objektorientierte Modellbildung nach Bedarf flexibel integriert werden. BS_Modell -gebaeude_id n

n

BS_Bauteil

BS_Element

-hersteller -artikelnummer -artikelbeschreibung

Rettungsweg -ID -bezeichnung -typ -element_id_Liste -einzugsobjekt_id_Liste

Brandabschnitt -ID -objekt_id_Liste -bezeichnung

Brandwand -ID -bezeichnung -innerer_Abschnitt -funktion -feuerwiderstandsklasse -wand_id_Liste

Decke -ID -bezeichnung -funktion -innerer_Abschnitt -feuerwiderstandsklasse -decken_id_Liste

Abb. 2.4. Ausschnitt aus dem Brandschutzmodell

Zur Bearbeitung des Brandschutzmodells auf der Basis des Gebäudemodells wurde die Software „Brandschutzmodellierer“ als Modul der CAD-Software Architectural Desktop von Autodesk entwickelt, das in Abb. 2.5 dargestellt ist (Meißner et al. 2005).

Abb. 2.5. Darstellung von Brandwänden mit dem „Brandschutzmodellierer“

342

Uwe Rüppel, Michael Lange, Mirko Theiß

2.4.3 Regelmodell Im Gebäude- und Brandschutzmodell werden die Fakten eines Gebäudes abgebildet. Zur Überprüfung der Anforderungen des baulichen Brandschutzes ist es darüber hinaus notwendig, entsprechende Regeln zu modellieren. Regeln des baulichen Brandschutzes haben vornehmlich einen deklarativen Charakter (Rüppel et al. 2002b). Sie beschreiben eine Anforderung in der Form „Wenn X kleiner als Y ist, dann ist Z falsch“. Diese Form der Wissensdarstellung lässt sich sehr gut in regelbasierten Schlussfolgerungssystemen verarbeiten. Es ist notwendig, die Regeln fachlich zu strukturieren und damit die Zahl der zu verarbeitenden und auszutauschenden Regeln zu minimieren, um eine effiziente Kommunikation und Verarbeitung zu gewährleisten (Meißner u. Rüppel 2003). Hierfür wurden die Hauptmerkmale zum Auffinden einer Regel genutzt:

x das Bundesland, in dem sie gültig ist, x der Gebäudetyp, den die Verordnung behandelt und x das Gebäudeelement, für das Anforderungen ausgedrückt werden. Unter Nutzung der in Abb. 2.6 dargestellten Hierarchie lassen sich die Regeln effizient recherchieren. Bei der Verarbeitung wird hierdurch mit einer überschaubaren Anzahl von Regeln gearbeitet.

Bundesland

Hessen

Gebäudeklasse Gebäudeklasse 5

Brandschutzelement Brandwand

fire-class >= F90

Brandschutzregel

Abb. 2.6. Kategorisierung der Brandschutzregeln aus Bauordnungen und Richtlinien

Agentenbasierter Modellverbund für die kooperative Gebäudeplanung

343

2.5 Modellverbund zur verteilten Brandschutzplanung Im Ingenieurwesen hat sich gezeigt, dass vor allem bei komplexeren Aufgaben kleine Teilprobleme von Spezialisten effizient gelöst werden können. Fasst man die einzelnen Teillösungen zusammen, erhält man die Lösung des Gesamtproblems. Dieses Prinzip der Problemdekomposition liegt ebenfalls den so genannten Multiagentensystemen zugrunde. Das oben beschriebene Konzept des Modellverbundes wurde daher im Rahmen dieses Projekts als ein solches System umgesetzt (Theiß 2005). Multiagentensysteme bieten sich zur Realisierung der Informationsbereitstellung, sowie des Informationstransports und der -verarbeitung im Modellverbund an. Diese drei Basisaspekte des agentenbasierten Modellverbundes zur verteilten Überprüfung des baulichen Brandschutzes werden im Folgenden näher dargestellt. 2.5.1 Agentenbasierte Informationsbereitstellung Die Informationsbereitstellung und damit die Veröffentlichung der Informationen für Kooperationspartner sollten in einer ähnlichen Art und Weise erfolgen, wie es der Fachplaner aus seiner bisherigen Arbeitsweise gewöhnt ist. Bisher erfolgt diese Bereitstellung durch Versand von Plänen und Dokumenten an die Planungspartner. Eine Veranlassung zum Versenden ist immer dann gegeben, wenn der Fachplaner zu einer Weitergabe der Informationen im Rahmen des Bauplanungsprozesses verpflichtet ist oder er eine Anfrage eines anderen Planungsbeteiligten beantwortet. erzeugen

n

he

lic

nt

ffe

rö

Gebäudemodell

ve

bearbeiten

Architekt

erzeugen bearbeiten

Tragwerksmodell

veröffentlichen

Modellverbund

Tragwerksplaner n

erzeugen bearbeiten

Brandschutzmodell

he

lic

nt

fe öf

r

ve

Brandschutzplaner

Abb. 2.7. Veröffentlichung von Teilmodellen zur kooperativen Bearbeitung im Modellverbund

344

Uwe Rüppel, Michael Lange, Mirko Theiß

Für den Modellverbund bedeutet dies, dass die Modellinformationen durch geeignete Mechanismen an einem bestimmten Ort im Verbund bereitgestellt werden müssen. Von diesem Ort aus werden die Informationen allen Beteiligten und berechtigten Planungspartnern zur Verfügung gestellt (Abb. 2.7). Zur Integration von Informationsbeständen oder auch bestehender Anwendungen in ein neues System hat sich in der Forschung und Praxis das so genannte Wrapping (Umhüllung) etabliert (Sneed 2000). Hierbei wird eine Umhüllende geschaffen, welche die Informationsbereitstellung nach außen organisiert und so eine Schnittstelle definiert. Auf dem Gebiet der Agentensysteme hat die Foundation for Intelligent Physical Agents (FIPA) einen entsprechenden Wrapper-Agenten spezifiziert (FIPA 2001). Dieser Wrapper-Agent kapselt beliebige Informationsquellen und stellt die darin enthaltenen Informationen über seine Kommunikationsschnittstellen in einem Multiagentensystem zur Verfügung (Bilek u. Hartmann 2003). Für jede Informationsquelle wird im Rahmen dieses Projekts ein WrapperAgent spezifiziert, der als Schnittstelle zum Gesamtverbund arbeitet. Der Wrapper-Agent kennt die zu kapselnde Informationsquelle genau und kann dort ermittelte Informationen in einem der Umwelt bekannten Schema bereitstellen. Ein gemeinsames Schema ist zwingend erforderlich, da nicht davon ausgegangen werden kann, dass sämtliche benötigte Informationen nach demselben Schema gespeichert werden. 2.5.2 Fachgerechte Kommunikation zur Informationsrecherche Bisher wurde die Bereitstellung der Modellinformationen im agentenbasierten Modellverbund beschrieben. Im Folgenden wird der Austausch der Modellinformationen zwischen den Planungspartnern näher betrachtet. Die Kommunikation zwischen Planungspartnern im Bauwesen erfolgt in der Regel Punkt-zu-Punkt. Das bedeutet, ein Beteiligter stellt eine Anfrage, die ein weiterer direkt angesprochener Beteiligter beantwortet. In einigen Fällen müssen zur Beantwortung einer Fragestellung weitere Informationen eingeholt werden, die dann wiederum durch eine Punkt-zu-Punkt-Kommunikation abgebildet werden. Zentraler Aspekt der Kommunikation innerhalb des Modellverbundes ist die Recherche nach Informationen und der Austausch von Teilmodellen auf Basis der beschriebenen Punkt-zuPunkt-Kommunikation. Im Mittelpunkt der Eigenschaften von Softwareagenten stehen ihre Fähigkeiten, durch ein Netzwerk zu migrieren und untereinander auf Basis einer vorher festgelegten Methodik zu kommunizieren. Agenten sollen ihren Besitzern „Alltagsarbeiten“ abnehmen. Diese Arbeiten beanspruchen oft eine enorme Zeit und dienen als Grundlage für die Bearbeitung der eigentlichen Problemstellung. Im Rahmen dieser Arbeit werden verschiedene Dienste in den Modellverbund integriert, die den Planer beispielsweise bei der Recherche und Beschaffung von Modellinformationen bei seinen verteilten Planungspartnern unterstützen. Hierzu ist eine Kommunikation zwischen den oben vorgestellten Wrapper-Agenten notwendig.

Agentenbasierter Modellverbund für die kooperative Gebäudeplanung

345

Diese Kommunikation basiert auf definierten Sprechakten. Interaktionsprotokolle strukturieren die Kommunikation, indem sie eine genaue Sequenz von Sprechakten vorgeben (Rüppel u. Lange 2006). Unter Nutzung der Interaktionsprotokolle gewinnt ein Agent Informationen oder führt Verhandlungen durch. In Abb. 2.8 ist ein Gesprächsablauf bei der Beschaffung von Modellinformationen zwischen einem mobilen Informations-Transport-Agenten und dem stationären Wrapper-Agenten mithilfe des zugehörigen Interaktionsprotokolls als AUMLSequenzdiagramm dargestellt (Odell et al. 2000). Gebäudemodell-Wrapperagent

Rechercheagent

Request: Authentifizierung mit Passwort

Refuse: Anfrage nicht verstanden

Agree: Anfrage wird bearbeitet

Failure: Authentifizierung fehlgeschlagen [agreed] Inform: Authentifizierung angenommen

Query: Wand mit ID 1234

Refuse: Anfrage nicht verstanden

Agree: Anfrage wird bearbeitet

Failure: Wand nicht vorhanden [agreed] Inform: Modell von Wand 1234

Abb. 2.8. Interaktionsprotokoll zum Kommunikationsablauf bei der Informationsrecherche mit Hilfe von Softwareagenten

2.5.3 Semantische Beschreibung des Kommunikationsinhaltes Der zuvor beschriebene Kommunikationsprozess stellt lediglich eine Folge von Sprechakten dar. Für eine erfolgreiche Kommunikation ist jedoch auch die semantische Interpretation des Kommunikationsinhaltes notwendig (Rüppel et al. 2005). Im in Abb. 2.9 gezeigten Beispiel führt die Kommunikation ausschließlich zu einem Erfolg, wenn beide Partner die Wörter „Wand“ und „mit ID“ identisch interpretieren. Nur durch diese gleiche Interpretation ist gewährleistet, dass auf die Anfrage auch wirklich die gesuchte Wand geliefert wird.

346

Uwe Rüppel, Michael Lange, Mirko Theiß

Request

AgentAction

-type -value

Logon

Logoff

Select

Insert

Update

Delete

-responseType

Abb. 2.9. Aktionsontologie

Hierzu wird eine weitere Nachrichtenschicht eingeführt. Diese Schicht vereinbart eine Ontologie, die den Inhalt der Nachricht genauer beschreibt (Hartmann et al. 2004). Der Sprechakt beschreibt nur grob die Intention der Nachricht (z.B. Request). Fachspezifische Aktionen wie das Übermitteln der Authentifizierungsinformationen müssen hingegen korrekt interpretiert und ausgeführt werden. Hierfür wurde eine spezielle Aktionsontologie entworfen, die in Abb. 2.9 dargestellt ist. Der Inhalt eines Request-Sprechaktes kann auf Basis dieser Ontologie genauer beschrieben werden. 2.5.4 Agentenbasierter Modelltransport Die Kooperation zwischen Fachplanern basiert in großem Umfang auf dem Austausch von Planungsinformationen. Ein verteiltes Planungssystem muss nicht nur die Bereitstellung von Fachinformationen im Netzwerk, sondern auch den fachgerechten Transport leisten. Auch hier bieten Agenten Vorteile gegenüber anderen verteilten Middleware-Systemen: Beispielsweise basieren CORBA (OMG 1999) oder Java-RMI (Sun 2003) auf dem Prinzip der entfernten Methodenaufrufe. Dabei wird der Ort der Objekte nie geändert. Die Informationsbeschaffung erfolgt durch den Aufruf der Methoden so genannter Stellvertreterobjekte (proxy). Zur wiederholten Informationsbeschaffung muss bei jedem Datenzugriff wiederum auf die Methode des entfernten Objektes zugegriffen werden. In der Folge entstehen ein sehr hoher Kommunikationsaufwand und die Notwendigkeit, dass jede Komponente des verteilten Systems permanent erreichbar sein muss. Des Weiteren kann eine Unterscheidung zwischen wichtigen und unwichtigen Informationen erst nach der Datenübertragung durch die anfragende Komponente getroffen werden. Damit werden auch nicht benötigte Informationen zumindest einmal über das Netzwerk übertragen. Durch den Einsatz mobiler Agenten kann der Informationsaustausch fachgerecht organisiert und durchgeführt werden (Rüppel et al. 2002b). Mobile Agenten sammeln Informationen bei den Kooperationspartnern und transportieren eine Kopie der Informationen zu ihrem Auftraggeber. Ein Informations-Transport-Agent verfolgt dabei das Ziel, möglichst vollständige Informationen für seinen Auftraggeber zu beschaffen und sich dabei selbständig mögliche Informationsquellen zu

Agentenbasierter Modellverbund für die kooperative Gebäudeplanung

347

erschließen. Informations-Transport-Agenten müssen sowohl mit ihrem Auftraggeber als auch mit den entsprechenden Wrapper-Agenten kommunizieren können. Die Kommunikation erfolgt durch Nutzung der zuvor beschriebenen Interaktionsprotokolle. Der eigentliche Modelltransport erfolgt im Sinne der Agentenmigration. Nach erfolgreicher Informationsübermittlung zwischen dem Wrapper- und dem Informations-Transport-Agenten enthält der Informations-Transport-Agent in seinem Informationsspeicher die gewünschten Modelle. Der Agent beendet seine Aktionen auf der aktuellen Plattform, um zurück zu seinem Auftraggeber zu migrieren. Hierzu werden die ermittelten Modelle und der eigentliche Agent serialisiert und gepackt. Zur Gewährleistung der Sicherheit wird ein Hash-Wert des Paketes erzeugt. Hat sich dieser Hash-Wert nach der Migration verändert, so kann festgestellt werden, dass Manipulationen während der Migration an dem Paket vorgenommen wurden (Meißner et al. 2004). Das Paket aus Modellinformationen, Agentenlogik und Zustandsinformationen des Agenten wird nun zu der definierten Zielplattform übertragen und dort in umgekehrter Reihenfolge wieder entpackt und der Agent gestartet. Nach dem Neustart des Agenten kann dieser seine ausgepackten Informationen an seinen Auftraggeber übermitteln. 2.5.5 Regelbasierte Abbildung von Brandschutzanforderungen Es hat sich in der Praxis gezeigt, dass zahlreiche brandschutzbezogene Fehler in der Gebäudeplanung dadurch entstehen, dass den entsprechenden Fachplanern nicht alle erforderlichen Informationen vorliegen bzw. die Informationen falsch interpretiert werden. Ein wirkungsvolles Instrument ist hier die Überprüfung einer Planungsleistung auf Basis der Fakten der zuvor eingeführten Modelle. Da nicht davon ausgegangen werden kann, dass ein Fachplaner permanent über das aktuelle und vollständige Planungswissen verfügt, müssen ihm Werkzeuge zur Überprüfung seiner Planungen zur Verfügung gestellt werden. Die Integration solcher Werkzeuge in den Bauplanungsprozess kann grundsätzlich auf zwei Arten erfolgen. Zum einen kann die Logik zur Überprüfung der Anforderungen direkt in die Fachanwendungen integriert werden, da die meisten Fachanwendungen programmierbare Schnittstellen besitzen, die eine fachliche Erweiterung erlauben. Zum anderen kann die Überprüfung in einer externen Komponente durch die Nutzung eines regelbasierten Schlussfolgerungssystems erfolgen. Bei der direkten Integration in die Fachanwendung müssen alle Anwendungen entsprechend erweitert werden. Hierbei wird die Verarbeitungslogik fest in die vorhandene Anwendung integriert. Dies macht eine permanente Anpassung der Anwendungen an sich ändernde Verordnungen in neuen Versionen der Anwendung notwendig. Im Rahmen dieses Projekts wurde der Ansatz der Nutzung eines regelbasierten Schlussfolgerungssystems verfolgt (Rüppel et al. 2003b). Hiermit kann die Verarbeitungslogik unabhängig von der Fachanwendung auf Basis der zuvor vorgestell-

348

Uwe Rüppel, Michael Lange, Mirko Theiß

ten Teilproduktmodelle modelliert werden. Durch diesen Ansatz ist es möglich, die Regelbasis zentral verschiedenen Projekten zur Verfügung zu stellen. Es ist des Weiteren denkbar, dass diese Bereitstellung zentral als Service angeboten wird, wie dies heute schon bei dem Vertrieb von gedruckten Normen praktiziert wird. Eine Regel im Sinne eines Schlussfolgerungssystems wird als eine Schablone (template) beschrieben. Sie besteht aus einer linken und einer rechten Seite, die durch den Operator „=>“ getrennt sind. Die linke Seite definiert eine Menge von Parametern (slots) und eine oder mehrere Bedingungen (constraints) die auf die Parameter angewendet werden. Die Parameter werden zur Ausführung der Regel mit Fakten gefüllt. Sind alle Bedingungen erfüllt, so werden die Aktionen der rechten Seite ausgeführt. Durch Verknüpfung der Regeln untereinander können komplexe Überprüfungen modelliert werden. Zur Verarbeitung der Regeln müssen diese gemeinsam mit den zur Definition verwendeten Modellen zur Verfügung gestellt werden. Nur durch die Einheit von Regeln und verwendetem Modell kann eine korrekte Verarbeitung in einem Schlussfolgerungssystem garantiert werden. 2.5.6 Agentenbasierte Brandschutzplanung Eine agentenbasierte Informationsverarbeitung ist immer dann sinnvoll, wenn fachlich bedingt ein hoher Grad an autonomer Bearbeitung von Problemstellungen möglich ist. Im beschriebenen agentenbasierten Modellverbund wurde dies am Beispiel der Überprüfung der Planungen des baulichen Brandschutzes umgesetzt. Ein spezialisierter Brandschutz-Agent unterstützt den Fachplaner bei der Überprüfung seiner Arbeit hinsichtlich der Konformität seiner Planungen zu den geltenden Brandschutzanforderungen. Der Brandschutz-Agent beschafft sich die notwendigen Modellinformationen nicht selbst, sondern nutzt hierzu den Informations-Transport-Agenten. Es ist ihm hierdurch möglich, parallel an verschiedenen Orten Informationen zu beschaffen. Zur Verarbeitung der Brandschutzinformationen wurde der Brandschutz-Agent um das Schlussfolgerungssystem Jess (Friedmann-Hill 2003) erweitert. Die ermittelten Modellinformationen werden von der Kommunikationseinheit direkt dem Regel- und Modell-Faktenspeicher des Schlussfolgerungssystems übergeben und von diesem verarbeitet. Dem Kontrollsystem werden alle auftretenden Fehler in der Planung übergeben. Alle in den Regeldatenbanken formulierten Regeln werden „negativ“ formuliert, das bedeutet, dass ihre rechte Seite nur ausgeführt wird, wenn eine Anforderung nicht erfüllt ist. Das Schlussfolgerungssystem Jess erlaubt es neben der rein textbasierten Beschreibung der rechten Regelseite auch neue Java-Objekte als Resultat der Regelverarbeitung zu erzeugen. Im Falle eines aufgetretenen Fehlers wird durch die Inferenzmaschine ein Fehlerobjekt erzeugt, dass neben dem betroffenen Bauteil auch eine Erläuterung des aufgetretenen Fehlers beinhaltet. Hieraus kann der Planer nachvollziehen, welche Teile seiner Planungen die Anforderungen des bauli-

Agentenbasierter Modellverbund für die kooperative Gebäudeplanung

349

chen Brandschutzes nicht erfüllen und welche Maßnahmen er zur Erfüllung der Anforderungen durchführen muss. Jedem Fachplaner ist es durch die Nutzung des Brandschutz-Agenten möglich, auf der Grundlage der geltenden Verordnungen und Richtlinien seine Planungen hinsichtlich des baulichen Brandschutzes effizient und qualitätsvoll zu überprüfen und evtl. zu korrigieren (Rüppel et al. 2006). Hierdurch können Fehler in den frühen Gebäudeplanungsphasen vermieden werden, deren Beseitigung zu einem späteren Zeitpunkt einen erheblichen Kostenaufwand bedeuten würde.

2.6 Umsetzung und Anwendungsbeispiel 2.6.1 Einleitung Im Folgenden soll die Umsetzung des Gesamtsystems anhand eines durchgängigen Beispiels demonstriert werden. Das Brandschutzkonzept zum Gebäude ist in (Bock u. Klement 2002) veröffentlicht und diskutiert worden. Das Gebäude wurde in seiner ursprünglichen Planung als Wohn- und Geschäftshaus konzipiert. Der Keller, das Erdgeschoss und das erste Obergeschoss sind zur Nutzung als Verkaufsfläche eines Einkaufsmarktes und verschiedener kleinerer Geschäfte geplant. Das zweite bis fünfte Obergeschoss ist jeweils etwa zur Hälfte als Wohnraum und Bürofläche vorgesehen. Um die Übersichtlichkeit zur wahren wird an dieser Stelle ausschließlich das vierte Stockwerk des Gebäudes behandelt. Das Stockwerk ist in drei Bereiche aufgeteilt. Der erste Bereich beinhaltet vier kleine Wohnungen, die Bereiche zwei und drei jeweils Büros. Die Wohnungen können durch ein Treppenhaus und zwei Aufzüge betreten werden. Für die Büros stehen zwei weitere Treppenhäuser zur Verfügung. Zusätzlich wurde für die Wohnungen und die mittleren Büros ein Fluchttreppenhaus geplant, dass von diesen als zweiter Rettungsweg über einen Balkon erreicht werden kann. Aus der Nutzung heraus werden drei Brandabschnitte gebildet. Den ersten Brandabschnitt bildet der Wohnbereich. Der Bürobereich wurde in Achse O in zwei Brandabschnitte unterteilt (s. Abb. 2.10). Dementsprechend müssen die Wände in den Achsen H und O als Brandwände ausgebildet werden. Das Rettungswegekonzept sieht eine Räumung des Gebäudes im Gefahrenfall über die drei Treppenhäuser vor (Abb. 2.10: Achsen H-I, O-P und R-S). Die notwendigen Flure münden in diese Treppenhäuser und sind durch Rauchschutztüren anzuschließen. Der zweite Rettungsweg wird durch Anleiterung der Feuerwehr bzw. bei zum Innenhof gerichteten Räumen durch den Balkon und ein Fluchttreppenhaus gewährleistet. Alle Wände zwischen Fluren und Büros sind als F30 Wände auszubilden und entsprechende Türen dort einzubauen. Zur Verhinderung des Feuerüberschlages von einem Brandabschnitt in einen benachbarten sind die Fenster in den Achsen G-H und N-O mit einer feststehenden G90 Verglasung auszuführen.

350

Uwe Rüppel, Michael Lange, Mirko Theiß

Diese Beschreibung gibt nur einen Ausschnitt aus dem kompletten Brandschutzkonzept zu dem Gebäude wieder. Die hier genannten Brandschutzelemente und -anforderungen sind für die Planung der konstruktiven Elemente des Gebäudes notwendig, die im Rahmen dieser Arbeit verifiziert werden. 6 5 RS

F90

T30

T30

4

F90

RS

3

G90 T90

2

BW

BW

F90

F90

F90

T30 RS T30

T30

1 A

B

C

D

E

F

G

T30

RS

T90 G90

G90

H

I

J

K

L

M

N

O

P

Q

R

S

Abb. 2.10. Brandschutzplan für das vierte Stockwerk

Das folgende Planungsszenario soll die Funktionsweise des Gesamtsystems verdeutlichen. Die Wände in den Achsen B, D und F wurden durch einen Planer nur als F30 geplant (Abb. 2.11). Aufgrund der Gebäudehöhe werden aber feuerbeständige (=F90) Wohnungstrennwände gefordert. Diese Fehlplanung würde im Falle der Ausführung erhebliche Kosten verursachen, da die Wände nachträglich mit feuerbeständigem Material beplankt werden müssten.

F30

F30

F30

3 2 1 A

B

C

D

E

F

G

Abb. 2.11. Fehlerhaft geplante Wohnungstrennwände; die Mindestanforderung an eine Wohnungstrennwand ist mit F90 im Brandschutzkonzept angegeben

Agentenbasierter Modellverbund für die kooperative Gebäudeplanung

351

Zur Überprüfung seiner Planungen beauftragt der Planer den BrandschutzAgenten, seine aktuelle Planung hinsichtlich des baulichen Brandschutzes zu verifizieren. Hierzu benötigt der Brandschutz-Agent Informationen aus den verteilten Modellen. Im Folgenden wird die Erstellung der zur verteilten Verifizierung notwendigen Fachmodelle am Beispiel des Brandschutzmodells dargestellt. Die Modellierung des baulichen Brandschutzes geschieht auf der Basis des vorhandenen Gebäudemodells. Dieses wurde zuvor durch den Architekten erstellt und beinhaltet alle Strukturinformationen, wie Stockwerke, Nutzungszonen, Räume und Bauteile des Gebäudes. Das Gebäudemodell wurde dem Brandschutzplaner durch einen Informations-Transport-Agenten zur Verfügung gestellt. Das bedeutet, dass der Brandschutzplaner eine Kopie aller für seine Planung relevanten Gebäudeinformationen erhalten hat. Durch die dreidimensionale Darstellung kann sich der Brandschutzplaner einen realitätsnahen Eindruck von den Verhältnissen des Gebäudes verschaffen. Zur Definition der Brandschutzanforderungen an die Trennwände zwischen den Wohnungen ruft der Brandschutzplaner im „Brandschutzmodellierer“ die entsprechende Funktion auf. Er wird aufgefordert im eingelesenen Gebäudemodell die entsprechende Wand auszuwählen und kann verschiedene brandschutzrelevante Attribute wie die Feuerwiderstandsklasse festlegen. Nach Bestätigung der Eingaben durch den Brandschutzplaner instanziert der „Brandschutzmodellierer“ eine neue Brandwand. Diese Instanz enthält alle gesetzten Attribute und verknüpft außerdem die Brandwand mit der ausgewählten Wand im Gebäudemodell. Hierdurch können jederzeit Attribute wie die Dicke der Wand aus dem Gebäudemodell ermittelt werden. Er ist also eine Verknüpfung zwischen zwei Teilproduktmodellen vorgenommen worden. In entsprechender Art und Weise werden auch die weiteren Elemente des Brandschutzmodells erzeugt. Nach Beendigung seiner Planungstätigkeiten und der Genehmigung des Brandschutzkonzeptes veröffentlicht der Brandschutzplaner sein Modell in einer Modeldatenbank. Das Modell steht nun allen beteiligten Fachplanern im Modellverbund durch die Anbindung der Datenbank an das Internet permanent zur Verfügung. Die Datenbank ist durch einen Datenbank-Wrapper-Agenten mit dem Modellverbund verbunden, so dass kontrolliert Teile des Modells kooperierenden Fachplanern zur Verfügung gestellt werden können und eine Informationsanfrage möglich ist. Die Speicherung der Planungsinformationen ist unabhängig von dem zur Erstellung des Modells benutzten Werkzeug. Damit können diese Planungsinformationen durch die im Folgenden vorgestellten Agenten genutzt werden, ohne dass Methoden des ursprünglichen CAD-Systems aufgerufen werden müssen. 2.6.2 Definition und Bereitstellung von brandschutzrelevanten Regeln Zusätzlich zu den zuvor definierten Fakten ist es notwendig, bei der Verifizierung der Brandschutzanforderungen auch die gültigen Regeln der Gesetze und Verordnungen der einzelnen Bundesländer abzubilden und zu verarbeiten. Hierzu wurde auf Basis des Wissensmodellierungswerkzeuges Protégé (Protégé 2006) eine

352

Uwe Rüppel, Michael Lange, Mirko Theiß

Komponente zur fachgerechten Definition von Brandschutzregeln in der Regelsprache CLIPS (Riley 2002) entwickelt. Mit Hilfe dieses Werkzeuges lassen sich Regeln unter Nutzung von Objektschablonen erzeugen (Rüppel et al. 2003b). Die Fakten des Gebäude- und Brandschutzmodells werden in diese Schablonen eingesetzt. In Abb. 2.12 ist der Regelmodellierer dargestellt. Mit ihm lassen sich die Regeln auch gemäß ihrer Gültigkeit für ein Bundesland, einer Gebäudeklasse und eines Brandschutzelements strukturieren.

Abb. 2.12. Der Regelmodellierer zur Verwaltung und Strukturierung von Brandschutzregeln

Neben der Verwaltung der Brandschutzregeln können mithilfe des Werkzeuges auch neue Regeln erzeugt bzw. vorhandene Regeln bearbeitet werden. Die korrekte Funktionsweise der Regel kann durch das Einsetzen von Testfakten erfolgen. Hierdurch erhält der Bearbeiter eine Information, ob seine Regel syntaktisch korrekt und ausführbar ist. Es erfolgt allerdings keine fachliche Überprüfung des Regelinhaltes. Alle Regeln stehen dem Modellverbund auf einem Regelserver zur Verfügung, der durch einen Wrapper-Agenten an den Modellverbund angeschlossen ist (Meißner et al. 2002). 2.6.3 Überprüfung der Anforderungen des baulichen Brandschutzes Die Planung des Gebäudes wird nach der Genehmigung durch die Bauaufsichtsbehörden durch eine Vielzahl von Fachplanern detailliert. Die meisten dieser Detailplanungen müssen auch die Anforderungen des baulichen Brandschutzes zur Sicherstellung der Schutzmaßnahmen berücksichtigen. Die modellbasierte Brandschutzplanung ermöglicht es, jede Detailplanung hinsichtlich der Anforderungen des baulichen Brandschutzes einzeln zu überprüfen. Um den Planer hierbei fachgerecht zu unterstützen, wurde der Brandschutz-Agent entwickelt (vgl. Kap. 2.5.6).

Agentenbasierter Modellverbund für die kooperative Gebäudeplanung

353

Ermittlung der Gebäudefakten zur Überprüfung der Anforderungen des baulichen Brandschutzes In dem folgenden Beispiel wird die eingangs beschriebene Trennwand zwischen zwei Wohnungen hinsichtlich ihrer Feuerwiderstandsklasse überprüft. Hierzu aktiviert der Planer den Brandschutz-Agenten. Dem Agenten wird die durch den Planer bearbeitete Wand als neues Element übergeben und die Überprüfung gestartet. Der Brandschutz-Agent analysiert die übergebenen Modelldaten und fordert einen Informations-Transport-Agenten auf, zu der Wand das entsprechende Brandschutzelement aus dem Modell des Brandschutzplaners zu beschaffen. Der Informations-Transport-Agent migriert zu der Agentenplattform des Brandschutzplaners und kontaktiert dort den stationären Datenbank-Wrapper-Agenten. Nach der Authentifizierung des Informations-Transport-Agenten wird die Anfrage dem Datenbank-Wrapper-Agenten übergeben. Diese Anfrage enthält eine eindeutige Identifikationsnummer der Wand. Auf Basis dieser Information kann der Datenbank-Wrapper-Agent aus seinem Brandschutzmodell die entsprechende Brandwand ermitteln. Diese Brandwand definiert als brandschutztechnische Anforderung an die Trennwand zwischen den Wohnungen die Feuerwiderstandsklasse F90. Die Informationen werden dem Informations-Transport-Agenten zur Verfügung gestellt, der sie zurück zu seinem Auftraggeber (in diesem Fall der Brandschutz-Agent) transportiert. Ermittlung der Brandschutzregeln zur Überprüfung des baulichen Brandschutzes Auf ähnliche Art und Weise ermittelt der Brandschutz-Agent die zur Überprüfung der Anforderungen notwendigen Regeln aus den Regeldatenbanken. Durch eine Anfrage an den Wrapper-Agenten des Gebäudemodells werden der Gebäudetyp und der Standort des Gebäudes ermittelt. Der Brandschutz-Agent kann nun einen Informations-Transport-Agenten mit der Beschaffung aller Regeln des baulichen Brandschutzes zu folgenden Aspekten beauftragen:

x Bundesland: Hessen x Gebäudetyp: Geschäftshaus x Brandschutzelement: Trennwand Diese Aspekte dienen im Folgenden zur Ermittlung der notwendigen Brandschutzregeln. Der Wrapper-Agent der Regeldatenbank kann aus den Informationen ‚Hessen’ und ‚Geschäftshaus’ ableiten, dass Regeln aus der Hessischen Bauordnung und der Sonderbaurichtlinie für Geschäftshäuser benötigt werden. Aus diesen Regelwerken ermittelt er nun alle Regeln, die für eine Trennwand definiert wurden und übergibt diese dem anfragenden Informations-Transport-Agenten. Der Brandschutz-Agent hat durch die zuvor beschriebenen Kommunikationsschritte selbständig alle notwendigen Fakten und Regeln ermittelt. Er beginnt daher mit der Überprüfung der Planung.

354

Uwe Rüppel, Michael Lange, Mirko Theiß

Durch Einsetzen der vorhandenen Fakten

x vorhandene Wand ist Trennwand, x aktuelle Feuerwiderstandsklasse ist F30 und x geforderte Feuerwiderstandsklasse ist F90 in die Regel, stellt der Schlussfolgerungsmechanismus des Brandschutz-Agenten fest, dass die aktuelle Feuerwiderstandsklasse der Trennwand zu niedrig ist. Der Planer erhält eine Fehlermeldung und einen Hinweis auf die korrekten Anforderungen. Dieses Ergebnis wird dem Planer in dem Verarbeitungsfenster des Brandschutz-Agenten mitgeteilt. Der Planer kann nun seine fehlerhafte Planung korrigieren und mit der Überprüfung weiterer Planungsergebnisse fortfahren. Es ist einem Fachplaner also möglich, unter Nutzung des Brandschutz-Agenten seine Planungsleistungen ohne detaillierte Kenntnis der Brandschutzverordnungen hinsichtlich Fehler in der Planung zu überprüfen. Hierdurch kann das Auftreten von Planungsfehlern durch mangelhafte Informationsweitergabe oder auch durch mangelnde Fachkenntnisse im Bereich des Brandschutzes erheblich reduziert werden.

2.7 Zusammenfassung Im Rahmen dieses Projekts wurde ein agentenbasierter Modellverbund für die kooperative Gebäudeplanung entwickelt. Hierbei werden die örtlich verteilten Teilproduktmodelle der verschiedenen Planungsdomänen unter Nutzung von Softwareagenten zu dem Modellverbund verknüpft. Der Fachplaner erhält damit die Möglichkeit, seine Planungen modellbasiert durchzuführen und zusätzlich auf Teilproduktmodelle anderer Fachdomänen zuzugreifen. Um die verteilten Fachmodelle auf Konformität mit den Anforderungen aus den Bauordnungen und Richtlinien zu überprüfen, ist es notwendig, diese ebenfalls in den Modellverbund zu integrieren. Die Aufbereitung und Strukturierung der Regeln erfolgt in enger Verknüpfung mit den definierten Teilmodellen. Unter Nutzung eines Werkzeuges zur Abbildung von formalem Wissen wurde eine Regeldefinitions- und Strukturierungskomponente entwickelt. Zur Überprüfung der Brandschutzanforderungen wurde ein Brandschutz-Agent zur Verfügung gestellt, der die Fakten der Teilmodelle gemeinsam mit den Regeln des baulichen Brandschutzes unter Nutzung eines regelbasierten Schlussfolgerungssystems verarbeitet. Die Funktionsweise des Modellverbundes wurde beispielhaft für die Planungen des baulichen Brandschutzes umgesetzt. Jeder Fachplaner erhält damit die Möglichkeit, seine Planung hinsichtlich der Konformität zu den definierten Brandschutzanforderungen zu verifizieren. Dies ist nur durch die Kopplung der verschiedenen Teilproduktmodelle möglich. Planungsfehler, die bisher auf unvollständigen Informationsaustausch zurückzuführen sind, werden durch diesen ganzheitlichen Ansatz aufgedeckt und damit frühzeitig ausgeschlossen. Die Interaktion in komplexen Systemen wie den Kooperationsverbünden in der Bauplanung kann durch Problemdekomposition und Umsetzung mit Multiagen-

Agentenbasierter Modellverbund für die kooperative Gebäudeplanung

355

tensystemen adäquat abgebildet werden. Multiagentensysteme haben sich als eine leistungsfähige Plattform erwiesen. Hierzu ist es aber erforderlich, dass es sich um Modellinformationen handelt, die zwischen den Partnern ausgetauscht werden. Für die Baupraxis bedeutet dies, dass ein Innovationssprung mit Softwareagenten nur erreicht werden kann, wenn die Planungen durchgängig modellbasiert erfolgen. Da dies aber gegenwärtig hauptsächlich dokumentenbasiert erfolgt, ist es zur Erhöhung der Praxisrelevanz der erreichten Ergebnisse und Erkenntnisse erforderlich, diese für einen Modell- und Dokumentenverbund weiterzuentwickeln.

Literatur Bellifemine F (2006) JADE – Java Agent Development Framework. TiLab, Turin, Italia (http://jade.cselt.it) Bilek J, Hartmann D (2003) Development of an Agent-based Workbench supporting Collaborative Structural Design. In: The 20th CIB W78 Conference on Information Technology in Construction, New Zealand Bock H, Klement E (2002) Brandschutz-Praxis für Architekten und Ingenieure. Bauwerk Verlag Cremers AB, Rüppel U, Meißner UF, Alda S, Theiß M (2003) Wahrnehmung und Verarbeitung von Ereignissen bei der verteilten Planung im baulichen Brandschutz. In: Gürlebeck K (Hrsg), Hempel L (Hrsg) Könke C (Hrsg) digital Proceedings, 16. Internationales Kolloquium über Anwendungen der Informatik und Mathematik in Architektur und Bauwesen (ikm 2003; Tagungs-CD-ROM), ISSN 1611-4086, Weimar FIPA (2001) FIPA Agent Software Integration Specification. Foundation for Intelligent Physical Agents (http://www.fipa.org/specs/fipa00079/) Friedmann-Hill E (2003) Jess in Action – Java Rule-based Systems. Manning Publications, Greenwich Hartmann D, Meißner UF, Rüppel U, Bilek J, Theiß M (2004) Integration of Product Model Databases into Multi-Agent Systems. In: Proceedings of the Xth International Conference on Computing in Civil and Building Engineering (ICCCBE-X) IAI (International Alliance for Interoperability) (2002) ifcXML-Schema Definition – Version 1.02 (http://www.iai-international.org) Meißner UF, Rüppel U (2003) Vernetzt-kooperative Planung mit Computern – Grundlagen und Methoden der Bauinformatik. In: Gürlebeck K (Hrsg), Hempel L (Hrsg), Könke C (Hrsg) digital Proceedings, 16. Internationales Kolloquium über Anwendungen der Informatik und Mathematik in Architektur und Bauwesen (ikm 2003; Tagungs-CDROM), ISSN 1611-4086, Weimar Meißner UF, Rüppel U, Theiß M (2002) Verteilte Brandschutzmodellierung auf der Basis von Software-Agenten. In: Bauen mit Computern – Kooperation in IT-Netzwerken, Fortschritt-Bericht VDI, Bonn, S 557–569 Meißner UF, Rüppel U, Greb S, Theiß M (2003) Network-based Cooperation Processes for Fire Protection Planning. In: Amor R (ed) Proceedings of the CIB W78's 20th International Conference of Information Technology For Construction, University of Auckland, New Zealand, pp 231–238 Meißner UF, Rüppel U, Theiß M (2004) Network-Based Fire Engineering Supported by Agents. In: Proceedings of the Xth International Conference on Computing in Civil and Building Engineering (ICCCBE-X)

356

Uwe Rüppel, Michael Lange, Mirko Theiß

Meißner UF, Rüppel U, Theiß M, Lange M (2005) An Agent-based Model-Compound for Fire Protection Engineering. In: Proceedings of the International Conference on Computing in Civil Engineering 2005 (ICCC2005), ISBN 0-7844-0794-0, Cancun, Mexico Odell J, Parunak HVD, Bauer B (2000) Extending UML for Agents. In: Proc. of the AgentOriented Information Systems Workshop at the 17th National conference on Artificial Intelligence OMG (1999) Object Management Group: Common Object Request Broker Architecture (CORBA/IIOP). Specification of the Middleware Architecture (www.omg.org) Protégé (2006) Ontology Editor and Knowledge-base Framework. Stanford Medical Informatics (http://protege.stanford.edu) Riley G (2002) C Language Integrated Production System (CLIPS) – A Tool for building Expert Systems. (http://www.ghg.net/clips/CLIPS.html) Rüppel U (2002) Collaborative Fire Protection Engineering Based on Software Agents. In: Proceedings of the 19th International Symposium on Automation and Robotics in Construction, NIST SP 989, Gaithersburg, USA, pp 3–8 Rüppel U, Lange M (2006) Network-based Agent- and Process Modelling-Methods for Cooperation Support in Civil Engineering Applications on Example of Fire Protection Engineering. In: Electronic Journal of Information Technology in Construction (www.itcon.org) Rüppel U, Meißner UF, Theiß M (2002a) An Agent-based Platform for Collaborative Building Engineering. In: Proceedings of the 9th International Conference on Computing in Civil & Building Engineering, Taipei, Taiwan Rüppel U, Meißner UF, Theiß M (2002b) Fire Protection Concepts With Mobile Agents. In: Proceedings of the 9th International Workshop of the European Group for Intelligent Computing in Engineering (EG-ICE), Darmstadt Rüppel U, Greb S, Theiß M (2003a) Managing Distributed Planning Processes in Fire Protection Engineering based on Agent Technologies and Petri-Nets. In: 10th ISPE International Conference on Concurrent Engineering: Research and Applications, vol 2, Madeira Island, Portugal, pp 651–656 Rüppel U, Meißner UF, Theiß M (2003b) Vernetzt-kooperative Planung im vorbeugenden baulichen Brandschutz unter Nutzung von Software-Agenten. In: thema Forschung 1/2003, S 52–57 Rüppel U, Theiß M, Lange M (2005) Agent-enabled Model Integration in a Knowledgebased Planning Environment. Proceedings of the 22nd Conference on Information Technology in Civil Engineering (cibW78), ISBN 3-86005-478-3; CIB Publication No. 304, Dresden, pp 471–476 Rüppel U, Meißner UF, Lange M (2006) An Agent-Based Cooperation Platform for Fire Protection Planning. In: Proceedings of the Joint International Conference on Computing and Decision Making in Civil and Building Engineering, Montreal, Kanada Sneed HM (2002) Encapsulation of Legacy Software – A Technique For Reusing Legacy Software Components. In: Journal of Software Engineering 2000 Sun (2003) Java Remote Method Invocation Specification (Java RMI) (http://java.sun.com/products/jdk/rmi/index.jsp) Theiß M (2005) Agentenbasierter Modellverbund am Beispiel des baulichen Brandschutzes in der Gebäudeplanung. Berichte des Instituts für Numerische Methoden und Informatik im Bauwesen Nr. 03/2005, TU Darmstadt, Shaker Verlag, ISBN 3-8322-4359-3, Aachen

3 Kooperative Tragwerksplanung basierend auf Multiagentensystemen und adaptiven Assoziationsnetzen

Jochen Bilek, Dietrich Hartmann Ruhr-Universität Bochum, Lehrstuhl für Ingenieurinformatik im Bauwesen [email protected] | [email protected]

3.1 Vorbemerkungen Die Planung und Errichtung von größeren Bauwerken ist ein hochkomplexer Vorgang, der durch ständig wachsende Qualitätsanforderungen der Bauherren und einen damit verbundenen hohen Kosten- und Termindruck geprägt ist. Es gilt, die im Planungsprozess zur Verfügung stehenden, knappen Ressourcen möglichst effizient und effektiv einzusetzen. Man geht infolgedessen vor allem bei mittleren und größeren Planungsprojekten dazu über, Planungstätigkeiten – soweit dies möglich ist – parallel durchzuführen. Dies trifft in besonderer Weise auf die Tragwerksplanung zu, die einen wesentlichen Anteil an der Gesamtplanungsleistung hat und daher in besonderer Weise für die Gesamtkostenentwicklung bei der Bauwerkserstellung verantwortlich ist. Die Tragwerksplanung muss infolgedessen gründlich, qualitativ hochwertig und möglichst konfliktfrei durchgeführt werden. Das gestaltet sich insbesondere deshalb als schwierig, weil die im Rahmen der Tragwerksplanung durchzuführenden Planungsaktivitäten in Koordination und Kooperation mit allen beteiligten Planungspartnern (Architekten, Bauherren, Ingenieure etc.) aufeinander abgestimmt durchgeführt werden müssen. Hinzu kommt, dass jedes Bauwerk stets ein Unikat mit niedrigem Standardisierungsgrad ist, das in seiner Gestalt, Form und Tragstruktur nahezu beliebig entworfen werden kann. Infolgedessen besitzt die Tragwerksplanung anders als die maschinelle Fertigung einen hochgradig komplexen, polydisziplinären und dynamischen Charakter.

358

Jochen Bilek, Dietrich Hartmann

3.2 Einleitung und Zielsetzung Die bisher in der Tragwerksplanung eingesetzten Modelle, Computer-Technologien und Softwarearchitekturen zur Unterstützung kooperativer Planungsarbeit sind i.d.R. algorithmisch geprägte, einfach strukturierte, monolithische Programmsysteme (Stichwort Insellösungen). Die komplexe, interaktive und vernetzte Planungsrealität lässt sich mit solchen Programmen und Modellansätzen nur schwer abbilden und bewältigen. Eine Verbesserung des kooperativen Tragwerkplanungsprozesses ist trotz der i.d.R. leistungsstarken hardwaretechnischen Ausstattung der Fachplanungsbüros nicht feststellbar. Infolgedessen muss man zu hochgradig verteilten und vernetzten Systemen übergehen, für die im Bereich der vernetzt-kooperativen Tragwerksplanung bisher kaum zufrieden stellende wissenschaftliche Grundlagen und Modelle erarbeitet worden sind. Insbesondere muss berücksichtigt werden, dass sich die Planung und anschließende Fertigung von Tragwerken als ein Netzwerk komplizierter, verteilt ablaufender Arbeitsabläufe (Arbeitsprozesse, Aktivitäten) darstellt, die von den einzelnen Aufgabenträgern – den Fachplanern und Ingenieuren – verantwortet und durchgeführt werden. Hier setzt nun das Forschungsprojekt an. Oberstes Ziel ist es, für die vernetztkooperative Tragwerksplanung neue methodische Grundlagen und Kooperationsmodelle auf hohem Abstraktionsniveau zu schaffen, die auf Basis einer holistischen Betrachtungsweise auf den kooperativen Planungsprozess die spezifischen Charakteristika der Arbeits- und Organisationsstrukturen in der Tragwerksplanung berücksichtigen und abbilden. Folgende Teilziele wurden hierzu verfolgt: 1. Die Zusammenführung bisheriger, geeigneter Forschungsansätze in Form einer Hybridisierung mit Zuschnitt auf die fachspezifischen Belange von Planungsprozessen im Konstruktiven Ingenieurbau, wobei vor allem auf eine sinnvolle Mischung der sog. Agententechnologie mit Technologien des Computer Supported Cooperative Work (kurz CSCW) und Petrinetzen gesetzt wurde. 2. Die Stärkung der anthropogenen Komponente bei der computergestützten kooperativen Arbeit, wobei sowohl die Gruppenarbeit als auch die Arbeit des Einzelnen innerhalb einer Gruppe unterstützt werden muss; vor allem muss dem heterogenen Beziehungsgeflecht der zeitlich befristeten Planungsgemeinschaft im Konstruktiven Ingenieurbau Rechnung getragen werden. 3. Aufbau eines formalen Beschreibungs- und Darstellungskalküls für Planungsprozesse des Konstruktiven Ingenieurbaus mit anschaulicher Notation und Symbolik. Entsprechend den drei zuvor dargelegten Zielsetzungen wurde eine neuartige, computergerechte und gebrauchstaugliche Arbeitsplattform in Form eines Multiagentensystems (MAS) für Planungsprozesse in der Tragwerksplanung geschaffen, mit der sich sowohl die kooperative als auch die individuelle Projektbearbeitung wesentlich verbessern und erleichtern lässt.

Kooperative Tragwerksplanung basierend auf Multiagentensystemen

359

3.3 Beitrag des Projektes zu den Gesamtzielen des SPP Das Forschungsprojekt trägt aufgrund seines hybriden Charakters implizit zu allen vier übergeordneten Gesamtzielen des SPP 1103 sowie zu allen Zielen der Arbeitsgruppe „Agentensysteme“ bei. Beitrag zum SPP-Gesamtziel „Neugestaltung der Planungsprozesse in einer verteilten Rechnerumgebung“: Wie zuvor bereits dargestellt, beinhaltet Teilziel 3 des Teilprojekts die Entwicklung neuer Ansätze zur verteilten Prozessmodellierung in der Tragwerksplanung. Im Rahmen des agentenbasierten Lösungsansatzes wurde hierzu ein auf die Tragwerksplanung zugeschnittenes agentenbasiertes Modell zur Prozessunterstützung entwickelt. Es übernimmt auf Basis höherer Petrinetze die Koordination und Steuerung der in der heterogenen Planungsumgebung zeitlich und örtlich verteilt durchgeführten Planungsaktivitäten. Beitrag zum SPP-Gesamtziel „Neukonzeption der Kommunikation hinsichtlich der Kooperationsinhalte und -formen“: Der favorisierte MultiagentensystemAnsatz hat zur Folge, dass auf die Agententechnologie zugeschnittene Formen der Kommunikation, Informationsübermittlung und -verarbeitung entwickelt werden mussten, die u. a. für die zielgerichtete Zustellung von Fachinformationen zur richtigen Zeit am richtigen Ort sorgen. Als tragfähig hat sich hierbei eine Kombination aus sprechaktbasierten Nachrichtenübermittlungsverfahren mit Interaktionsprotokollen und domänenspezifischen Fachontologien erwiesen. Beitrag zum SPP-Gesamtziel „Entwicklung neuer Methoden zur Verwaltung der im KIB einsetzbaren Fachsoftware/-modelle“: Zur Einbindung heterogener Ingenieur- und Fachsoftware in die agentenbasierte Arbeitsplattform wurde das Konzept des Software-Wrapping entsprechend weiterentwickelt. Hiermit wird planungsrelevante Fachsoftware wie Statik-, CAD- oder Datenbankprogramme über Rechnergrenzen hinweg allen berechtigten Planern jederzeit ortsungebunden verfügbar gemacht. Weiterhin wurde ein agentenbasiertes Produktmodell entwickelt, mit dem beliebige ISO 10303 basierte Produktmodelle in die Arbeitsplattform integriert und für die verteilte Produktmodellbearbeitung bereitgestellt werden können. Beitrag zum SPP-Gesamtziel „Entwicklung neuer Verfahren zur fachgerechten Verarbeitung der Normen und Regelwerke“: Der Aufbau von Wissensbasen zur dauerhaften Bereitstellung des in bestehenden technischen Regelwerken und Normen abgelegten Fachwissens speziell aus dem Bereich der Tragwerksplanung ist essentieller Bestandteil des Projekts. Hierzu wurde ein agentenbasiertes Modell zur Integration von Fachwissen entwickelt. Es ermöglicht im Sinne eines „steckerkompatiblen Computing“ die flexible und dynamische Integration von technischem Fachwissen in die agentenbasierte Arbeitsplattform.

3.4 Agentenbasierter Lösungsansatz Das agentenbasierte Lösungskonzept fußt darauf, grundlegende Teilbereiche der Tragwerksplanung und das Beziehungsgeflecht der sich zeitlich ändernden Pla-

360

Jochen Bilek, Dietrich Hartmann

nungsgemeinschaft möglichst realitätsnah auf ingenieurspezifische Softwareagenten abzubilden. Das agentenbasierte Lösungskonzept impliziert damit einen hierarchischen Drei-Ebenen-Ansatz, der das komplexe Zusammenwirken von Fachplanern, problemspezifisch zugeschnittenen Softwareagenten und eingesetzten, planungsspezifischen Ressourcen beschreibt (vgl. Abb. 3.1). Auf der obersten Ebene der Hierarchie, der Ebene der realen Welt, befinden sich die menschlichen Aufgabenträger. Die Ebene der realen Welt ist durch dynamische Beziehungsgeflechte, Gruppenstrukturen, Rollen, Pflichten, Aufgabenund Zuständigkeitsbereiche sowie kooperative Teamarbeit geprägt. Die Fachplaner auf der obersten Ebene werden durch das in diesem Projekt entwickelte Multiagentensystem ACOS (vgl. Kap. 3.6) in ihren Planungstätigkeiten zielgerichtet und effektiv unterstützt (Agentensystem-Ebene). Auf der Agentensystem-Ebene werden die wichtigsten, agentifizierbaren Teilbereiche der Tragwerksplanung, ihre Abhängigkeiten und Wechselwirkungen identifiziert, analysiert und anschließend computergerecht auf fachspezifische Softwareagenten abgebildet. Die agentengerechte Abbildung der identifizierten Teilbereiche erfolgt im Agentenmodell für die vernetzt-kooperative Tragwerksplanung (AMTP). Die modellierten Fachagenten wiederum greifen zur Erreichung ihrer individuellen Zielvorgaben auf die hierzu erforderlichen, planungsrelevanten Ressourcen zu (Ressourcen-Ebene). Planungsrelevante Ressourcen in diesem Sinne sind z.B. spezifische Ingenieur- oder Standardsoftware, Produktdaten- oder Prozessmodelle, technische Regelwerke etc.

Abb. 3.1. Agentenorientierte Planungsunterstützung und Drei-Ebenen-Ansatz

Kooperative Tragwerksplanung basierend auf Multiagentensystemen

361

3.5 Agentenmodell für die Tragwerksplanung Aus den Projektzielen und der anfangs postulierten holistischen Betrachtungsweise auf den kooperativen Planungsprozess folgte, dass alle wesentlichen Aspekte kooperativer Arbeit in der Tragwerksplanung in das Agentenmodell AMTP einzubetten waren. Neben der Kooperations-, Koordinations- und direkten Kommunikationsunterstützung zählt dazu vor allem die Sicherstellung des durchgängigen Datenflusses auf Basis verteilt bearbeiteter Produktdatenmodelle. Ein weiterer wichtiger Punkt ist die Modellierung, Kontrolle und Koordination der zugehörigen, oftmals parallel ausgeführten Planungaktivitäten. Zusätzlich müssen die Einbindung heterogener Ingenieur- und Standardsoftware sowie die Integration von computerisierbarem, ingenieurspezifischem Fachwissen, das z.B. in Regelwerken und technischen Normen abgelegt ist, im AMTP vorgesehen werden. Aus diesen fünf Kernbereichen der Tragwerksplanung wurden fünf miteinander verzahnte, agentenbasierte Teilmodelle abgeleitet, die zusammen das AMTP bilden. Diese waren für sich methodisch und konzeptionell leichter herzuleiten als ein monolithisches Gesamtmodell. Jedes Teilmodell klärt dabei, wie viele Agenten für welche Bereiche der Tragwerksplanung mit welchen Aufgaben und Fähigkeiten zu entwickeln sind. Die fünf agentenbasierten Teilmodelle lassen sich wie folgt zusammenfassen: 1. Das heterogene, dynamische Beziehungsgeflecht der zeitlich befristeten, realen Planungsgemeinschaft einschließlich der beteiligten Fachplaner wird durch das agentenbasierte Kooperationsmodell AMKoop abgebildet. 2. Die den einzelnen Planungsphasen zugehörigen (Teil-)Produktmodelle werden in das agentenbasiertes Produktmodell AMProd überführt. 3. Die in der Praxis auftretenden Planungsprozesse werden im agentenbasierten Modell zur Prozessunterstützung AMProz dargestellt. 4. Im agentenbasierten Modell zur Softwareintegration AMSoft wird die eingesetzte, heterogene Ingenieur- und Standardsoftware für alle beteiligten Fachplaner verfügbar gemacht und ist damit ortsungebunden einsetzbar. 5. Das agentenbasierte Modell zur Integration von Fachwissen AMWiss bindet das in Normen und technischen Regelwerken vorhandene Anwendungswissen in das Agentensystem ein, so dass dieses Wissen produktiv im Planungsprozess wieder verwendet werden kann. Informatisch gesehen, wird unter Berücksichtigung dieser fünf Teilmodelle die Dekomposition des Gesamtproblems – in der Tragwerksplanung ist dies die Gesamtplanungsaufgabe – wirklichkeitsgetreu auf einzelne, besser lösbare Teilprobleme betrieben, die dann von einzelnen Softwareagenten zu bearbeiten sind. Jedes Teilmodell führt dabei auf einen Satz an fachspezifisch zugeschnittenen Softwareagenten, die in Kooperation Teilproblemlösungen erarbeiten. Die schrittweise Synthese der erarbeiteten Teillösungen trägt entscheidend zur Gesamtlösung bei, die letztendlich in der Erstellung von Konstruktionsplänen und der damit verbundenen Errichtung des Tragwerks liegt. Die Grundzüge der einzelnen agentenbasierten Teilmodelle werden im Folgenden kurz dargestellt.

362

Jochen Bilek, Dietrich Hartmann

3.5.1 Das agentenbasierte Kooperationsmodell Aufgabe des agentenbasierten Kooperationsmodells AMKoop ist die Abbildung des im Planungsverlauf dynamisch wechselnden Organisations- und Beziehungsgeflechts. Hierzu war es zunächst erforderlich, die charakteristischen, organisatorischen Besonderheiten der Tragwerksplanung zu erfassen. Es hat sich herausgestellt, dass die kleinen und mittleren (Fach-)Planungsbüros die wichtigsten Organisationseinheiten in der Tragwerksplanung sind. Sie sind i.d.R. auf einige wenige Aufgaben im Planungsprozess spezialisiert und schließen sich daher oft mit anderen Planungsbüros zu zeitlich begrenzten Projekt- bzw. Arbeitsgemeinschaften zusammen, um so auch komplexe Planungsaufgaben bewältigen zu können. Nach Ende der gemeinsamen Projektbearbeitung zerfallen die temporär gebildeten, projektbezogenen Organisationen wieder und können im nächsten Planungsprojekt wieder ganz anders zusammengesetzt sein. Weiterhin hat sich gezeigt, dass die an einem Planungsprojekt beteiligten Personen, die Akteure, im Planungsverlauf wechselnde Aufgaben, Funktionen, Zuständigkeiten und Rechte innehaben. Sie besitzen, informatisch gesehen, eine oder mehrere projektbezogene Rollen. Wichtige Rollen in der Tragwerksplanung sind z.B. Projektleiter, Fachplaner (Statiker, Stahlbauer etc.), Konstrukteur/Techniker und Zeichner. Die Abbildung des soeben geschilderten menschlichen Beziehungs- und Organisationsgeflechts und der dynamischen Rollenverteilung erfolgt durch Kooperations-Agenten, die in zwei grundlegend verschiedene Agententypen unterteilt sind: 1. Projekt-Agent (PA): Ein Projekt-Agent repräsentiert genau ein zeitlich befristetes Planungsprojekt. Er übernimmt projektbezogene Koordinationsaufgaben, wie die flexible Verwaltung der häufig wechselhaften, dynamischen Projektrandbedingungen (Gruppen, Rollen, Personen, Zugriffsrechte etc.). 2. Persönlicher Kooperations-Agent (PKA): Ein PKA ist der Vertreter eines menschlichen Akteurs und unterstützt diesen bei Kommunikation, Kooperation und Koordination mit anderen Planern. Der PKA eines Fachplaners stellt für diesen somit die Schnittstelle zum Agentensystem dar. Aus dem ermittelten Rollenkonzept folgt, dass ein PKA mehrere Rollen besitzen und gleichzeitig mehreren projektbezogenen Organisationen angehören kann. 3.5.2 Das agentenbasierte Produktmodell Die Mitglieder einer Projektgemeinschaft kooperieren vor allem über das gemeinsame Planungsmaterial, dem Produktmodell, miteinander, welches sie im Planungsablauf gemeinsam aufbauen und teilweise parallel bearbeiten. Die Einbindung von Produktmodellen in das Agentenmodell erfolgt über das agentenbasierte Produktmodell AMProd. Hierin übernehmen Produktmodell-Agenten (PMA) die Bereitstellung des gemeinsamen Datenmaterials, die Kontrolle und Überwachung des Zugriffs auf einzelne Tragwerksobjekte, die Konsistenzsicherung und die persistente Speicherung des verwendeten Tragwerkmodells.

Kooperative Tragwerksplanung basierend auf Multiagentensystemen

363

Die Verteilung und der möglichst verlust- und redundanzfreie Austausch von Produktdaten durch den Produktmodell-Agenten erfordert – das hat die Forschungsarbeit eindeutig ergeben – die Verwendung einer Datenstruktur in digitaler, computerlesbarer Form: einem Produktmodell. Weil sich im Bauwesen bisher noch kein einheitliches Standardproduktdatenmodell etabliert hat, wurde zur Produktmodellintegration die aus dem Maschinen-/Flugzeugbau stammende, internationale Norm ISO10303 „Standard for the Exchange of Product Model Data“ herangezogen. Die ISO10303 ist eine allgemeingültige Regelung zur Definition, Beschreibung und Anwendung von technischen Produktmodellen, mit der auch in der Arbeitsgruppe „Verteilte Produktmodellierung“ bereits gute Erfahrungen gemacht worden sind. Durchgeführte Untersuchungen haben gezeigt, dass mehrere, ISO10303-basierte Produktmodellansätze für die Tragwerksplanung relevant sind. Dazu zählen die IFC (Industry Foundation Classes – allg. Bauproduktmodell), der CIS/2 Standard (CIMSteel Integration Standard – Stahlbaudomäne) und das AP225 (Application Protocol 225 – räumliche Geometriedarstellungen). Für die Verteilung der Produktmodelldaten im Multiagentensystem wurde ein hybrides, teilrepliziertes Datenhaltungskonzept entwickelt, das gegenüber der zentralen und vollreplizierten Datenhaltung (Borghoff u. Schlichter 1998) zahlreiche Vorteile bezüglich Robustheit, Effizienz und Entwicklungsaufwand aufweist. Prinzip hierbei ist, dass die beteiligten Kooperations-Agenten der Fachplaner entweder vollständige Replikate oder Teilreplikate des parallel bearbeiteten Produktmodells vorhalten. Der PMA hingegen besitzt und kontrolliert immer das komplette Original-Produktmodell einer Planung. Er kann folglich alle schreibenden Zugriffe synchronisieren und die bei den Fachplanern vorliegenden Teilmodelle in einem konsistenten Zustand halten. Dabei wird das aus der Datenbankwelt bekannte ACID-Prinzip (Atomicity, Consistency, Isolation, Durability) für Transaktionen berücksichtigt. Aus dem entwickelten Datenhaltungskonzept folgt direkt das Interaktionsmodell des PMA. Es sieht vor, dass die am Aufbau des Produktmodells beteiligten Fachplaner über ihre persönlichen Kooperations-Agenten in Abhängigkeit ihrer projektspezifischen Rollen Produktmodelltransaktionen (Erstellen, Löschen, Modifizieren von Tragwerksobjekten) veranlassen können. Die Zulässigkeit der Aktionen überprüft der PMA in Interaktion mit dem Projekt-Agenten, der das hierzu erforderliche Wissen besitzt. Zur persistenten Speicherung von ProduktmodellObjekten kann der PMA Datenbank-Wrapper-Agenten beauftragen.

364

Jochen Bilek, Dietrich Hartmann

Abb. 3.2. Interaktion des PMA mit anderen Agenten des AMTP in AUML

Abbildung 3.2 verdeutlicht das komplexe Zusammenspiel zwischen den verschiedenen Agenten anhand eines AUML-Interaktionsdiagramms. Dargestellt ist ein Szenario, in dem Fachplaner A eine Änderung des Tragwerkobjekts 1011 vornimmt und den Produktmodell-Agenten hierüber benachrichtigt. Dieser überprüft anschließend die Zulässigkeit der Aktion, sorgt für die Speicherung des Objekts und informiert schließlich weitere Agenten über die erfolgte Änderung. 3.5.3 Das agentenbasierte Modell zur Prozessunterstützung Die Modellierung, Ausführung, Kontrolle, Steuerung und Simulation der in der Praxis auftretenden, tragwerkspezifischen und häufig parallel ausgeführten Fachplanungsprozesse erfolgt im agentenbasierten Modell zur Prozessunterstützung AMProz. Eine Analyse der bei der Planung des Referenztragsystems durchgeführten Planungsaktivitäten hat ergeben, dass die beteiligten Fachplaner einzelne Arbeitsprozesse häufig parallel ausführen; zudem sind die durchgeführten Aktivitäten häufig direkt mit dem Produktmodell verknüpft. Die systematische Koordination und Steuerung der Planungsabläufe innerhalb des agentenbasierten Prozessmodells konnte daher nicht isoliert erfolgen: Vielmehr musste eine Kopplung mit dem agentenbasierten Produktmodell (dem Produktmodell-Agenten) sowie dem agentenbasierten Kooperationsmodell (den Agenten der beteiligten Fachplaner und dem Projekt-Agenten) vorgesehen werden. Ausgangspunkt für die Prozessmodellierung und agentengerechte Dekomposition der Prozessausführung ist der Workflow-Agent (WFA), der jeweils genau eine komplette Prozess-Instanz – einen Workflow – steuert. Hierzu besitzt er eine Workflow-Engine, die auf Basis höherer Petrinetze die koordinierte und zeitlich abgestimmte Verteilung von Planungsaktivitäten während der Projektphase durchführt. Eigene Untersuchungen und Ergebnisse der Arbeitsgruppe „Prozessmodellierung“ des SPP 1103 zeigen, dass die in der Tragwerksplanung häufig anzutreffenden, synchron oder asynchron ablaufenden, mit Ressourcen gekoppelten Planungsprozesse zielführend mit einer Kombination aus farbigen, hierarchischen und zeitbehafteten Petrinetzen, den HCT-PN (Hierachical, Colored, Timed Petri Nets) abgebildet und zu Kontrollzwecken simuliert werden können.

Kooperative Tragwerksplanung basierend auf Multiagentensystemen

365

Das Prinzip der agentenbasierten Prozesssteuerung zeigt Abb. 3.3. Während der Workflowausführung schaltet die Workflow-Engine das modellierte Petrinetz in Abhängigkeit der Planungszustände und der Planungsentscheidungen der Akteure und verfügt damit stets über eine aktuelle Aktivitätenliste. Für die Zuweisung von Aktivitäten wird das im AMKoop erarbeitete, dynamische Rollen- und Organisationskonzept übernommen: Alle Aktivitäten sind entweder rollen- oder benutzerbezogen. Fallen nach einem Schaltvorgang neu auszuführende Aktivitäten an, werden sie vom Workflow-Agenten an diejenigen Agenten weitergeleitet, die entweder die geforderte Rolle besitzen (Separation of Duties) oder aber den entsprechenden Fachplaner repräsentieren. Die für das Aktivität-Agent-Mapping notwendigen Informationen über Gruppenzugehörigkeiten bzw. Rollenverteilungen besitzt der Projekt-Agent. Automatisierbare Aktivitäten muss der WFA erkennen und an entsprechende Wrapper-Agenten delegieren, die dann die durchzuführende Aufgabe selbständig erledigen. Eine Sonderstellung nimmt hierbei der Produktmodell-Agent ein. Zur Kopplung von Prozess- und Produktmodell muss der eingesetzte Produktmodell-Agent in vielen Fällen den Workflow-Agenten während der Prozessausführung zeitnah über relevante Änderungen am Produktmodell informieren, damit dieser die beabsichtigte Aktivitätsabfolge sicherstellen kann.

Abb. 3.3. Prinzip der agentenorientierten Prozessunterstützung

3.5.4 Das agentenbasierte Modell zur Softwareintegration Die an einem Planungsprojekt beteiligten Planungsbüros sind üblicherweise mit äußerst heterogenen Hard- und Softwareumgebungen ausgestattet. Immer häufiger ist festzustellen, dass die Bauherren – gerade bei größeren Planungsprojekten – bestimmte Softwareprodukte und Austauschformate vorgeben. Für kleinere Planungsbüros rentiert sich die Anschaffung der oft speziellen Softwareprodukte meist nicht. Zudem können zusätzliche, nicht kalkulierte Folgekosten auftreten (Installation, Support, Wartung etc.). Für die Tragwerksplanung relevant sind vor allem Finite-Element-Programme, CAD-, Nachweis- und Datenbanksysteme.

366

Jochen Bilek, Dietrich Hartmann

Mit dem agentenbasierten Modell zur Softwareintegration AMSoft wird erreicht, dass ingenieurspezifische Fachapplikationen – unabhängig von ihrem physischen Installationsort – allen Planungsbeteiligten zur Verfügung gestellt werden können. Monolithisch aufgebaute Fachapplikationen, die sich nicht ohne weiteres verteilt benutzen lassen, können so trotzdem in den Agentenverbund integriert und nutzbar gemacht werden. Die Umsetzung des AMSoft basiert auf dem Prinzip des Software-Wrapping: Einzelne Softwareprodukte werden durch an die Software angepasste WrapperAgenten gekapselt und über softwarespezifische Interaktionsprotokolle und Ontologien für andere Agenten im System nutzbar gemacht (s. Abb. 3.4). WrapperAgenten wirken infolgedessen als Schnittstelle zwischen lokal installierter Software und dem Multiagentensystem ACOS. Das Software-Wrapping erlaubt damit auch die Automatisierung von softwarespezifischen Planungstätigkeiten. Technisch erfolgt die Einbindung der Softwareprogramme über ein an die jeweilige Software angepasstes Technologie-Mapping (z.B. Anbindung über SQL, Middleware-Technologien etc.). Untersuchungen haben gezeigt, dass nicht jede Ingenieursoftware „gewrappt“ werden kann, weil z.B. entsprechende Programmschnittstellen fehlen oder der Aufwand für das Wrapping unangemessen hoch ist. Das Interaktionsmodell der Wrapper-Agenten sieht vor, dass der Zugriff auf die angebotenen Software-Dienste nur berechtigten Agenten gestattet ist. Jeder Wrapper-Agent muss daher bei angeforderten Aktionen den Projekt-Agenten kontaktieren, um die erforderlichen Berechtigungsinformationen einzuholen.

Abb. 3.4. Konzept zur Softwareintegration mit Wrapper-Agenten

3.5.5 Das agentenbasierte Modell zur Integration von Fachwissen Aufgabe des agentenbasierten Modells zur Integration von Fachwissen AMWiss ist die Bereitstellung und Verarbeitung von fachspezifischem Ingenieurwissen, das nicht nur einmalig, sondern vielfach in verschiedenen Planungsprojekten und Anwendungskontexten benötigt und verwendet wird. Die einzelnen Fachplaner können mit Hilfe des AMWiss bei der Bearbeitung ihrer Planungsaufgaben auf einfache Art und Weise auf einen breiten, ingenieurtechnischen Erfahrungsschatz zurück-

Kooperative Tragwerksplanung basierend auf Multiagentensystemen

367

greifen und diesen im Planungsprozess nutzen. Für jedes klar eingegrenzte und computerisierbare Wissensgebiet wird ein wissensbasierter Fachdomänen-Agent vorgeschlagen. Er erarbeitet für konkrete Fragestellungen in seiner Fachdomäne eigenständig problemspezifische Lösungsvorschläge, die er dann den persönlichen Agenten der Anwender übermittelt. Für die hier betrachtete Tragwerksplanung waren vor allem die Aufgabenbereiche Nachweisführung (Planungsphase „Nachweis/Bemessung“), Entwurfsunterstützung (Planungsphase „Vorentwurf/Strukturanalyse“) und Konstruktionsunterstützung (Planungsphase „Konstruktive Durchbildung“) durch Fachagenten zu unterstützen. Abbildung 3.5 zeigt das Prinzip der Wissensbereitstellung durch FachdomänenAgenten. Grundlage jedes Fachdomänen-Agenten ist sein wissensbasiertes Modul, das zwischen Wissensrepräsentation und Wissensverarbeitung differenziert. Die Wissensdarstellung erfolgt in der Wissensbasis, die Wissensverarbeitung und Lösungsfindung in der Inferenzkomponente. Die persönlichen Kooperations-Agenten sind mit einer dialogbasierten Fragekomponente ausgestattet, über die der Fachplaner seine Problemstellung formulieren und an den jeweiligen Fachdomänen-Agenten senden kann. Mit seiner Erklärungskomponente kann er anschließend die erhaltenen Lösungsvorschläge einsehen. Zur Aufnahme von neuen Wissenselementen in die Expertenbasis z.B. durch die im Planungsprozess eingesetzten Fachplaner dient eine dialogbasierte Akquisitionskomponente. In vielen Fällen baut das Expertenwissen zudem auf Partialmodelle auf, die dem ganzheitlichen Produktdatenmodell einer Planung entstammen (produktmodellgebundene Wissensbasis). Während der kooperativen Projektbearbeitung muss dann das Faktenwissen in der Wissensbasis an das aktuelle Produktmodell der Tragwerksplanung angepasst werden. Diese Aufgabe übernimmt eine Sensor-/Aktorkomponente, die in dem Produktmodell-Agenten eingebaut ist.

Abb. 3.5. Prinzip der agentenbasierten Wissensverarbeitung im AMWiss

368

Jochen Bilek, Dietrich Hartmann

3.5.6 Kopplung der Teilmodelle Die nutzbringende Kooperation verschiedener, ingenieurspezifischer Softwareagenten basiert auf hoch entwickelten, mit domänenspezifischen Fachontologien gekoppelten Nachrichtenübermittlungsverfahren. Diese sind auf einer höheren semantischen Ebene als herkömmliche Ansätze (wie z.B. Middleware-Techniken) angesiedelt und sorgen u. a. für die zielgerichtete Zustellung von Fachinformationen zur richtigen Zeit am richtigen Ort. Die Modellierung der Kommunikations- und Koordinationsmechanismen ist ein zentraler Bestandteil des AMTP. Hierbei wurde konsequent auf die FIPASpezifikationen für Agenten bzw. Agentensysteme gesetzt (FIPA 2002). Die Kommunikation zwischen den Agenten erfolgt mit der nachrichtenorientierten, auf der Sprechakttheorie basierten FIPA-Agent Communication Language (FIPAACL). Die Nachrichtenspezifikation und Kommunikationssprache ist dabei eher eine technische Realisierungsfrage, wohingegen die Extraktion und Verarbeitung der eigentlichen Nachrichteninhalte – die übermittelten semantischen Informationen einer Nachricht – zweckmäßig mit Hilfe von Ontologien durchgeführt wird. Für die einzelnen Anwendungsbereiche (Produktmodell, Prozessunterstützung, Software-Wrapping etc.) wurden eigenständige Ontologien entwickelt, die klar und eindeutig den jeweiligen domänenspezifischen Wortschatz definieren. Bei der Strukturierung und Definition der nachrichtenbasierten Dialoge zwischen den Agenten wurde auf die FIPA-Interaktionsprotokolle gesetzt. Sie tragen wesentlich zur Koordination der von den Agenten ausgeführten, interdependenten Aktivitäten bei. Besondere Bedeutung hatte hierbei das FIPA-Request-Protokoll: Es wird immer dann verwendet, wenn ein Agent die Fähigkeiten eines anderen Agenten in Anspruch nehmen will – mithin also Aufgaben an diesen delegieren will – und auf Ergebnisse des anderen Agenten angewiesen ist. Die hier entwickelte Mischung aus FIPA-ACL, Ontologien und Interaktionsprotokollen hat sich als tragfähig, flexibel und leistungsstark erwiesen. Die Kopplung und Koordination der in den einzelnen Teilmodellen modellierten Softwareagenten gelingt mit diesem hybriden Ansatz auf einfache Art und Weise.

3.6 Multiagentensystem für die Tragwerksplanung ACOS Die softwaretechnische Realisierung des AMTP erfolgte im Multiagentensystem für die kooperative Tragwerksplanung ACOS (Agent-based COllaborative Structural Design System). Für den Nachweis der Gebrauchstauglichkeit und Leistungsfähigkeit des AMTP war die softwaretechnische Realisierung der in nachfolgender Tabelle aufgelisteten ACOS-Agenten ausreichend:

Kooperative Tragwerksplanung basierend auf Multiagentensystemen

369

Tabelle 3.1. ACOS-Teilmodelle Teilmodell Agententyp

Zweck/Kurzbeschreibung

x Schnittstelle der Fachplaner zu ACOS Persönlicher x Einbindung modularer Benutzer-Interaktionsmodule, über KooperationsAMKoop

Projekt-Agent (PA) AMProd

die die Tragwerksplaner mit anderen ACOS-Agenten interagieren können

Agent (PKA)

x flexible Verwaltung von Gruppen, Rollen, Personen, Berechtigungen und Zuständigkeiten in ACOS

x Verwaltung beliebiger, ISO 10303 basierter Produktmodelle Produktmodellx Exemplarische Bereitstellung des CIS/2 und IFC ProduktdaAgent (PMA) tenmodells

AMProz

WorkflowAgent (WFA)

x Abwicklung je eines Planungsprozesses unter Einbeziehung farbiger, hierarchischer, zeitbehafteter Petrinetze

x Instantiierung von Workflow-Templates Finite-Element- x Durchführung und Überwachung von strukturanalytischen Wrapper-Agent (FEA) AMSoft

DatenbankWrapper-Agent (DBA) CAD-WrapperAgent (CADA)

AMWiss

NachweisAgent (NA)

Finite-Element-Berechnungen

x Einbindung der FE-Programme Ansys und FElt x Integration des relationalen Datenbanksystems MySQL und des XML-basierten DBS XIndice

x Automatisierte Ablage von Produktmodelldaten durch genau x x x x x

spezifizierte Datenmodelle Darstellung von Produktmodellen Interaktive Mehrbenutzer-Zeichensitzungen Exemplarische Einbindung von AutoCAD 2002 Durchführung von Stahlbaunachweisen nach DIN Fachbericht 101-104, vor allem DIN FB 103 (Stahlbrücken) Durchführung von Stahlbetonbaunachweisen nach EC3

Alle Agenten sind generisch in Form von sog. Agententypen realisiert. Entscheidender Vorteil dabei ist, dass jeder Agententyp – mit projektspezifischen Randparametern zu einem konkreten Agenten instantiiert – leicht an einen bestimmten Anwendungskontext angepasst und ohne Modifikation des Quellcodes eingesetzt werden kann. So konnte vermieden werden, dass für jeden an der Planung beteiligten Fachplaner ein eigener Agent entwickelt werden musste. Für die Realisierung der verschiedenen Agententypen hat sich eine hybride Agentenarchitektur als besonders vorteilhaft erwiesen. Sie ist in Abb. 3.6 dargestellt. Jeder Agententyp besteht aus einem reaktiven Subsystem, das im Wesentlichen die Kommunikationsinfrastruktur beinhaltet und einem deliberativen Subsystem, das die als höherwertige Fähigkeiten einzustufenden, internen Dienste bzw. Fähigkeiten des Agenten repräsentiert. Durch die Aufspaltung wurde erreicht, dass die einzelnen Dienste komplett von der Kommunikationsschnittstelle entkoppelt sind, so dass sie in gekapselten, austauschbaren Software-Modulen, den Dienstmodulen, implementiert werden konnten. Die einzelnen Dienstmodule lassen sich infolgedessen zur Laufzeit in Agenten integrieren oder wieder entfernen und erlauben somit einen hochgradig

370

Jochen Bilek, Dietrich Hartmann

flexiblen, adaptiven und vor allem auf die jeweilige Projektsituation angepassten Einsatz der ACOS-Agenten.

Abb. 3.6. Prinzipieller Aufbau eines Softwareagenten für die Tragwerksplanung

3.6.1 Design und Implementierung der Kooperations-Agenten Der Projekt-Agent übernimmt die Abbildung, Verwaltung und Kontrolle der im Projektverlauf dynamischen Organisationsstrukturen, Verantwortlichkeiten und Zuständigkeiten. Hierzu ist der Projekt-Agent mit einem internen Projektmodell ausgestattet, das nach folgendem XML-Schema definiert ist: <users> Statiker usw. <username>Meier Meier@xp:27999/JADE usw.

Alle ACOS-Agenten publizieren zudem für ihre bereitgestellten Dienste sog. Berechtigungsobjekte, die mit bestehenden Gruppen oder Benutzern gekoppelt sind. Anhand der aktuell eingetragenen Benutzer und Rollen kann jeder Agent entscheiden, ob eine in Auftrag gegebene Aktion autorisiert ist. Eine Anpassung der zugewiesenen Rollen/Benutzer im Projektverlauf ist jederzeit möglich. Die Gesamtaufgabe des Projekt-Agenten, das „Projektmanagement“, ist in drei eigenständige Basisdienste untergliedert, die sich inhaltlich grundlegend voneinander unterscheiden und mit der entwickelten Projekt-Ontologie gekoppelt sind: 1. Daten-Modifikationsdienst: Der Projektleiter oder andere autorisierte Fachplaner können den Projekt-Agenten über ihre persönlichen KooperationsAgenten anweisen, das Projektmodell – entsprechend der aktuellen Projektsituation – anzupassen (z.B. Benutzer hinzufügen, Rollen zuweisen etc.). 2. Daten-Abfragedienst: Der Projekt-Agent bietet einen Dienst an, mit dem autorisierte Agenten Projektdaten jederzeit gezielt abfragen können.

Kooperative Tragwerksplanung basierend auf Multiagentensystemen

371

3. Beobachter-Notifikationsdienst: Der Projekt-Agent offeriert auf Basis des modifizierten Beobachter-Entwurfsmusters für Agenten (vgl. Bilek 2006a) einen Benachrichtigungsmechanismus, mit dem registrierte ACOS-Agenten über Änderungen am Projektmodell zeitnah informiert werden. Die Erprobung des PA hat gezeigt, dass dieser zuverlässig funktioniert und der gewählte Ansatz einer dynamischen Organisationsverwaltung – gekoppelt mit einer anpassbaren Zugriffsverwaltung – tragfähig und ausreichend flexibel ist. Der persönliche Kooperations-Agent wandelt Aktionen, die der ihm zugeordnete Fachplaner in ACOS durchführen will, in Agent-zu-Agent Interaktionen um (vgl. Abb. 3.7). Zur Umsetzung dieser Interaktionen in eine für den Menschen verständliche Darstellung dient das Konzept der Benutzer-Interaktionsmodule (BIM). Ein BIM ist eine Fähigkeit des PKA, auf Weisung des zugeordneten Akteurs ausgewählte Dienste anderer ACOS-Agenten in Anspruch zu nehmen, die im Gegenzug erhaltenen Ergebnisse graphisch aufzubereiten und evtl. weitere FolgeAktionen autonom auszulösen. Ein BIM ist damit ein auf ein spezielles Aufgabengebiet zugeschnittenes Interaktionsmodul, das eine gebrauchstaugliche, graphische Benutzer-Schnittstelle mit einem zugehörigen Interaktionsprotokoll und einer fachspezifischen Ontologie koppelt. Der PKA wurde so implementiert, dass er zur Laufzeit eine beliebige Anzahl an Benutzer-Interaktionsmodulen laden kann.

Abb. 3.7. Realisierung des Agententyps „Persönlicher Kooperations-Agent“

Prototypisch realisiert wurden sechs Benutzer-Interaktionsmodule für die Interaktion mit dem Projekt-Agenten, dem Produktmodell-Agenten, dem WorkflowAgenten, dem Nachweis-Agenten, dem FE-Wrapper-Agenten sowie ein BIM zur Unterstützung synchroner Kommunikation. 3.6.2 Design und Implementierung des Produktmodell-Agenten Für die Integration von Produktmodellen in ACOS wurde ein generischer Produktmodell-Agent entwickelt, der je eine Instanz eines beliebigen ISO10303basierten Produktdatenmodells verwalten kann. Die Bereitstellung ISO10303 konformer Produktmodelle durch den Produktmodell-Agenten erforderte zunächst die Entwicklung einer Java-Klassenbibliothek, um diese agentenintern und objektorientiert verarbeiten zu können. Derartige Java-Klassenbibliotheken sind für die maßgeblichen Produktmodelle CIS/2 und IFC nicht frei verfügbar und wurden deshalb selbst entwickelt.

372

Jochen Bilek, Dietrich Hartmann

Ausgangspunkt für die Entwicklung der Klassenbibliotheken sind die jeweiligen Produktmodellspezifikationen, die EXPRESS1-Schemata. Den in einem Schema spezifizierten Typen und Entities wird jeweils genau eine Java-Klasse zugeordnet. Eine Implementierung aller sich hieraus ergebenden Java-Klassen (1062 Klassen z.B. für den CIS/2 Standard) war aus Zeitgründen und wegen der hohen Fehleranfälligkeit nicht praktikabel. Stattdessen wurde der generische QuellcodeGenerator EXPRESS2Java-Generator entwickelt, der aus jedem beliebigen EXPRESS-Schema (hierzu zählt auch das IFC-Schema) eine entsprechende JavaKlassenbibliothek generiert; diese kann dann in den Produktmodell-Agenten eingearbeitet und zur Erzeugung ISO10303 konformer Produktmodelle eingesetzt werden. Die mit dem EXPRESS2Java-Generator erzeugten Produktmodell-Klassen können aufgrund ihrer JavaBean-Eigenschaften im Programmablauf generisch verarbeitet und zur Laufzeit dynamisch geladen werden. Folglich kann der PMA alle generierten, EXPRESS konformen Produktdatenmodelle verarbeiten und bereitstellen.

Abb. 3.8. AUML-Klassendiagramm des Produktmodell-Agenten

Für den Zugriff auf das integrierte Produktmodell stellt der Produktmodell-Agent die folgenden vier, in Abb. 3.8 als AUML-Klassendiagramm dargestellten Basisdienste in ACOS zur Verfügung: 1. Transaktions-Kompetenz: Durchführung von Änderungen am Produktmodell unter Beachtung der Bearbeitungszustände und der vom Projekt-Agenten verwalteten Zugriffsrechte. 2. Daten-Abfrage-Kompetenz: Gezielte Abfrage von Produktmodelldaten. Abfrage-Aktionen müssen ebenfalls vom Projekt-Agenten autorisiert sein. 3. Synchronisations-Kompetenz: Automatische Synchronisation der Produktmodellzustände der gemeinsam modellierenden Fachplaner bzw. persönlicher Agenten über einen Produktmodell-Beobachter-Mechanismus. 1

EXPRESS ist die Datenbeschreibungssprache nach ISO10303 zur Definition von Produktmodellspezifikationen

Kooperative Tragwerksplanung basierend auf Multiagentensystemen

373

4. Notifikations-Kompetenz: Synchronisations-Kompetenz für unpersönliche Agenten wie Workflow- und Wrapper-Agenten. Der Notifikations-Service benachrichtigt registrierte ACOS-Agenten über die für sie relevanten Änderungen im Bearbeitungszustand einzelner Produktmodell-Objekte. Für die Inanspruchnahme dieser Dienste über Nachrichten und Interaktionsprotokolle wurde ein eigenes Vokabular, die Produktmodell-Ontologie, entwickelt. Die Produktmodell-Ontologie ist generisch konzipiert und kann mit allen Produktdatenmodellen (CIS/2, IFC, AP225) umgehen. Zur fachgerechten Nutzung des Produktmodell-Agenten durch die Planungsbeteiligten wurde das generische Produktmodell-Benutzer-Interaktionsmodul (PMBIM) implementiert. Mit dem PM-BIM kann jedes mit dem EXPRESS2JavaGenerator erzeugte Produktmodell bearbeitet werden. Aufgrund der fehlenden Semantik kann das PM-BIM jedoch nicht zur graphischen 2D- bzw. 3D-Darstellung einzelner Tragwerksmodelle herangezogen werden. Um den Fachplanern dennoch eine komfortable, übersichtliche und einfache Bearbeitung von Produktmodellen zu ermöglichen – wie sie es z.B. mit gängigen CAX-Softwaresystemen gewohnt sind – wurde zusätzlich das graphische Bearbeitungswerkzeug STEP3DViewer implementiert und in das PM-BIM integriert (s. Abb. 3.9).

Abb. 3.9. Produktmodellbearbeitung und -visualisierung mit dem STEP3DViewer: IFCGeschossbau (links) und CIS/2-Brückentragwerk (rechts)

3.6.3 Design und Implementierung des Workflow-Agenten Der Workflow-Agent (WFA) ist modular aufgebaut. Er besitzt eine definierte Schnittstelle zur Anbindung einer austauschbaren Workflow-Engine, eine graphische Oberfläche zur Kontrolle und aktiven Steuerung ablaufender Workflows und eine PNML-Schnittstelle (Petri Net Markup Language) für den Im- und Export von bereits modellierten Petrinetzen (Billington et al. 2003). Die Workflow-

374

Jochen Bilek, Dietrich Hartmann

Schnittstelle ist dabei direkt mit den bereitgestellten Workflow-Diensten (Versand von Aktivitäten/Empfang von Aktivitäts-Zustandsänderungen) und der WorkflowOntologie zur Nachrichtenauswertung gekoppelt, so dass im Wesentlichen die Workflow-Engine zu implementieren war. Prototypisch realisiert wurde eine auf höheren Petrinetzen basierende Workflow-Ausführungskomponente (Aalst 1998), die auf Basis des aktuellen Workflowzustands die durchzuführenden Planungsaktivitäten ermittelt und diese über die Workflow-Schnittstelle an verfügbare Ressourcen (weitere ACOS-Agenten, integrierte Applikationen) weiterleitet. Für die Ermittlung der projektspezifischen Ressourcen muss der WFA den Projekt-Agenten kontaktieren. Das verdeutlicht Abb. 3.10: Die Aktivität „Bogen abnehmen“ ist an die Gruppe „Prüfingenieur“ gebunden. Erst wenn ein menschlicher Fachplaner mit der Rolle „Prüfingenieur“ in das Multiagentensystem eintritt und zugleich die Aktivität „Bogen abnehmen“ ausführbar ist, kann die Workflow-Ausführungskomponente die Aktivität an den persönlichen Kooperations-Agenten des Fachplaners delegieren. Eine wichtige Funktion innerhalb der Workflow-Ausführungskomponente hat die Applikationsschnittstelle. Der zugehörige Applikationsmanager definiert, welche Aktivitäten durch Programme oder Software-Module substituiert werden (automatisierbare Aktivitäten). Die Applikationsbindung ist dynamisch: Applikationen können zur Laufzeit des Workflows an Transitionen gebunden werden.

Abb. 3.10. Oberfläche des Workflow-Agenten mit beispielhaftem Petrinetz

Über das Applikationskonzept wurden zeitbehaftete Transitionen und auch die Hierarchisierung von Planungsprozessen realisiert. Die Workflowsteuerung ist

Kooperative Tragwerksplanung basierend auf Multiagentensystemen

375

damit äußerst flexibel: Prozessverfeinerungen und Ressourcenbindungen erfolgen dynamisch während der Workflowausführung. Der Projektverantwortliche kann infolgedessen zur Laufzeit vielfältig auf die aktuelle Planungssituation reagieren. 3.6.4 Design und Implementierung der Wrapper-Agenten Zur Einbindung von Finite-Element-Programmen in ACOS wurde der FiniteElement-Wrapper-Agent (FEA) entwickelt. Er integriert prototypisch das bei der Tragwerksanalyse häufig eingesetzte FE-Softwaresystem Ansys (Version 8.1) sowie das FE-Programm FElt (Finite Element light). Die technische Anbindung von Ansys und FElt an den FE-Agenten erfolgt über ihre Kommandozeileninterpreter (Batch-Modus), weil sie keine Java-Programmierschnittstellen besitzen. Der FEAgent verfügt dabei über die Fähigkeit, mehrere Berechnungen parallel auszuführen. Darüber hinaus stellt er weitere Fähigkeiten zur Kontrolle ablaufender FEBerechnungen bereit (Statusabfragen zu laufenden Berechnungen, kontrollierter Abbruch von Berechnungsprozessen, Abfrage von Benchmarking-Informationen). Der FEA wurde sowohl auf Windows-Rechnern als auch auf Linux-Systemen erfolgreich getestet. Zur Integration verschiedener professioneller Datenbanksysteme in ACOS wurde in Zusammenarbeit mit dem Darmstädter Projekt ein Datenbank-WrapperAgent (DBA) realisiert. Der DBA kapselt wichtige Funktionalitäten zur Verwaltung und Nutzung der integrierten Datenbanksysteme und macht diese für andere ACOS-Agenten über eine Datenbank-Ontologie nutzbar. Zum Zugriff auf die Datenbanken wurde ein Schichtenmodell entwickelt, das aus einem MappingFramework und einem Datenbank-Adapter besteht. Aufgabe des DB-Adapters ist die physikalische Einbindung von relationalen und hierarchischen DBS. Das Mapping-Framework dagegen ist die Schnittstelle zwischen DB-Agent und physikalischem Datenbankzugriff über den DB-Adapter. Es ermöglicht, die agentenintern verwendeten objektorientierten Datenmodelle, die aus der Extraktion von eingehenden Nachrichten resultieren, auf das Datenmodell des verwendeten DBS abzubilden. Die Funktionstüchtigkeit des Datenbank-Agenten mit integriertem DB-Adapter und Mapping-Framework wurde prototypisch anhand der relationalen Datenbank MySQL sowie der XML-Datenbank XIndice erfolgreich getestet. Der CAD-Wrapper-Agent (CADA) bindet – stellvertretend für weitere CADSysteme – die CAD-Software AutoCAD2002 (ACAD) in ACOS ein. Der CADWrapper-Agent ist an die Existenz einer gültigen AutoCAD-Installation gebunden und muss infolgedessen auf einem Rechner gestartet werden, auf dem ACAD verfügbar ist. Das ist i.d.R. der Arbeitsplatzrechner eines Fachplaners. Zur technischen Anbindung von AutoCAD an den CAD-Agenten wurde die COM-Schnittstelle von AutoCAD herangezogen. Alle 448 Klassen der COM-Schnittstelle wurden in einem eigenen Paket, dem com2acad-Framework, anwendungsfreundlich strukturiert und gekapselt. Das com2acad-Framework wurde auch im Bonner Projekt erfolgreich eingesetzt. Über eine einfache CAD-Ontologie können einzelne Zeichnungsobjekte oder vollständige Zeichnungen zur Visualisierung an einen CAD-Agenten geschickt werden. Zusätzlich kann sich jeder ACOS-Agent bei ei-

376

Jochen Bilek, Dietrich Hartmann

nem ACAD-Agenten als Beobachter registrieren. Er erhält dann Informationen über alle auftretenden ACAD-Ereignisse (Löschen von Zeichenobjekten etc.). Damit kann ein CAD-Agent andere beteiligte Agenten proaktiv über Änderungen in Zeichnungen, die er überwacht, informieren. Hieraus lassen sich – das wurde erfolgreich erprobt – interaktive Mehrbenutzer-Zeichensitzungen durchführen. 3.6.5 Design und Implementierung des Nachweis-Agenten Die Realisierung des AMWiss beschränkte sich im Rahmen der Forschungsarbeit auf die prototypische Implementierung eines generischen Nachweis-Agenten (NA). Der Nachweis-Agent ist modular aufgebaut, so dass beliebige Tragfestigkeits- und Gebrauchstauglichkeitsnachweise, z.B. aus den Fachdomänen Stahlbau oder Stahlbetonbau, zur Laufzeit hinzugefügt und jederzeit im Agentenverbund durchgeführt werden können. Der Nachweis-Agent stellt hierzu die zwei folgenden Dienste zur Verfügung: 1. Wissensakquisitions-Dienst: Autorisierte Experten können neue Nachweise/ Nachweisverfahren in die Wissensbasis des Nachweis-Agenten einfügen und bereits vorhandenes Wissen anpassen. 2. Nachweis-Dienst: Tragwerksplaner können über den Nachweis-Dienst interaktiv mit dem Nachweis-Agenten Bemessungsaufgaben durchführen. Die Formalisierung und Durchführung der Tragsicherheits- und Gebrauchstauglichkeitsnachweise erfolgt durch ein austauschbares, wissensbasiertes Nachweismodul. Es basiert auf einem regelbasierten Expertensystemansatz, der bereits gewonnene Erkenntnisse zur Abbildung und Verarbeitung von Regeln, Bedingungen und Fakten bei der Nachweisführung im Konstruktiven Ingenieurbau (Hartmann u. Lehner 1990) berücksichtigt. Eine Evaluierung bestehender Regelsysteme hat ergeben, dass das regelbasierte Expertensystem JESS (Java Expert System Shell) für die Verarbeitung von Tragsicherheits- und Bemessungsaufgaben besonders gut geeignet ist. JESS unterstützt Vorwärts- als auch Rückwärtsverkettung und ist infolgedessen hervorragend für die Implementierung des wissensbasierten Nachweismoduls geeignet. Zur Erprobung des Nachweis-Agenten wurden exemplarisch einige Tragsicherheitsnachweise nach DIN 18800 Teil 2 Stahlbauten und dem DIN-Fachbericht 103 Teil 5 Stahlbrücken realisiert (ein- und zweiachsige Zug-, Knick, Biegeknick- und Biegedrillknicknachweise). Allgemeingültige, ingenieurmäßige Fakten wie Profiloder Materialdaten wurden in eigene Module gebündelt, die dann in alle Nachweise – falls erforderlich – eingebunden werden können. 3.6.6 Eingesetzte Hard- und Software Eine ausgiebige Recherche hat ergeben, dass bisher noch keine speziell auf die Entwicklung von Softwareagenten ausgerichtete Programmiersprache existiert. Verfügbar sind allerdings Agentenplattformen. Diese sind i.d.R. objektorientiert

Kooperative Tragwerksplanung basierend auf Multiagentensystemen

377

aufgebaut und in der Programmiersprache Java programmiert. Infolgedessen wurde die ACOS-Agenten in Java (Version 1.4) implementiert. Als Agentenlaufzeitund Entwicklungsumgebung hat sich die FIPA-konforme Agentenplattform JADE (Java Agent DEvelopment Framework) bewährt (Bellifemine et al. 1999). JADE unterstützt insbesondere die Integration der in der Projektarbeit entwickelten Interaktionsprotokolle und den damit verknüpften, für die Einbringung von Wissen wichtigen Ontologien sowie deren Kopplung mit den agenteninternen Dienstmodulen. Zusätzlich konnten leichtgewichtige Agenten zur Workflow-Teilnahme auch auf mobilen Kleinstrechnern wie Mobilfunkgeräten gestartet und in das Multiagentensystem integriert werden (Bilek 2005). Da die Implementierung in der Plattform-unabhängigen Programmiersprache Java erfolgte, waren keine speziellen Anforderungen an Hardware und Betriebssysteme notwendig.

3.7 Evaluierung und Anwendungsbeispiel Als Anwendungsbeispiel und Evaluierungsszenario dient die Planung einer bereits fertiggestellten Fußgängerbogenbrücke über die Mulde in Dessau (s. Abb. 3.12).

Abb. 3.12. Planungsgegenstand „Fußgängerbogenbrücke über die Mulde in Dessau“ (rechts im STEP3DViewer mit Lastfall Verkehrslast)

Bei dem Referenztragwerk (Bauzeit 1.3. bis 31.10.2000) handelt es sich um eine kreisbogenförmige Bogenbrücke aus Stahl mit einer Spannweite von 107,65 m. Der weit gespannte Bogen hat einen Durchmesser von 81,28 cm ist aus der Vertikalen um 17° geneigt. Der 3,86 m breite, kreisbogenförmige Wegträger ist als Stahl-Hohlkasten ausgebildet und weist einen Radius von 105 m auf. Der Wegträger ist über 15 Bogenhänger aus Rundstahl mit dem Bogen verbunden und an beiden Auflagern unverschieblich und torsionssteif gelagert. Der Bogenträger dagegen ist an beiden Enden fest eingespannt. Im Rahmen des Anwendungsbeispiels wurde der gesamte Planungsvorgang von der Vorentwurfs- über die Entwurfs- und Genehmigungsplanung bis hin zur

378

Jochen Bilek, Dietrich Hartmann

Ausführungsplanung mit wechselnden Fachplanern und Aufgaben mit Hilfe des entwickelten Multiagentensystems detailliert durchgespielt.

Abb. 3.13. Vereinfacht dargestelltes, initiales Agentenmodell

Das aus den organisatorischen Projektrandbedingungen abgeleitete Agentenmodell und die physikalische Verteilung der benötigten Agenten zeigt Abb. 3.13. Die einzelnen Planungsbeteiligten werden durch persönliche Kooperations-Agenten unterstützt. Außerdem werden weitere für das Beispielprojekt erforderliche Agenten (Projekt-, Produktmodell-, Nachweis-Agent) auf dem zentralen Projektserver des Tragwerkplanungsbüros TPB X eingerichtet. Für die verteilte Produktmodellierung wurde ein CIS/2-Produktmodell-Agent eingesetzt und für FE-Berechnungen ein Ansys-FE-Wrapper-Agent. Für die Unterstützung der Nachweisführung nach DIN FB 103 wurde ein Nachweis-Agent verwendet. Das Anwendungsbeispiel hat gezeigt, dass das Multiagentensystem ACOS die reibungslose Zusammenarbeit der Planungsbeteiligten in allen Phasen der Tragwerksplanung effektiv und effizient unterstützt und für eine Minimierung von Konfliktpotentialen und vermeidbaren Planungsfehlern sorgt. Im Einzelnen ergeben sich nachweisbar durch den Einsatz von ACOS folgende Vorteile:

x x x x x x

Durchgängiger und verlustfreier Informationsfluss Koordinierung und Parallelisierung von Planungstätigkeiten Transparenz der Planungsentscheidungen und -vorgänge Optimale und kostengünstige Nutzung von Ressourcen und Fachwissen Hohe Fehlertoleranz und robustes Systemverhalten Unkomplizierter, wartungsarmer Einsatz der Agentensoftware in heterogenen Hard- und Softwareumgebungen x Wiederverwendbarkeit der ACOS-Agenten in verschiedenen Planungsprojekten Neben der qualitativen Evaluierung von ACOS wurde auch eine quantitative Bewertung hinsichtlich Performance, Laufzeitverhalten und erzeugter Netzlast durchgeführt. Die qualitativen Analysen haben ergeben, dass ACOS bis zu einem bestimmten Grad beliebig skaliert werden kann, ohne dass signifikante Perfor-

Kooperative Tragwerksplanung basierend auf Multiagentensystemen

379

mance-Probleme auftreten. Überschreitet die Anzahl der beteiligten Agenten bzw. der durchgeführten Aktionen jedoch diesen Wert, kann es zu systembedingten Performanceeinbußen bei den ACOS-Agenten kommen. In der Erprobungsphase wurde ohne Leistungseinbußen mit bis zu 15 Agenten experimentiert.

3.8 Zusammenfassung und Ausblick Im Rahmen des Forschungsprojekts wurde erstmalig die konzeptionelle und methodische Übertragung des Agentensystemparadigmas auf Planungsprozesse im KIB erreicht. Mit dem entwickelten Agentenmodell für die Tragwerksplanung AMTP gelingt die Abbildung der Planungsrealität auf insgesamt hohem Abstraktionsniveau. Das AMTP behebt damit konzeptuelle Schwächen, die bestehende Ansätze, beispielsweise das bewährte – auch im KIB weit verbreitete – objektorientierte Modellierparadigma, aufweisen. Aufbauend auf der Methodik der Multiagentensysteme wurde die wirklichkeitsnahe Modellierung der im Planungsverlauf komplexen Beziehungsgeflechte, Organisations- und Rollenstrukturen für den Bereich der vernetzt-kooperativen Tragwerksplanung über ein agentenbasiertes Kooperationsmodell mit anthropogenen Anteilen erfolgreich durchgeführt. Damit verbunden war die Entwicklung eines hochentwickelten sprechakt- und ontologie-basierten Kommunikations- und Interaktionsmechanismus, der auf einer höheren semantischen Ebene als bisherige, Middleware-basierte Ansätze angesiedelt ist. Die Tragfähigkeit des AMTP konnte erfolgreich im Multiagentensystem ACOS nachgewiesen und evaluiert werden. Die erreichten Ergebnisse zeigen, dass kooperationsunterstützende Systeme im KIB enormes Potential besitzen, um Planungsprozesse effizienter gestalten und damit die Wettbewerbsfähigkeit von Planungsbüros steigern zu können. Die jedoch häufig anzutreffende strukturelle Abgeschlossenheit solcher Systeme wird mit dem hier entwickelten, offenen Multiagentensystem-Ansatz aufgehoben: ACOS ist ein dezentrales, adaptives, erweiterbares und ausfallsicheres Kooperationssystem. Im Sinne eines „steckerkompatiblen Network-Computing“ können zur Laufzeit beliebig wieder verwendbare Funktionalitäten, Fachwissen und Fachmodelle – wie die Petrinetz-basierte Koordination der Arbeitsprozesse, die Integration ISO10303-basierter Produktmodelle oder die Bereitstellung regelbasierter Nachweissysteme – in Form von Agenten hinzugefügt oder entfernt werden. Zusätzlich wurde der Nachweis erbracht, dass das Konzept des agentenbasierten Software-Wrapping tragfähig, gebrauchstauglich und flexibel ist. Eine Integration weiterer, bewährter Ingenieursoftware in ACOS durch softwarespezifisch angepasste Wrapper-Agenten kann bei Bedarf jederzeit vorgenommen werden, sofern die einzubindende Applikation über geeignete Schnittstellen verfügt. Die Bedeutung kooperativer, rechnergestützter Systeme in der Bau-/Tragwerksplanung nimmt beständig zu – nicht zuletzt aufgrund der Globalisierung und der damit verbundenen Projektabwicklung über Ländergrenzen hinweg. Die Fortführung und Verstärkung der Forschungsaktivitäten auf dem Gebiet der kooperationsunterstützenden Systeme erscheint daher unbedingt geboten. Vom Standpunkt

380

Jochen Bilek, Dietrich Hartmann

des Software-Engineering ist der in dieser Arbeit verfolgte agentenbasierte Ansatz zukunfts- und richtungsweisend. Es ist zu erwarten, dass der Einsatz von Multiagentensystemen mittel- und langfristig – auch für das gesamte Spektrum der vernetzt-kooperativen Bauplanung (Technische Gebäudeausrüstung, Grundbau etc.) – deutlich zunimmt. In diesem Zusammenhang ist der Aufbau eines geeigneten, umfassenden und einheitlichen Formalisierungskalküls zur Beschreibung der für das Bauwesen noch zu entwickelnden Multiagentensysteme – z.B. in Form eines gesonderten Forschungsvorhabens – dringend anzuraten. Eine wichtige Voraussetzung für die erfolgreiche, interdisziplinäre Kooperation auf übergeordneter Ebene ist – das hat das Forschungsprojekt gezeigt – die Bereitstellung eines gemeinsamen Planungsmaterials, dessen Teile in konsistenter Weise parallel bearbeitbar sind. Die Notwendigkeit für ein solches, fachgebietsübergreifendes Produktmodell, das den gesamten Bereich der Bauwerksplanung abdeckt, ist auch von der AG „Verteilte Produktmodelle“ bestätigt worden. Aber auch der von der IAI vorgeschlagene, umfassende IFC-Standard, der als einziges, ernstzunehmendes Bau-Produktmodell angesehen werden muss (IAI 2003), wurde nur zögerlich von den Softwareherstellern angenommen und hat sich bisher nicht in der Baubranche etablieren können. Schließlich ist für Modellierung und Formalisierung der koordiniert durchzuführenden Planungsaktivitäten – wie mit den in diesem und auch anderen Projekten der AG „Verteilte Prozessmodelle“ verwendeten Petrinetzen – ein vertieftes Verständnis der zugrunde liegenden Planungsprozesse erforderlich. Das fundierte Wissen, wie Fachplaner im Planungsprozess gemeinsam entwerfen und konstruieren, ist bisher jedoch nur schwach ausgeprägt. In der gängigen Ingenieurpraxis beruhen die praktizierten Arbeitsweisen weitgehend auf Erfahrungen, Heuristiken und Ad-Hoc-Entscheidungen. Ihre Verwendung als Modellierungsgrundlage ist infolgedessen schwierig. Folglich ist es ratsam, in zukünftigen Arbeiten – aufbauend auf die bisher erzielten Ergebnisse – verstärkt eine wissenschaftlich fundierte Systematik der Planungsprozesse zu entwickeln, die für die Baupraxis geeignet ist und von den verantwortlichen Projektleitern angewandt werden kann.

Literatur v. d. Aalst W (1998) The Application of Petri-Nets to Workflow Management. In: Journal of Circuits, Systems and Computers 8, no 1, pp 21–66 Alda S, Bilek J, Cremers AB, Hartmann D (2004) Support of Collaborative Structural Design Processes through the Integration of Peer-to-Peer and Multiagent Architectures. In: Xth Intl. Conference on Computing in Civil and Building Engineering, Weimar Bellifemine F, Poggi A, Rimassa G (1999) JADE – A FIPA-compliant Agent Framework. Technischer Bericht, Telekom Labs Italia Bilek J (2002) Forum Bauinformatik 2002 – Junge Wissenschaftler forschen. FortschrittBerichte VDI, Reihe 4, Nr. 181, VDI-Verlag, Düsseldorf Bilek J (2004) Java im Bauwesen – Performance-Untersuchung einer agentenbasierten Tragwerksberechnung. In: Computer im Bauwesen, Shaker Verlag, Aachen

Kooperative Tragwerksplanung basierend auf Multiagentensystemen

381

Bilek J (2005) Integration mobiler Kleinstgeräte in ein Multiagentensystem für die vernetzt-kooperative Tragwerksplanung. In: 17. Forum Bauinformatik, Cottbus Bilek J (2006a) Vernetzt-kooperative Tragwerksplanung mit ingenieurspezifischen Softwareagenten. Dissertation, Ruhr-Universität Bochum Bilek J (2006b) Entwicklung interaktiver, dynamischer Ingenieuranwendungen auf der Basis von AJAX. In: Forum Bauinformatik – Junge Wissenschaftler forschen, Weimar Bilek J, Hartmann D (2002a) Kooperative Tragwerksplanung basierend auf Multiagentensystemen. In: VDI-Berichte 1668 – Bauen mit Computern – Kooperation in ITNetzwerken, VDI-Verlag, Düsseldorf, S 282–306 Bilek J, Hartmann D (2002b) Collaborative Structural Engineering based on Multiagent Systems. In: 9th International Workshop of the European Group for Intelligent Computing in Engineering (EG-ICE), VDI-Verlag, Darmstadt, pp 49–60 Bilek J, Hartmann D (2003a) Development of an Agent-based Workbench supporting Collaborative Structural Design. In: Proceedings of the 20th CIB W78 Conference on Information Technology in Construction, University of Auckland, Neuseeland, pp 39–46 Bilek J, Hartmann D (2003b) Agentenbasiertes Kooperationsmodell zur Unterstützung vernetzter Planungsprozesse in der Tragwerksplanung. In: 16. Intl. Kolloquium über Anwendungen der Informatik und Mathematik in Architektur und Bauwesen, Weimar Bilek J, Hartmann D (2003c) Modell zur Abbildung vernetzt-kooperativer Planungsprozesse in der Tragwerksplanung auf Softwareagenten. In: Forum Bauinformatik 2003 – Junge Wissenschaftler forschen, Shaker Verlag, Aachen, S 238–249 Bilek J, Hartmann D (2004) Collaborative based on Multiagent Systems and Adaptive Association Networks. In: Deutsches Bauinformatik Symposium, Moskau Bilek J, Hartmann D (2006) Agent-based Collaborative Work Environment for Concurrent Structural Design Processes. In: Joint International Conference on Computing and Decision Making in Civil and Building Engineering, Montreal Bilek J, Schrader C (2006) Entwicklung eines Softwareagenten zur Aufbereitung von Finite-Element-Daten höherwertiger Produktdatenmodelle und ihre Weiterverarbeitung in einem Multiagentensystem. In: Forum Bauinformatik 2006, Weimar Bilek J, Wellmann-Jelic A (2004) Durchführung paralleler Ermüdungssimulationen von Stahlbauteilen mit Hilfe von Software-Agenten. In: Zimmer J (Hrsg), Geller S (Hrsg) 16. Forum Bauinformatik – Junge Wissenschaftler forschen, S 9–19 Bilek J, Wellmann-Jelic A (2006) Effizienzvergleich eines Agenten-Frameworks für parallele Ermüdungssimulationen mit klassischen Parallelisierungstechniken. In: Forum Bauinformatik 2006, Weimar Bilek J, Mittrup I, Smarsly K, Hartmann D (2003) Agent-based Concepts for the Holistic Modelling of Concurrent Processes in Structural Engineering. In: 10th ISPE Intl. Conf. on Concurrent Engineering: Research and Applications, Balkema Publishers, pp 47–53 Bilek J, Hartmann D, Meissner U, Rüppel U, Theiß M (2004a) Integration of Productmodel Databases into Multi-Agent Systems. In: Xth International Conference on Computing in Civil and Building Engineering (ICCCBE), Weimar Bilek J, Smarsly K, Mittrup I, Bloch M (2004b) Implementierung eines Software-Agenten zur Verwaltung komplexer Datenbestände aus dem Bauwesen. In: Zimmer J (Hrsg), Geller S (Hrsg) 16. Forum Bauinformatik – Junge Wissenschaftler forschen, S 20–27 Bilek J, Wellmann-Jelic A, Galffy M, Hartmann D (2005a) Parallel Software Framework for Fatigue Analyses Based on Software Agents. In: International Conference on Computing in Civil Engineering (ICCC), Cancun, Mexico Bilek J, Alda S, Cremers AB, Hartmann D (2005b) Integrated Multiagent and Peer-to-Peer based Workflow-Control of Dynamic Networked Co-operations in Structural Design. In: 21th Intl. Council for Research & Innovation in Building and Construction, Dresden

382

Jochen Bilek, Dietrich Hartmann

Bilek J, Alda S, Hartmann D, Cremers AB (2006) Awareness- and Workflow-based Coordination of Networked Co-operations in Structural Design. In: Katranuschkov P (Hrsg) Journal of Information Technology in Construction (ITcon), vol. 11 Billington J, Christensen S, Hee van K, Kindler E, Kummer O, Petrucci L, Post R, Stehno C, Weber M (2003) The Petri Net Markup Language: Concepts, Technology and Tools. In: 24th Intl. Conference on Application and Theory of Petri Nets, Eindhoven Borghoff U, Schlichter J (1998) Rechnergestützte Gruppenarbeit. Springer Verlag FIPA (2002) FIPA 2000 Standards – Foundation for Intelligent Physical Agents. Genf Hartmann D, Lehner KH (1990) Technische Expertensysteme. Springer Verlag, Heidelberg

4 Komponentenbasierte Plattform für anpassbare, vernetzte Systeme im Bauwesen

Armin B. Cremers, Sascha Alda Institut für Informatik III, Rheinische Friedrich-Wilhelms-Universität Bonn {abc, alda}@cs.uni-bonn.de

4.1 Einleitung In dem folgenden Abschnitt werden die wesentlichen Ziele des Projekts CoBE1, wie im ursprünglichen Projektantrag dargestellt sowie wie in den Folgeanträgen weiter erodiert, zusammengefasst. In dem anschließenden Abschnitt 4.1.2 werden die Beiträge aus dem Projekt kurz erläutert. 4.1.1 Ziele des Projekts Das angestrebte Ziel des Projekts CoBE war die Entwicklung einer kompontenbasierten Plattform zur Unterstützung von verteilten Planungsszenarien im Konstruktiven Ingenieurbau. Das Projekt hatte demnach das Ziel, einen Beitrag zu einem der wesentlichen Ziele des Schwerpunkts, der Software-unterstützten Neugestaltung der Kommunikation von Ingenieuren in vernetzt-kooperativen Plannungsszenarien, beizutragen. Eine weitere Maßgabe des Projekts war es, neben der Entwicklung von Software-Modellen sowie Methoden zur Entwicklung von Fachsoftware für den Konstruktiven Ingenieurbau, branchenübliche Standardsoftware (z.B. AutoCAD) in eine derartige Plattform nahtlos integrieren zu können. Dieses Ziel entsprach einer weiteren Zielsetzung des Schwerpunkts, der Entwicklung von Methoden zur Einbindung von (vorhandener) Software im Konstruktiven Ingenieurbau. Zur Entwicklung einer Software-Plattform in dem gegebenen Anwendungskontext eines verteilt-kooperativen Szenarios mussten zunächst die Merkmale und 1

Component-based Software Plattform for Civil and Building Engineering

384

Armin B. Cremers, Sascha Alda

somit ein generelles Verständnis von solchen Szenarien analysiert werden. Diese Analyse wurde zunächst allgemein, später anhand von konkreten Plannungsszenarien aus dem Bereich der Tragwerksmodellierung durchgeführt. Dadurch konnten funktionale sowie nichtfunktionale Anforderungen in Form von Use Cases erhoben werden. Eine essentielle nichtfunktionale Anforderung war dabei die Forderung nach einer flexibel anpassbaren Plattform, die es Fachplanern erlaubt, lokale Software gemäß neuen Anforderungen oder aufgrund von Änderungen in der Umgebung (beispielsweise durch den Ausfall eines Partners) kontextabhängig anzupassen. Der ursprüngliche Antrag hat dabei die Hypothese vertreten, dass eine Plattform, welche moderne Entwicklungsmethoden aus der Komponententechnologie (Szyperski et al. 2002) adaptiert, diese Forderung effektiv erfüllen kann. Ziel des Projekts CoBE war es nunmehr zu evaluieren, inwiefern vorhandene komponentenbasierte Methoden, die aus Vorarbeiten der Universität Bonn resultierten (Stiemerling 2000; Won 2004), für eine Software-Plattform zur Unterstützung von verteilt-kooperativen Anwendungsszenarien übertragen bzw. angepasst werden müssen. Im Laufe der ersten Förderungsphase wurde ersichtlich, dass neben einer Software-Plattform zur Einbindung von ingenieurspezifischer Fachsoftware ein geeignetes verteiltes Prozessmodell notwenig ist, um die Zusammenarbeit der beteiligten Fachplaner innerhalb einer verteilten Kooperation zu verbessern. Dadurch wurde die Entwicklung eines Prozessmodells zur Neugestaltung von Planungsprozessen als weiteres Ziel formuliert. Dieses entsprach dem Schwerpunktziel „Neugestaltung von Planungsprozessen“. 4.1.2 Beiträge des Projekts Der Hauptbeitrag des Projekts CoBE ist die Software-Plattform DEEVOLVE (Mitrov 2003; Alda u. Cremers 2004; Alda et al. 2006). DEEVOLVE ist eine verteile Laufzeitumgebung zum Einsatz (engl. deployment), zur Veröffentlichung (engl. publication) sowie zur Suche (engl. discovery) von Peer Services innerhalb einer Service-orientierten Peer-to-Peer Software-Architektur. In dieser Architektur entspricht jeder DEEVOLVE Peer einem lokalen Rechner eines Fachplaners, der über einen entsprechenden Netzwerkanschluss mit anderen DEEVOLVE Peers kommunizieren kann. Aufgrund des Dualitätsprinzips der Peer-to-Peer Architektur ist jeder Peer Anbieter sowie Konsument von Diensten zugleich. Dieses Prinzip erlaubt es Fachplanern, eigene Fachsoftware und Entwurf-Dokumente anderen Teilnehmern zur Verwendung anzubieten bzw. diese von anderen Anbietern zu benutzen. Ein zentraler Server wird nicht benötigt. Peers können sich zu themenoder projektspezifischen Peergruppen zusammenfügen, die von den Fachplanern eigenständig verwaltet werden können. Dadurch wird der Zugriff auf Ressourcen (z.B. CAD-Dokumente, Dienste) entsprechend reguliert. Sämtliche Dienste innerhalb eines Peers entsprechen komponentenbasierten Applikationen. Auf Basis des zu Grunde liegenden Komponentenmodells (FLEXIBEAN) wurden komponentenbasierte Anpassungsoperationen definiert, die es Fachplanern ermöglichen, Applikationen (bzw. Dienste) effektiv anzupassen.

Komponentenbasierte Plattform für anpassbare, vernetzte Systeme im Bauwesen

385

DEEVOLVE ermöglicht es zudem, Ausnahmefälle wie den Ausfall eines abhängigen Peers zu entdecken. Unter Berücksichtigung des Arbeitskontexts eines Fachplaners können entsprechende Anpassungsoperationen zur Behebung des Ausnahmefalls selektiert und ausgeführt werden. Um die Zuverlässigkeit einer Service-Komposition insbesondere bei zeitkritischen Aktivitäten zusätzlich zu gewährleisten, können Fachplaner Service-Kontrakte in Form von Integritätsbedingungen formulieren. Auf Basis der DEEVOLVE Architektur wurde das COBE AWARENESS FRAMEWORK entwickelt. Dieses Framework kann von anderen Diensten benutzt werden, um Aktionen innerhalb eines Dienstes sichtbar für Anwender zu machen. Die entsprechende Information über eine erfolgte Aktivität (z.B. das Verändern eines Dokuments) kann anderen interessierten Fachplanern zur Verfügung gestellt werden. Auf Basis der Wahrnehmung (engl. awareness) dieser Informationen sind Fachplaner in der Lage, weitere, eigene Aktionen auszuführen. Das AwarenessModell dient als Modell zur Koordination von Planungsaktivitäten, in dem aber die Aktionen nicht à priori festgelegt werden müssen. 4.1.3 Weitere Gliederung des Berichts Nach der Darlegung der Ziele sowie der wesentlichen Beiträge des Projekts werden die erbrachten Beiträge ausführlich dargestellt. Kapitel 4.2 fasst die Ergebnisse der Analyse zusammen, in der es galt, die Anforderungen an eine SoftwarePlattform zu ermitteln. Kapitel 4.3 beschreibt die DEEVOLVE Plattform inklusive den Modellen zur Ausnahmebehandlung und Integritätsbedingungen. Das COBE AWARENESS FRAMEWORK wird in Kapitel 4.4 behandelt. Die Verzahnung des Projekts mit anderen Forschungsvorhaben aus der SPP-Arbeitsgruppe „Agenten“ wird in Kapitel 4.5 zusammengefasst. Abschließende Betrachtungen über das CoBE Projekt erfolgen in Kapitel 4.6.

4.2 Ergebnisse der Vorstudie In diesem Kapitel werden die Ergebnisse der Vorstudie dargestellt. Diese hatte das Ziel, ein Verständnis für die Eigenschaften von verteilten Planungsszenarien im Konstruktiven Ingenieurbau zu bekommen, um dann, in einem nächsten Schritt, entsprechende Anforderungen an eine passende Software-Architektur zu ermitteln, die als Basis für den Einsatz von Fachsoftware innerhalb eines verteilten Planungsszenarios dienen soll. 4.2.1 Visionäres Szenario In einem ersten Schritt zur Analyse der Eigenschaften von verteilten Planungsszenarien im Konstruktiven Ingenieurbau wurde ein visionäres Szenario erstellt. Ein

386

Armin B. Cremers, Sascha Alda

visionäres Szenario ist eine informelle Beschreibung, wie man ein zukünftiges Software-System in einer Anwendungsdomäne einsetzen und verwenden kann. Es berücksichtigt in diesem Zuge die wesentlichen Gegebenheiten und Einschränkungen der jeweiligen Domäne. Die Erstellung dieses visionären Szenarios basiert auf der allgemeinen Beobachtung, dass komplexe Bauprojekte im Konstruktivem Ingenieurbau als virtuelle Projektkonstellationen organisiert und durchgeführt werden, in denen die Partner örtlich verteilt und (oftmals) zeitlich versetzt miteinander kooperieren (Alda et al. 2006). Diese Projekte sind zudem durch eine strukturelle Dynamik (die Konstellation eines Projekts kann sich stetig ändern, z.B. durch den Wegfall eines Partners) sowie einer technischen Heterogenität (die lokalen Software- und Hardwareinstallationen sind unterschiedlich) maßgeblich gekennzeichnet. Trotz der allgemeinen Bereitschaft hin zur übergreifenden Kollaboration mit anderen Planern oder Akteuren, bestehen viele Fachplaner auf die Verwendung von proprietärer Fachsoftware, was die Interoperabilität zwischen den einzelnen Systemen potentiell verringern kann. Daneben herrscht oft ein Lokalitätsprinzip, d.h. Daten sollen vorzugsweise lokal vorhanden bleiben und nicht auf andere, zentrale Server ausgelagert werden. Gemeinsames Ziel (Erstellung eines Tragwerksmodell) Gesamtmodell Netzwerk (Internet)

Netzwerk (Internet) bearbeitet

Teilmodell

Bauingenieur A

bearbeitet

Teilmodell

bearbeitet

Statikprüfingenieur B

Teilmodell

bearbeitet

Fachplaner C

Teilmodell

Fachplaner D

Virtuelles Projekt “Tragwerksmodellierung einer Stahlbr ücke”

Abb. 4.1. Visionäres Szenario eines verteilten Planungsszenarios am Beispiel der Tragwerksplanung einer Stahlbrücke

Auf Grundlage dieser Annahmen wurde ein Szenario aus dem Bereich der Tragwerksplanung entwickelt, welches primäre Anforderungen einer SoftwarePlattform zur Unterstützung von derartigen Planungsszenarien widerspiegelt (Abb. 4.1). Dieses Szenario wurde in Zusammenarbeit mit dem Projekt aus Bochum entwickelt und ausführlich in (Alda et al. 2006) beschrieben. Technische Daten (z.B. über die zu modellierende Brücke) sind aus diesem Beitrag zu entnehmen. Das Szenario beschreibt einen Verbund aus vier verschiedenen Fachplanern, die zusammen an der Modellierung einer Stahlbrücke beteiligt sind. Das gemeinsame Ziel ist daher die Entwicklung eines gemeinsamen Tragwerkmodells. Dieses setzt sich aus einer Reihe von partiellen Teilmodellen zusammen, die von

Komponentenbasierte Plattform für anpassbare, vernetzte Systeme im Bauwesen

387

den jeweiligen Fachplanern zum Teil parallel bearbeitet werden. Die Konsistenz der Teilmodelle zu definierten Zeitpunkten ist dabei ein wichtiges Kriterium. Als Projektleiter wird ein Architekt angenommen, der die grundlegenden Kompetenzen der einzelnen Planer gesichtet und diesen einzelne Planungsaktivitäten zugeordnet hat. Der Architekt verfügt zudem über das Gesamtmodell der Konstruktion. Jeder Fachplaner modelliert seine ihm zugeordneten Tragwerksteile bezüglich der ihm übertragenden Rolle im Gesamtverbund. Diese Modellierung erfolgt lokal mit entsprechender Standardsoftware (hier: AutoCAD). Trotz der Möglichkeit der lokalen Bearbeitung können kontextbedingte Abhängigkeiten zu den Ergebnissen der anderen Fachplaner entstehen. Zur wirksamen Abstimmung der Planungsergebnisse wurden zwei wesentliche Dienste für notwendig gehalten: der flexible Austausch von Dokumenten sowie der Austausch von Informationen über Planungsaktivitäten. Es ist außerdem zu erwarten, dass Fachplaner Unterstützung von anderen, externen Experten benötigen. Der Architekt als Projektverantwortlicher soll darüber hinaus über die Fortschritte in dem Projekt informiert werden. Auf Basis des Szenarios der Tragwerksplanung konnte eine abstrakte Beschreibung in Form eines Anwendungsfalldiagramms (engl. use case diagram) hergeleitet werden, die von den Gegebenheiten eines konkreten Szenarios abstrahiert. Dieses wird im folgenden Abschnitt erläutert. 4.2.2 Use Case Diagramm Abbildung 4.2 skizziert das Use Case Diagramm zur abstrakten Darstellung der Anforderungen an eine Software-Plattform zur Unterstützung von verteilten Planungsszenarien im Konstruktiven Ingenieurbau. Jeder Use Case (Anwendungsfall) stellt die Funktionalität des Systems aus Sicht eines Akteurs (hier: Ingenieur) dar. Zentrale Anwendungsfälle sind dabei die Modellierung von Entwurfsmodellen mit lokaler Standard-CAD-Software, der gemeinsame Austausch (engl. sharing) von Entwurfsmodellen mit anderen Fachplanern sowie die Kollaboration mit Fachplanern. Der letzte Anwendungsfall beschreibt die Möglichkeit, dass Fachplaner untereinander aktiv Informationen über Planungszustände austauschen können, um auf deren Basis entsprechende Aktionen herzuleiten. Ziel dieser Bemühungen ist die konsistente Entwicklung eines Tragwerksmodells durch die Fachplaner der Kollaboration. Ein weiterer hilfreicher Anwendungsfall ist die eigentliche Festlegung der Grenzen einer Kollaboration, insbesondere, um den Zugriff auf planungsrelevante Ressourcen exakt zu bestimmen (d.h. welche Fachplaner sind Teil einer Kollaboration und was für Rechte besitzen diese) sowie, um Regeln der Kollaboration zu etablieren (z.B. Regeln zur Anpassung von Software, siehe (Alda 2005)). Die Festlegung der Grenzen aber auch die Definition des Ziels einer Kollaboration sollte in der Regel von einem Verantwortlichen (z.B. dem Architekten) übernommen werden. In dem Use Case Diagramm aus der Abb. 4.2. wird aus Gründen der Übersichtlichkeit keine Unterscheidung zwischen den Verantwortlichkeiten eines Akteurs gemacht.

388

Armin B. Cremers, Sascha Alda

arbeitet mit lokaler Standard CAD-Software

<>

tauscht EntwurfsModelle aus (share)

TragwerksIngenieur

kollaboriert mit anderen Fachplanern legt Grenzen der Kollaboration fest nutzt und offeriert Mehrwertdienste

Flexibilität / Anpassbarkeit

passt Software an

<>

definiert Service Kontrakte Zuverlässigkeit

<<extend>>

behandelt Ausnahmefälle <<extend>>

Abb. 4.2. Use Case Diagramm zur abstrakten Darstellung der Anforderungen an eine Software-Plattform zur Unterstützung von verteilen Planungsszenarien

Neben der Möglichkeit des Austauschs von Dokumenten und Informationen sollen Fachplaner zudem in der Lage sein, Mehrwertdienste anzubieten bzw. diese zu benutzen. Fachplaner aus dem Bereich des Brandschutzes können beispielsweise einen Mehrwertdienst zur Überprüfung von Brandschutzbestimmungen an einem Gebäudemodell anbieten. Möglich ist auch die Offerierung von Hardware (z.B. Zugriff auf teure Drucker) oder sonstige Software (z.B. Groupware-Funktionalitäten). Es soll die Möglichkeit bestehen, neue Dienste mit vorhandener lokaler Software zu verbinden, so dass eine Benutzung dieser erfolgen kann. Auf Grundlage der wesentlichen Anwendungsfälle wurden weitere Anwendungsfälle identifiziert, die wichtige nicht-funktionale Anforderungen der Software-Plattform umsetzen sollen. Dazu zählt die Möglichkeit des Ingenieurs, lokale Software (CAD, Mehrwertdienste) flexibel anpassen zu können. Um die Zuverlässigkeit während der Kollaboration zwischen Fachplaner zu verbessern, wird ein Anwendungsfall zur Definition von Service-Kontrakten angenommen. Dieser Anwendungsfall erlaubt es dem Fachplaner, sowohl Verbindlichkeiten als auch Nutzen bezüglich der Erreichbarkeit aber auch der Qualität von Diensten zu definieren. Dies kann hilfreich während der parallelen Modellierung von Fachmodellen sein, in denen die Verfügbarkeit von Diensten zur Abstimmung der Ergebnisse (z.B. durch den Austausch von einzelnen Partiellmodellen) während der Modellierungsaktivitäten erforderlich ist. Ein weiterer Anwendungsfall ist notwendig, um den Wegfall eines abhängigen Dienstes oder von Ressourcen zu behandeln. Eine derartige Fehlerbehandlung ist insbesondere dann notwendig, wenn der ausgefallene Dienst Teil eines aktiven Kontrakts ist. In dem nachfolgenden Kap. 4.4.3 wird die Software-Plattform DEEVOLVE vorgestellt, die die vorgestellten Anforderungen umsetzt. Das wissenschaftliche Augenmerk während der Entwicklung galt der Umsetzung der nicht-funktionalen Anforderungen Anpassbarkeit und Zuverlässigkeit in einer derartigen Plattform. Der Anwendungsfall zur Kollaboration zwischen Fachplanern wird im Wesentlichen durch das COBE AWARENESS FRAMEWORK (Kap. 4.4.4) realisiert.

Komponentenbasierte Plattform für anpassbare, vernetzte Systeme im Bauwesen

389

4.3 Die DEEVOLVE Plattform Dieses Kapitel fasst die erbrachten Beiträge rund um die DEEVOLVE Plattform zusammen. Zunächst wird auf die Struktur von Peer Services eingegangen. Danach erfolgt die Beschreibung der eigentlichen Plattform. 4.3.1 Peer Services und Komponentenmodell Ein Peer Service besteht aus einem lokalen sowie einem entfernten Teil (Abb. 4.3). Der lokale Teil implementiert die Kernfunktionalität eines Peer Services (z.B. ein CAD-System). Der entfernte Teil stellt die Schnittstelle zu der Kernfunktionalität des Peer Services dar. Sie kann von einer entfernten DEEVOLVE Laufzeitumgebung verwendet werden, um auf den von einem anderen Peer angebotenen Dienst zuzugreifen. Dabei kann es sich sowohl um eine graphische Benutzeroberfläche als auch um eine Programmierschnittstelle (API) handeln, die von anderen Peer Services oder lokalen Applikationen benutzt wird. Peer Services realisieren Mehrwertdienste für den Zugriff auf lokale Ressourcen. Sie stellen somit ein wichtiges Instrument zur gemeinsamen Benutzung von Ressourcen in einer Kollaboration dar.

veröffentlicht

Advertisement

Findet entscheidet

beschreibt

beschreibt

Anbieter Peer Service FlexiBean Komponente

Konsument Peer Service

(lokaler Teil )

Remote Interaction via RMI

(Schnittstelle )

Schnittstelle (GUI, API)

DeEvolve DeEvolve

Peer Laufzeitumgebung

Peer Laufzeitumgebung

Abb. 4.3. Das Peer Service Modell von DEEVOLVE

Der interne Aufbau eines lokalen sowie eines entfernten Teils eines Peer Services entspricht einer Komposition von Software-Komponenten. SoftwareKomponenten sind abgeschlossene Bausteine, die über dediziert vereinbarte Schnittstellen (Ports) miteinander kommunizieren können. Die Struktur einer Komponente ist durch das Java-basierte FLEXIBEAN Komponentenmodell (Stiemerling 2000) festgelegt. Das Komponentenmodell legt zudem Interaktionsprimitve fest, wie Komponenten miteinander interagieren können. Neben der Möglichkeit der unidirektionalen (ereignisbasierten) Interaktion zur Übermittlung von Information können Komponenten über „shared objects“ auf

390

Armin B. Cremers, Sascha Alda

bidirektionalem Wege große Menge von Daten austauschen. Die Interaktion zwischen der lokalen und der entfernten Komposition regelt ebenfalls das Komponentenmodell. Die Möglichkeit der Interaktion über Rechnergrenzen hinweg wird durch die explizite Einbindung der RMI Technologie erreicht. Aus Sicht einer Komponente ist die Interaktion transparent, d.h. sie kann nicht sehen, ob sie mit einer lokalen oder entfernten Komponente interagiert. Die Komposition von FLEXIBEAN Komponenten wird durch einen Kompositionsplan beschrieben. Die Syntax dieses Plans ist durch eine Sprache (CAT, steht für Composition Abstract Template) festgelegt. Ein gegebener Kompositionsplan wird beim Einsatz des Peer Service von der DEEVOLVE Laufzeitumgebung des Konsumenten gelesen und interpretiert. Auf Basis der interpretierten Informationen werden die enthaltenen Komponenten geladen und Verbindungen zwischen den Ports hergestellt. Für den Endanwender ist es allerdings nur bedingt möglich, auf Basis der CAT Beschreibung die Semantik eines Dienstes festzustellen und somit zu entscheiden, ob eine Komposition für einen intendierten Anwendungszweck verwendbar ist. Daher wurde das aus dem JXTA Framework (Sun 2005) bekannte Konzept der Advertisements benutzt, mit dem beliebige Ressourcen in einer XML-basierten Notation textuell zu beschreiben, die ein Peer anderen Peers zur Verfügung stellt. Advertisements enthalten außerdem Informationen, die ein entfernter Peer benötigt, um einen Peer Service lokal bei sich einzubinden (u.a. eine global eindeutige Netzwerk-Adresse (UUID), mit der ein Service identifiziert werden kann). Durch das Advertisement Konzept ist es möglich, die Existenz eines Peer Service innerhalb einer Kooperation bekannt zu geben. Der Konsument hat dann die Aufgabe auf Basis des Advertisements zu entscheiden, ob ein Dienst für seinen intendierten Zweck passend ist (s. Abb. 4.3). 4.3.2 Die DEEVOLVE Laufzeitumgebung (Plattform) Die DEEVOLVE Plattform entspricht einer verteilten Laufzeitumgebung für FLEXIBEAN-basierende Peer Services. Eine verteilte Laufzeitumgebung setzt sich aus einer Menge von einzelnen, lokalen Laufzeitumgebungen (Peers) zusammen, die auf konventionellen Rechnern bei Endbenutzern (hier: Ingenieure oder Fachplaner) installiert werden. Mittels dieser Laufzeitumgebungen sind diese in der Lage, sowohl eigene Peer Services zu publizieren als auch fremde Services zu konsumieren. DEEVOLVE basiert auf dem Architekturstil einer Service-orientierten Peer-toPeer Architektur (SOP2PA). Dieser Stil beschreibt die wesentlichen Elemente und Eigenschaften von einer Software-Architektur, die aus einer Menge gleichberechtigter Netzwerknoten oder Peers besteht, die sowohl als Anbieter als auch als Konsument von Peer Services fungieren können. Einzelne Services können zu neuen, höherwertigen Services oder Applikationen komponiert werden. Zum Zweck der Komposition von Peer Services wurde die Sprache PeerCAT (Alda u. Cremers 2004) entwickelt. Aggregrierte Services können durch ein Advertisement in einer Kollaboration bekannt gemacht und durch Dritte benutzt werden.

Komponentenbasierte Plattform für anpassbare, vernetzte Systeme im Bauwesen

391

DEEVOLVE verwendet des Weiteren das in JXTA realisierte Konzept der Selbstorganisation von Peers. Benutzer von Peers sind in der Lage, ihre Peers thematisch, inhaltlich oder organisatorisch zu selbst verwalteten Peergruppen über Netzwerkgrenzen hinweg zusammen zu schließen. Der Zugriff auf Dienste oder Daten innerhalb der Gruppe ist dabei nur den Mitgliedern der Gruppe erlaubt, unautorisierten Peers ist der Zugriff untersagt. Um Mitglied einer Gruppe zu werden, muss sich ein neuer Peer zunächst bei der betreffenden Gruppe bewerben. Falls die Bewerbung erfolgreich war, kann er der Gruppe beitreten und bekommt fortan Zugriff auf die gruppenrelevanten Ressourcen. Die Existenz sowie die inhaltliche Beschreibung einer Gruppe werden ebenfalls über Advertisements bekannt gegeben. Der Initiator einer Gruppe ist im weiteren Verlauf der Entscheidungsträger, der entscheidet, ob Fachplaner mit ihren Peers der Gruppe beitreten können. In DEEVOLVE können Peer Services mehreren Gruppen gleichzeitig zugeordnet werden. Dabei kann bestimmt werden, dass ein Peer in allen Gruppen Mitglied sein muss, bevor ihm der Zugriff gewährt wird. DEEVOLVE ist mit einer Reihe von Tools u.a. zur Suche, Anpassung und Komposition von Diensten ausgestattet. Zentrales Tool ist dabei die DEEVOLVE Konsole, aus der alle wesentlichen Management-Aufgaben ausgeführt werden können (s. (Alda u. Cremers 2004)). 4.3.3 Integration von Standard-Software Das FLEXIBEAN Komponentenmodell stellt ein Regelwerk zur Erstellung von eigener Software zur Verfügung, welches von erfahrenen Ingenieuren benutzt werden kann, um eigene, ingenieurspezifische Software in einer vernetzten Kooperation zur Verfügung zu stellen. Für einen praktikablen Einsatz der Plattform ist dies jedoch nicht ausreichend, da es keine Möglichkeiten gibt, branchenübliche Standard-Software (insbesondere CAD-Software) aus dem Bereich des Konstruktiven Ingenieurbaus zu integrieren. Eine Integration ist oft ein Problem, da gängige CAD-Software aus Performanzgründen meist in der Programmiersprache C++ geschrieben sind und über keine offenen Schnittstelle verfügen, die den Zugriff auf interne Datensätze und Programmzustände erlauben. Als Ergänzung bietet DEEVOLVE den Einsatz einer so genannten COM2Java Bridge-Komponente (Katzmarzik 2003) an. Diese Komponente erlaubt es, aus einer FLEXIBEAN Komponente auf eine in der Programmiersprache C++ geschriebene Software-Komponente zuzugreifen und umgekehrt. Diese Komponente muss zudem über eine COM-kompatible, offene Schnittstelle verfügen. CAD-Software wie AutoCAD oder VisioCAD verfügen über eine derartige Schnittstelle. Über diese können Ausschnitte eines Entwurfsmodells sowie dessen Bearbeitungsstatus (geöffnet, verändert usw.) entnommen werden.

392

Armin B. Cremers, Sascha Alda

<> DocExchange

Model

FlexiBean Component (Java)

View

PartnerD PartnerC ExpertX

--- Event on 6/9/2006 (12:38) ---Successfully sent AutoCAD file to PartnerD Comment: “Hallo Jochen, wie findest du die neue Version des Modells?”

<> DocExchange

getDocFrom Consumer pushDocTo Consumer getDocFrom Provider pushDocTo Provider

PushDoc “PartnerA” (6/9/2006) 12:36 ReceivedDoc from “PartnerB” (6/9/2006) 12:34)

DocExchange - Local Interface AcadApplication <>

<port polarity =„required" type =„DocListener_event„ ID = „ getDocFromConsumer " /> <port polarity =„required" type=„DocPushXML_event„ ID = „ pushDocToConsumer " /> ....

Communication via TCP/IP

AcadApplication <>

COM2Java Bridge

AutoCAD 2002 Advertisement

Abb. 4.4. Integration von AutoCAD in einen Peer Service mittels COM2Java

In Abb. 4.4 ist das Zusammenspiel zwischen einer FLEXIBEAN Komponente und der Software AutoCAD innerhalb des Peer Services „DocExchange“ dargestellt. Dieser Peer Service wurde entwickelt, um den bidirektionalen Austausch von Teilmodellen zwischen Peers zu ermöglichen. Die interne View-Komponente erlaubt es einem Benutzer, das aktuelle Entwurfsmodell aus der lokalen AutoCAD Instanz zu entnehmen und an ausgewählten Benutzern zu senden (Button „PushDocument“ in Abb. 4.4). Diese Benutzer entsprechen Konsumenten des Peer Services, die diesen über das veröffentlichte Advertisement gefunden und integriert haben. Das Advertisement beschreibt die Schnittstelle, die eine lokale Applikation implementieren muss um mit dem „DocExchange“ Service zu interagieren. Eine lokale Installation eines „DocExchange“ Service kann mit den Schnittstellen entfernter „DocExchange“ Dienste (z.B. von anderen Fachplanern) kombiniert werden. Somit können über zwei „DocExchange“ Installationen Modelle in beide Richtungen ausgetauscht werden. Die somit verbundenen Fachplaner werden in der Liste der View-Komponenten angezeigt. Die Push-Funktionalität des Anbieters sendet über den Port „pushDocToConsumer“ Dokumente an registrierte Konsumenten. Sowohl Konsumenten als auch Anbieter des „DocExchange“ Service sind in der Lage, eine Kopie eines Entwurfsmodells anzufordern (Pull-Funktionalität). Die Kommunikation zwischen der View-Komponente und der AutoCAD-Instanz läuft über eine ModelKomponente, welche die COM2Java-Komponente kapselt. Die Kommunikation zwischen dieser und der COM-Komponente von AutoCAD erfolgt über TCP-IP.

Komponentenbasierte Plattform für anpassbare, vernetzte Systeme im Bauwesen

393

4.3.4 Ein Anwendungsszenario mit DEEVOLVE Das Anwenungsszenario eines verteilten Planungsszenarios aus dem Bereich der kooperativen Tragwerksmodellierung (Abschn. 4.2.1) kann mit der DEEVOLVE Plattform effektiv unterstützt werden (vgl. Abb. 4.5). Founder: Architect D (PeerD) Membership: Application to Architect <>: PeerX_(Expert X) provides ConsistencyChecker

<>

<>: Projekt “Stahlbrücke” <>

<> <><> <>

<> : PeerA_(Engineer A) provides DocExchange AwarenessData consumes DocExchange(PeerD) DocExchange (PeerB) ConsistencyChecker(X)

<>: PeerD_(Architect D) provides DocExchange consumes AwarenessData (PeerA)

<>: PeerC_(Engineer C) provides DocExchange

<>: PeerB_(Engineer B) provides DocExchange

Abb. 4.5. Unterstützung eines verteilten Planungsszenarios mit DEEVOLVE

Die Modellierung der DEEVOLVE Architektur basiert auf einer eigenen Erweiterung der Notation der UML 2.0. Das Element der Wolke wird angewandt, um eine Peergruppe zu visualisieren. Eine DEEVOLVE Laufzeitumgebung wird durch einen Hardwareknoten dargestellt, der sich mittels einer <> Assoziation auf eine Gruppe beziehen kann. Die in Abb. 4.5 dargestellte Architektur besteht aus einer Peergruppe “Steel-Bridge-Project”, der vier Peer Laufzeitumgebungen zugeordnet sind. Die Laufzeitumgebung des Architekten („PeerD_(Architect D)“) ist der Begründer der Peergruppe. Jeder Laufzeitumgebung kann man entnehmen, welche Peer Services jeweils angeboten bzw. welche von anderen konsumiert werden. Die eigentliche Modellierung der Dienste erfolgt in separaten Diagrammen, ähnlich die des „DocExchange“ Service in Abb. 4.4. Die Laufzeitumgebung des Fachplaners A („PeerA_(EngineerA)“) bezieht insgesamt drei Fremddienste. Zum aktiven Planungsaustausch mit Fachplaner B und dem Architekten D bezieht er die jeweiligen „DocExchange“ Dienste. Diese sind mit der lokalen „DocExchange“ Installation komponiert, so dass über diese Verbindungen aktive Dokumente aus AutoCAD ausgetauscht werden können. Der von Fachplaner A offerierte Dienst „AwarenessData“ wird vom Architekten bezogen, um ihn über fortlaufende Planungsaktivitäten zu unterrichten. Auf Basis dieser Informationen kann der Architekt weitere, eigene Aktivitäten ableiten (s. Abschn. 4.4). Der Dienst „ConsistencyChecker“ wird ebenfalls mit der lokalen „DocExchange“ Installation verknüpft. Über diese Verbindung kann ein Entwurfsmodell an den von einem Experten angebotenen Dienst geschickt werden.

394

Armin B. Cremers, Sascha Alda

Dieser ist dann in der Lage, das Dokument auf etwaige Inkonsistenzen oder Fehler zu überprüfen. 4.3.5 Integritätsbedingungen als Service-Kontrakt Die dynamische Verfügbarkeit der einzelnen Partner (bzw. deren Laufzeitumgebungen) kann die Effektivität von parallelen Planungsaktivitäten in einer vernetzten Kooperation negativ beeinflussen. In dem bereits geschilderten Szenario der Tragwerksmodellierung kann dies beispielsweise dann auftreten, wenn bei der Modellierung einer Stahlstütze Informationen über den Untergrund von einem anderen Fachplaner in Form eines Entwurfsmodells benötigt werden. Beim Ausfall oder Nichtvorhandensein des Peers des Fachplaners, der die notwendigen Informationen verwaltet und anbietet, können diese nicht mehr bezogen werden. Dadurch kann die Konsistenz der einzelnen Teilmodelle untereinander nicht mehr garantiert werden. In DEEVOLVE können Integritätsbedingungen auf Ebene einer ServiceKomposition definiert werden (Alda u. Mitrov 2004). Integritätsbedingungen enthalten einen Bedingungsteil, der festlegt, wann exakt eine Komposition gültig ist. Zudem können Prozeduren zur Ausnahmebehandlung (engl. exception handlers) definiert werden, die ausgeführt werden, falls eine Bedingung zur Laufzeit verletzt wird. Der hier gewählte Ansatz basiert auf dem bekannten ECS (Event, Condition, Action) Modell aus dem Bereich der aktiven Datenbanken. Obwohl sich Bedingungen durchaus auf mehrere Elemente einer Service-Komposition beziehen können (z.B. Parameter einzelner Komponenten), beziehen sich die realisierten Integritätsbedingungen nur auf die Verfügbarkeit einzelner Peer Services. Ausnahmebehandlung Instrumentierung von PeerCAT mit Integritätsbedingungen (Architekt, Ingenieur)

Einsatz und Start der Dienste (Ingenieur)

Instrumentierung von PeerCAT zur Ausnahmebehandlung (Architekt, Ingenieur)

Erkennung einer Ausnahme (System)

Entwurfszeit einer Komposition (Fachsoftware)

Manuelle Auswahl einer Option (Ingenieur)

Manuelle Anpassung (Ingenieur)

Automatische Anpassung (System)

Laufzeit der Fachsoftware

Abb. 4.6. Phasenmodell zur Erstellung und Verwaltung von Service Kontrakten

DEEVOLVE verwendet Integritätsbedingungen zur Etablierung von ServiceKontrakten zwischen den einzelnen Fachplanern. Diese Kontrakte definieren zum einen Verpflichtungen, zum anderen aber auch zu erwartende Leistungen der einzelnen Fachplaner, die als Anbieter bzw. als Konsument von Diensten fungieren. Der Prozess, wie und wann diese Kontrakte definiert werden, bleibt in DEEVOLE

Komponentenbasierte Plattform für anpassbare, vernetzte Systeme im Bauwesen

395

unbeachtet. Es wird angenommen, dass der Projektverantwortliche diese aufgrund seines breit gefächerten Wissens vordefinieren kann (vgl. Abb. 4.6). Erfahrene Fachplaner (z.B. Bauinformatiker) können sowohl Bedingungsteile als auch Behandlungsprozeduren überschreiben. Integritätsbedingungen werden deklarativ zu einer in PeerCAT beschriebenen Service-Komposition hinzugefügt. … <semantics> <description> Dieser Kontrakt unterstützt die parallele Modellierung des nördlichen Stützpfeilers der Stahlbrücke zwischen den Fachplanern A, B und X. <params = „remoteDoc_B, localDoc_A, checkerX“ /> <errorlevel value = „obligation“ description = “All services must be available” />

Abb. 4.7. Definition einer Integritätsbedingung in PeerCAT

Abbildung 4.7. zeigt den Bedingungsteil einer Integritätsbedingung, welche sich auf die Service-Komposition des Peers „PeerA_(EngineerA)“ aus Abb. 4.5 bezieht. Ein Bedingungsteil im Allgemeinen muss einen Kontext aufweisen, der besagt, wann diese Bedingung gültig ist. Ein Kontext entspricht einer diskreten Planungsaktivität, die z.B. aus einem Prozessmodell oder einer Projektbeschreibung zu entnehmen ist. In diesem Beispiel beschreibt der Kontext die Bearbeitung des nördlichen Stützpfeilers einer Stahlbrücke (siehe (Alda et al. 2006)). Benutzer können von allen gegebenen Kontexten über die DEEVOLVE Konsole den aktuellen Kontext auswählen. Der Bedingungsteil formuliert nun als Kondition, dass die Service-Komposition des Fachplaners A gültig ist, falls im Kontext der Modellierung des Stützpfeilers die Dienste „DocExchange“ des Partners B sowie der Dienst „ConsistencyChecker“ vom Experten X vorhanden und eingebunden sind. Diese Bedingung kann aufgrund der fachlichen Nähe dieser drei Planer während der Modellierung dieses Elements vertreten und daher angenommen werden. Das Vorhandensein des Architekten D ist in dieser Phase der Modellierung nicht vonnöten. Diese durch die Integritätsbedingung festgelegte Sub-Komposition (in Abb. 4.5. sind die betreffenden Peers grau schattiert) wird auch als minimale Komposition bezeichnet (Alda u. Cremers 2004). Falls die Bedingung erfüllt ist, kann die Konsistenz der partiellen Teilmodelle gewährleistet werden. Die Erfüllung der Integrität einer Service-Komposition gewährleistet somit auch die Konsistenz der partiellen Teilmodelle in einem gegebenen Modellierungskontext. Nach dem Start der Service-Komposition wird die assoziierte Integritätsbedingung gelesen und in ein objektorientiertes Schema umgewandelt. In der Phase der Ausnahmeerkennung (engl. exception detection) werden alle in dem Bedingungsteil involvierten Peers überwacht. Falls es zu einer Ausnahme kommt (d.h. beim

396

Armin B. Cremers, Sascha Alda

Wegfall eines Peers) werden alle Integritätsbedingungen zu dem aktuell selektierten Kontext auf Gültigkeit überprüft. Ist der weggefallene Peer Teil einer bestehenden und gültigen Integritätsbedingung, dann gilt diese als verletzt. Der Ausfall des Peers von Fachplaner B würde somit die Verletzung des Kontrakts hervorrufen, der Wegfall von Peer D jedoch nicht (vgl. Abb. 4.5). Bei der Verletzung einer Integritätsbedingung tritt die Phase der Ausnahmebehandlung in Kraft (s. Abb. 4.6 zur Illustration sowie (Palij 2006) für weitere Informationen). Der lokale Benutzer (hier: Fachplaner A) ist dabei in der Lage zwischen mehreren vordefinierten Routinen (engl. option) zu wählen (Abb. 4.8.).

Abb. 4.8. GUI-Dialog zur Auswahl einer Routine zur Ausnahmebehandlung

Die Auswahl der passenden Ausnahme-Routine kann dabei von zusätzlichen Kontextinformationen wie dem aktuellen Projektstatus, dem Zustand des Dokuments, oder der augenblicklichen Größe der Kooperation abhängen. Es ist daher dem Benutzer überlassen, die passende Routine zu selektieren. Diese Selektion hängt maßgeblich von seiner Wahrnehmung bzw. Einschätzung der aktuellen Kontextinformationen ab. Neben der benutzerorientierten Auswahl können Routinen automatisch ohne Intervention mit dem Benutzer ausgeführt werden. Dabei kann es sich bspw. um die Benachrichtigung aller beteiligten Partner handeln. Ausnahme-Routinen implementieren komponentenbasierte Anpassungsmethoden. Diese erlauben es unter anderem, neue Dienste zu suchen, in die PeerCAT Beschreibung einzubinden und entsprechend zu starten. Diese Methoden können verwendet werden, um z.B. einen unzuverlässigen Mehrwertdienst zu ersetzen. Daneben können Dienste gelöscht oder Dienste und lokale Komponenten neu verbunden werden. Falls sich ein neuer Dienst außerhalb der vorhandenen Peergruppe befindet, kann eine Mitgliedschaft beantragt werden. Die Ausführung dieser Methoden in einer sinnvollen Reihenfolge kann zum einen durch einen Projektverantwortlichen vordefiniert werden, was den Fachplaner später entlastet. Zum anderen kann die Reihenfolge aber auch offen gelassen werden, so dass der Fach-

Komponentenbasierte Plattform für anpassbare, vernetzte Systeme im Bauwesen

397

planer verantwortlich ist, die richtigen Routinen auszuführen. Dazu stehen entsprechende Tools zur Verfügung. Sämtliche Anpassungsmethoden strukturieren eine Komposition zur Laufzeit um, so dass die Wirkung unmittelbar zu sehen ist.

4.4 Das COBE AWARENESS FRAMEWORK Dieser Abschnitt gibt einen Überblick über das COBE AWARENESS FRAMEWORK, was dazu dient die Planungsaktivitäten der Fachplaner innerhalb einer vernetzten Kooperation zu koordinieren. 4.4.1 Allgemeines Konzept Das COBE AWARENESS FRAMEWORK realisiert ein dezentrales Modell zur Wahrnehmung (Awareness Modell) von synchronen und asynchronen Planungsaktivitäten innerhalb einer Gruppe von örtlich verteilten Fachplanern, die an einem gemeinsamen Fachmodell arbeiten. Die Wahrnehmung von Aktivitäten (engl. awareness (Dourish u. Bellotti 1992)) liefert Informationen über den Zustand und Fortschritt von gemeinsamen Tätigkeiten, die den jeweiligen Planern einen Kontext für weitere, eigene Aktivitäten bieten. Dieses Modell entspricht einem ereignisbasierten Modell, d.h. die Ausführung einer Aktivität löst ein Ereignis aus, welches zur weiteren Verarbeitung zur Verfügung steht. Im Gegensatz zum ursprünglichen Awareness Modell aus dem Bereich der CSCW (Computer Supported Cooperative Work), basiert der hier entwickelte Ansatz auf einem serverlosen Modell: Jeder Knoten (Peer) kann gleichberechtigt als Ereigniserzeuger sowie Ereignisempfänger fungieren. Dieses Modell entspricht eher den in Abschn. 4.4.2 identifizierten Gegebenheiten und Anforderungen einer verteilten Kooperation. Durch den generischen Framework-Ansatz können beliebige Anwendungen das Awareness-Framework verwenden, um Aktivitäten aus einer Anwendung heraus anderen Planern explizit zugänglich zu machen. Eine Anwendung kann dabei dem Framework über eine einfach gehaltene Schnittstelle und ohne hohen Programmieraufwand Informationen über Aktivitäten übermitteln und somit die Funktionalitäten des Frameworks benutzen. Um das Awareness-Framework einzusetzen, wurde ein Entwicklungsmodell konzipiert, welches konkrete Phasen zur Verwendung des Frameworks festlegt. Zunächst muss ein Anwender in der Entwurfsphase konkrete Planungsaktivitäten auf Ereignistypen abbilden. Typische Planungsaktivitäten, die mittels des Frameworks wahrgenommen werden können, sind beispielsweise das Öffnen, das Absichern oder die Änderung eines Fachmodells. Sämtliche Ereignistypen werden in einer XML-basierten Notation formuliert und in einer Datenbank persistent abgelegt. Auf Basis der so definierten Typen muss die Anwendung entsprechend erweitert werden, so dass zur Benutzungszeit der Applikation konkrete, zeitbezogene Ereignis-Instanzen gebildet und dem Framework zur weiteren Verarbeitung überreicht werden können. Viele kommerzielle Anwendungen, wie z.B. AutoCAD,

398

Armin B. Cremers, Sascha Alda

verfügen bereits über Ereigniskanäle, um Ereignisse über bestimmte Aktivitäten nach außen zu senden. Um auch solche Anwendungen mit dem COBE AWARENESS FRAMEWORK zu erweitern, muss der Anwender entsprechende Adapater- oder Bridge-Komponenten zur Verfügung stellen, welche die applikationsspezifischen Ereignisse in das für das Framework vorgeschriebene und somit allgemeinverständliches XML-Format konvertiert. In CoBE konnte mit Hilfe des COM2Java-Framework das CAD-System AutoCAD 2002 mit dem AwarenessFramework gekoppelt werden. Eine mit dem Framework erweiterte Applikation kann durch ein Advertisement innerhalb der Kooperation als Peer Service („AwarenessData“, in Abb. 4.5 von Peer A angeboten) veröffentlicht werden. Auf Basis dieses Advertisements können sich beliebige Benutzer als Empfänger (engl. subscriber) von Ereignissen in das Framework einschreiben. Voraussetzung ist dabei, dass Empfänger und Sender der gleichen Peer Gruppe angehören (ansonsten muss sich der Empfänger erst um eine Mitgliedschaft kümmern). Es ist des Weiteren möglich, sich nur für einen Teil der insgesamt wahrnehmbaren Aktivitäten einzuschreiben. Eine Liste aller Aktivitäten kann der Empfänger dabei aus dem Advertisement entnehmen.

modelliert

CIS/2 local data model

Ingenieur_A: Benutzer

Einschreibung benutzt

VarioCAD

AutoCAD

Ingenieur_B: Benutzer

Auslösung von Ereignissen

awareness channel Notifizierung über Ereignisse

Awareness Framework Ingenieur_C: Benutzer

DeEvolve Environment Subscriber Datenbank

Ereignis Historie

Abb. 4.9. Struktureller Aufbau des COBE AWARENESS FRAMEWORK

Zur Laufzeit der Applikation nimmt das Framework sämtliche aus Anwendungen produzierte Ereignisse entgegen (Abb. 4.9). Anschließend wird für jedes zeitbezogene Ereignis der entsprechende Ereignistyp ermittelt. Auf Basis des ermittelten Ereignistyps kann das Framework durch eine Anfrage an die lokale, auf jedem Peer vorhandene Benutzer-Datenbank feststellen, welche Benutzer sich à priori für die betreffende Planungsaktivität eingeschrieben haben. Die Benachrichtigung kann direkt auf dem Bildschirm der betreffenden Subscriber erfolgen (wahlweise per Dialog oder in einer Tabelle) oder per E-Mail, falls der Subscriber nicht online sein sollte. Der Produzent eines Ereignisses (Publisher) kann ein konkretes Ereignis mit zusätzlichen Informationen annotieren, teilweise werden diese auch automatisch aus dem jeweiligen Arbeitskontext extrahiert (z.B. der Name eines Trag-

Komponentenbasierte Plattform für anpassbare, vernetzte Systeme im Bauwesen

399

werkmodells). Sämtliche produzierten und empfangenen Ereignisse werden persistent in einer lokalen Ereignishistorie gespeichert, die einen globalen Überblick über zeitlich zurückliegende Planungsaktivitäten gibt. Eine solche Historie kann nützlich sein, um neu hinzugekommene Fachplaner in den bisherigen Verlauf der Planung zu integrieren. Jedem Benutzer des Frameworks steht eine Toolbar zur Verfügung, mit der man Einstellungen wie das Einschreiben für Planungsaktivitäten oder die Definition von Filtern (siehe 4.4.2) vornehmen kann. Einfache Ereignistypen können zu höherwertigen (aggregierten) Ereignistypen zusammengesetzt werden. Damit ist es möglich, die Verkettung (boolesche UNDVerknüpfung) oder aber auch die ODER-Verknüpfung von Ereignissen zu beschreiben. Bei der UND-Verknüpfung ist es zudem möglich, eine Zeitkonstante festzulegen, die vorgibt, in welchem Zeitraum die angegebenen Teil-Ereignisse emittiert werden sollen, so dass der aggregrierte Ereignistyp an den Benutzer weitergeleitet werden kann. Durch diese Art von Verkettung ist es möglich, das gleichzeitige Eintreffen von mehreren Ereignissen zu beschreiben. Ein Anwendungsbeispiel wäre für einen Projektleiter denkbar, der die parallele Bearbeitung eines partiellen Fachmodells durch eine Gruppe von Fachplanern observieren will. Durch das gleichzeitige Zustandekommen von einzelnen Ereignissen (z.B. resultierend durch das gleichzeitige Bearbeiten eines bestimmten Brückenelements) können somit potentielle Konflikte in der parallelen Planung erkannt werden. 4.4.2 Filterung von Ereignissen In einem Modell zur Wahrnehmung von Planungsaktivitäten ist die Filterung von Ereignissen ein wichtiges Mittel, um eine Vorselektierung von Ereignissen vorzunehmen. Eine derartige Vorauswahl schützt insbesondere die Privatsphäre des Ereigniserzeugers (Publisher). Ohne eine solche Filterung könnten zu viele nichtrelevante oder aber auch private Informationen über Modellierungsvorgänge an die Außenwelt gelangen und von dieser falsch interpretiert werden. Des Weiteren dienen Interessenfilter dazu, für einen Empfänger im Vorfeld uninteressante oder irrelevante Ereignisse herauszuselektieren bzw. diese vor einer Überflutung von Ereignissen zu bewahren. Globale Filter können kooperationsweite Filterungen z.B. zur Gewährleistung einer Cooperate-Identity durchführen. In einem dezentralen Kooperationsverbund gibt es, in Analogie zu dem eigentlichen Awareness-Modell, keine zentrale Instanz, auf der man Filter einstellen kann. Aus diesem Grunde wird in dem vorgeschlagenen Awareness-Modell die Filterung stets lokal auf einem Peer vorgenommen. Ein Benutzer kann Filter definieren und diese entweder lokal auf seinen Peer oder entfernt auf anderen Peers platzieren, um bereits eine Vorort-Filterung durchzuführen. Die Filter selektieren dann autonom im Auftrag der Endanwender die entsprechenden Ereignisse aus dem Ereignisstrom heraus. Der Autonomie-Gedanke sowie die Fähigkeit der Migration von Filtern waren mit dem bis dato betrachteten Komponenten- und Service-Ansatz nicht direkt realisierbar. Für die Realisierung solcher Filter können vorteilhaft Software-Agenten eingesetzt werden, da die Migration und insbesondere die Autonomie zu den we-

400

Armin B. Cremers, Sascha Alda

sentlichen Merkmalen von Agenten zählt. Die Realisierung einer Agentenplattform als Peer Service zum Einsatz von Filteragenten wurde in CoBE zunächst prototypisch realisiert (Brill 2004). Diese Entwicklung war der Anstoß zur Konzeptualisierung einer integrativen Plattform, welche die Konzepte des COBE AWARENESS FRAMEWORK mit den Ansätzen zur agenten-basierten WorkflowModellierung (Teilprojekte der Uni Bochum (Bilek u. Hartmann 2003) und TU Darmstadt (Theiß et al. 2004)) miteinander vereinigt. Eine aus der Zusammenarbeit mit der Uni Bochum resultierende Architektur wird im nächsten Abschnitt vorgestellt.

4.5 Integrative Architektur MAS-P2P Die integrative Architektur MAS-P2P vereinigt das COBE AWARENESS FRAMEWORK mit einem agentenbasierten Workflow-Modell zur ganzheitlichen Kontrolle und Zuteilung von Planungsaktivitäten (Alda et al. 2006). Das Workflow-Modell ist dabei als formales, ausführbares Prozessmodell modelliert, welches auf dem Formalismus der Petri-Netze basiert. Die vorgeschlagene integrative Architektur vereinigt die Stärken der beiden Ansätze zur Koordination von Planungsaktivitäten in einer vernetzten Kooperation. Aus Sicht des AwarenessModells werden zudem zwei bisherige Schwächen des Ansatzes umgangen:

x Das COBE AWARENESS FRAMEWORK ist ein Modell zur Koordination von Planern in einem Kooperationsverbund. Voraussetzung für den Einsatz des Awareness-Framework ist, dass ein Planungsverbund bereits existiert und die Planer untereinander vernetzt sind. Wann und unter welchen Gegebenheiten diese miteinander verbunden werden, bleibt ungeachtet. x Planer können entfernte Aktivitäten zwar wahrnehmen, jedoch obliegt ihnen ein gewisser Freiheitsgrad auf diese entsprechend zu reagieren. Häufig können auch Ereignisse durch den Empfänger ignoriert werden. Somit können etwaige Konfliktfälle potentiell unerkannt bleiben, obwohl Indikatoren durch das Awareness-Modell vorhanden sind. In der vorgeschlagenen MAS-P2P Architektur können sich neben realen Nutzern auch Software-Agenten (Persönliche Kooperations-Agenten) aus der Bochumer ACOS Agenten-Plattform als Empfänger für Ereignisse eintragen (s. Abb. 4.10). Persönliche Kooperations-Agenten assistieren Fachplanern während der Modellierung eines Fachmodells (z.B. durch Mechanismen zur Konsistenz- oder Transaktionskontrolle, Benachrichtigung an andere Agenten). Diesen Agenten können über einen Workflow-Agenten, der eine Workflow-Instanz eines konkreten Planungsablaufs kontrolliert und verwaltet, auszuführende Planungsaktivitäten zugewiesen werden.

Komponentenbasierte Plattform für anpassbare, vernetzte Systeme im Bauwesen

401

Petri-Netz (modelliert Planungsprozess) Workflow-Agent Ingenieur_B

überwacht Ingenieur_A

Veranlasst gegenseitige Einschreibung

competAgt_A

Aktivitäten sind abhängig von CIS/2 local data model

bearbeitet (entfernter Zugriff)

bearbeitet

Ingenieur_B: Benutzer

benutzt

VarioCAD

Ingenieur_A: Benutzer

AutoCAD

Notifizierung über Ereignisse Auslösung von Ereignissen aus Planungsaktivitäten

Awareness Framework DeEvolve Environment

bearbeitet (entfernter Zugriff) competAgt_A : Persönlicher KooperationsAgent

Abb. 4.10. Die MAS-P2P Architektur

Eine weitere Aufgabe des Workflow-Agenten in der MAS-P2P ist die Antizipierung potentieller Konflikte, die während der Planung auftreten. Eine Konfliktsituation entsteht, falls mehrere Fachplaner (oder persönliche KooperationsAgenten) innerhalb ihrer zugewiesenen Aktivitäten parallel an einem gemeinsamen Fachmodell modellieren, das von einem Fachplaner auf seinem Peer verwaltet wird. Der entfernte Zugriff auf Teile dieses Fachmodells kann von Seiten eines persönlichen Kooperationsagenten über einen lokalen Produktmodell-Agenten erfolgen (s. (Alda et al. 2006)). Ein Fachplaner kann über den „DocExchange“ Peer Service (Abschn. 4.3.3) auf das Fachmodell zugreifen. Eine solche Konfliktsituation bestehend aus drei Akteuren ist in dem Petri-Netz in Abb. 4.10 (oben rechts) dargestellt. In diesem Fall ist der Workflow-Agent verantwortlich, die entsprechenden Akteure (Planer A und B sowie Agent A) über das AwarenessFramework untereinander zu registrieren und somit zu verbinden. Somit können diese während der parallelen Bearbeitung des partiellen Modells Aktivitäten gegenseitig wahrnehmen und hierdurch auf entsprechende Konfliktfälle reagieren. Der Vorteil von persönlichen Kooperations-Agenten als Empfänger von Awareness-Ereignissen ist, dass diese autonom und unmittelbar auf bestimmte Ereignisse reagieren können. Der Nachteil des oben beschriebenen Freiheitsgrads eines menschlichen Akteurs wird behoben. Voraussetzungen für einen KooperationsAgenten sind interne Regeln und eine Wissensbasis, die zur Auswertung von Ereignissen sowie zur Ausführung von weiterführenden Aktionen dienen. Eine ausführliche Beschreibung der Konzeptualisierung sowie der teilprototypischen Implementierung der integrativen MAS-P2P Architektur sowie die

402

Armin B. Cremers, Sascha Alda

Darstellung beispielhafter Anwendungsszenarien können in (Alda et al. 2006) nachgelesen werden.

4.6 Zusammenfassung und Ausblick Dieser Bericht fasst die zentralen Ergebnisse des CoBE Projekts zusammen. Ziel des Projekts war die Entwicklung einer Software-Plattform zur Unterstützung der vernetzt-kooperativen Planung im Bereich des Konstruktiven Ingenieurbaus. Es wurde gezeigt, dass softwaretechnische Methoden aus der Komponententechnologie für die Entwicklung einer flexibel anpassbaren Plattform, zur Komposition von lokalen und entfernten Software-Applikationen sowie zur Integration von Standardsoftware geeignet sind. Die vorgeschlagene Plattform integriert zudem Konzepte aus zwei modernen Architekturstilen (SOA und P2P) zu dem Architekturstil der Service-orientierten Peer-to-Peer Architekturen. DEEVOLVE wurde als prototypische Implementierung dieses Stils vorgestellt. Das darauf basierende COBE AWARENESS FRAMEWORK realisiert ein dezentrales Modell zur Koordination von verteilt agierenden Fachplanern. Aufgrund der fokussierten Betrachtung des Projekts auf eine Formalisierung sowie einer Konzeptualisierung des Architekturstils sowie einer prototypischen Umsetzung der darauf basierenden DEEVOLVE Plattform, bleiben einige Fragen unbeantwortet. Zum einen muss untersucht werden, wie eine solche SoftwarePlattform mit den zugehörigen Diensten in einen realen Projektkontext eingeführt werden kann. Wie bei der Einführung von Software-Systemen in bestehende Organisationen bekannt ist, muss man auch hier mit Akzeptanz-Barrieren seitens der betroffenen Fachplaner rechnen. Notwendig ist daher die Adaptation bekannter Methoden zur Einführung der Software in einer (bestehenden) Gruppe von Fachplanern (z.B. ethnographische Methoden). Des Weiteren müssen softwareergonomische Richtlinien zur Entwicklung geeigneter Benutzeroberflächen z.B. für die Komposition und Anpassung von Applikationen abgeleitet werden. Obwohl eine Vielzahl von Tools entwickelt wurden, sind keine Richtlinien zur Gestaltung dieser Tools hergeleitet worden. Die ansprechende Gestaltung der Benutzeroberfläche von Tools kann die Akzeptanz der Plattform durchaus steigern.

Literatur Alda S (2005) Peer Group-Based Dependency Management in Service-Oriented Peer-toPeer Architectures. In: Proceedings des 3rd International Workshop On Databases, Information Systems and Peer-to-Peer Computing (DBISP2P), in Verbindung mit der 31st International Conference on Very Large Data Bases (VLDB), Trondheim, Norwegen Alda S, Bilek J, Cremers AB, Hartmann D (2006) Awareness and Workflow based Coordination of networked Co-operations in Structural Design. Journal of Information Tech-

Komponentenbasierte Plattform für anpassbare, vernetzte Systeme im Bauwesen

403

nology in Construction (ITCon), Special Issue Process Modelling, Process Management and Collaboration 11:489–507 Alda S, Cremers AB (2004) Towards Composition Management for Peer-to-Peer Architectures. In: Proceedings des Workshop Software Composition (SC 2004), zugeordnet zur 7th European Joint Conference on Theory and Practice of Software (ETAPS 2004), Barcelona, Spanien Alda S, Mitrov T (2004) Semantic Integrity Concepts for Service-Oriented Peer-to-Peer Architectures. In: Proceedings des Metadata Management in Grid and P2P Systems (MMGPS), London, England Bilek J, Hartmann D (2003) Development of an Agent-based Workbench supporting Collaborative Structural Design. In: Proceedings der 20th CIB W78 Conference on Information Technology in Construction, Auckland, Neuseeland Brill G (2004) Agentenbasierte Filter zur Unterstützung von dezentralen AwarenessSystemen. Diplomarbeit, Institut für Informatik III, Universität Bonn Dourish P, Bellotti V (1992) Awareness and Coordination in Shared Workspaces. In: Proceedings der 4th ACM Conference on CSCW, Toronto, Kanada Katzmarzik A (2003) Entwicklung eines Softwareagenten zur Visualisierung und Aufbereitung von geometrischen und topologischen Daten aus einem CAD-System. Diplomarbeit, Lehrstuhl für Ingenieurinformatik im Bauwesen, Universität Bochum Mitrov T (2003) A Peer-to-Peer Environment for Component-Based, Tailorable Groupware Applications. Diplomarbeit, Institut für Informatik III, Universität Bonn Palij A (2006) Selbstanpassbare Umgebung für P2P-Architekturen zur Behandlung von Laufzeitfehlern. Diplomarbeit, Institut für Informatik III, Universität Bonn Stiemerling, O (2000) Component-Based Tailorability. Dissertation, Institut für Informatik III, Universität Bonn Sun (2005) JXTA v2.0 Protocols Specification (Revision 2.3.5) Szyperski C, Gruntz D, Murer S (2002) Component Software - Beyond Object-Oriented Programming. Addison-Wesley, London Theiß M, Meissner U, Rüppel, U (2004) Network-Based Fire Engineering Supported by Agents. In: Proceedings der 10th International Conference on Computing in Civil and Building Engineering (ICCCBE-X), Weimar Won M (2004) Interaktive Integritätsprüfung für komponentenbasierte Architekturen. Technische Unterstützung für Endanwender beim Anpassen komponentenbasierter Software. Dissertation, Institut für Informatik III, Universität Bonn

Sachverzeichnis

4 4D-CAD 315 A Ablaufplanung 100 Abstimmungsprozess 202 ACID-Transaktion 128 ACOS 368 adaptives Assoziationsnetz 326 Adaptivität 302 Ad-hoc-Reaktion 25 Advanced Visual Systems (AVS) 247 Agent 253, 323, 400 Agent Unified Modeling Language (AUML) 331, 372 Agentenarchitektur 369 agentenbasierte Analyse 331 agentenbasierter Ansatz 274 agentenbasierter Modellverbund 337 agentenbasiertes Kooperationsmodell 361 agentenbasiertes Modell zur Integration von Fachwissen 361 agentenbasiertes Modell zur Prozessunterstützung 361 agentenbasiertes Modell zur Softwareintegration 361 agentenbasiertes Produktmodell 361 Agentenkommunikationssprache 332

Agentenmodell für die vernetztkooperative Tragwerksplanung 360 Agentenmodellierung 331 Agentenparadigma 330 Agentenplattform 253, 331, 353 Agentensystem 5, 323 Agententechnologie 253, 323, 331 Aktivität 34, 63 analytische Simulation 244 Anforderungsmodell 106 Ankerelement 277 Anlagensteuerung 290 Anordnungsbeziehung 111 Antwortfläche 260 Arbeitsmodell 326 asynchrone Kooperation 127 asynchron-sequentielle Kooperation 7 Attributregel 168 Aufbauorganisation 107 Aufgabenmanagement 106 Aufgabenträger 358 Ausführungsprozess 61 Ausnahmebehandlung 394 Ausnahmeerkennung 395 Ausnahmefall 53 Ausnahmefallbehandlung 56 AutoCAD 247 Autodesk 194, 274 Autodesk Architectural Desktop 277 autonome Software-Einheit 326 Autonomie 253 autonomous computing 327

406

Sachverzeichnis

AVS/EXPRESS 279 Awareness 397 B Backus-Naur-Form (BNF) 145 Balkenplan 99 baulicher Brandschutz 337 Bauobjekt 62 Bauphasensimulation 298, 315 Bauplan 278 Bauplanungsprozess 81, 133 Bauprozess 83 bauteilspezifisches Prozessmuster 86 Bauwerk 129 Bauwerksinstanz 129 Bauwerksmodell 129, 197, 297 Bauwerksmodellierung 129 Bauwerksplanung 36 Behaglichkeit 285 Bemessung 303 Benachrichtigungsdienst 298, 307 Benutzungsoberfläche 180 Beziehungsgeflecht 325 Bindung 138 bipartiter gerichteter Graph 81 Blackboard-basierter Ansatz 221 bocad 194 Bottom-Up-Ansatz 157 Brandschutz-Agent 348 Brandschutzmodell 340 Brep-Modell 284 Building Information Model (BIM) 197 C CAD-Hochleistungssystem 182 CAD-Wrapper-Agent 375 CFD-Simulation 277 CIMSteel Integration Standard 363 Client-Server Architektur 224 Cluster 245 COBE Awareness Framework 383, 397 Collaboration-Server 192

COM2Java Bridge-Komponente 391 Common Component Architecture (CCA) 243 Computational Steering 247, 275 Computer Aided Design (CAD) 244, 274 Computer Supported Cooperative Work (CSCW) 8, 248, 358 COM-Schnittstelle 286 Content-Management-System 194 CORBA 242 D Data Item Hierarchy 223, 228 Datenaustausch 277 Datenbank-Wrapper-Agent 375 Datenkonsistenz 205 DEEVOLVE 384, 390, 402 deklarativ 219, 235, 236, 342 Design of Experiments (DOE) 260 Detailnetz 92 digitaler Interessenvertreter 14 distributed simulation 242 Dokumentenmanagement 59 Dokument-Management-System 8 dreidimensionaler Berechnungsansatz 275 Drei-Ebenen-Ansatz 360 dünnwandige Strukturen 302 E Einbettung von Simulationsaufgaben 309 Eingangsparameter 259 emergentes System 333 Entity Relationship Model (ERM) 104 Entscheidung 39 Entscheidungsprozess 110 Entwurfsfehler 155 Entwurfsmuster 123 Entwurfsphase 156 Ereignis 64 ereignisbasierte Simulation 243

Sachverzeichnis

ereignisgesteuerte Prozessketten 80 Erreichbarkeitsanalyse 85, 89 Ersatzmodell 260 Evaluierung 156 Event 256 evolutionäre Entwicklung 324 Expertensystem 333 EXPRESS 123, 128 Extensible Markup Language (XML) 283 F Facettenmodell 284 Fachdomäne 94 Fachdomänen-Agent 367 Fachmodell 66, 273, 339 Fachontologie 159, 336 fachspezifisches Prozessmodell 86 Fachwissen 128 Fakt 348 farbiges Petri-Netz 82 Feature 144 Feature-Logic 143 Filteragent 400 Finite-Elemente-Methode (FEM) 248, 302 Finite-Element-Wrapper-Agent 375 FLEXIBEAN 389 formale Prozessanalyse 84 formale Prozessmodellierung 94 formale Semantik 167 Fortschreibung 38 Foundation for Intelligent Physical Agents (FIPA) 331, 344 Freigabe 186 Freigabestand 130 Fuzzy-Modelle 220, 229 G Gallileo-Hochhaus 92, 94 Gebäudemodell 339 Gebäudestruktur 36 Geotechnik 75, 94 geotechnische Beobachtungsmethode 57

407

geotechnische Kategorie 93 Gesamtmodell 199 Gesamtsystem 296 gewerkeübergreifend 220 Gittergenerator 284 globales ProzessManagementsystem 77 Grammatik 145 Graphersetzungssystem 157 Graphgrammatik 170 GRID 245 Groupwareplattform 112 H Haustechnik 220, 222, 233 Havariefall 53 Havariekonzept 56 heterogene Bauprojektorganisation 6 hierarchischer bipartiter Graph 25 hierarchisches Graphensystem 24 hierarchisches Petri-Netz 86, 94 High-Level-Architecture (HLA) 242 höheres Petri-Netz 82, 374 Human Orientation 324 HVAC 247 HVAC Agenten Framework 280 HVAC-System 274 Hybridisierung 358 I IfcPropertySet 282 individuelle Marke 82, 84, 93 Industry Foundation Classes (IFC) 123, 128, 206, 245, 274, 298, 339 Inferenzmaschine 348 Inferenzmechanismus 220 Informationsmanagement 59 Informationsmanagementsystem 59 Informationsmodell 60, 108 Informationsplattform 58 Informations-Transport-Agent 346 Ingenieurinformatik 326

408

Sachverzeichnis

ingenieurspezifischer Softwareagent 360 Insellösung 358 integrale Planung 97 Integration 336 Integratives Kooperationsmodell 13 Integritätsbedingungen 394 Interaktionsprotokoll 332, 345 interaktive Simulationsumgebung 275 interCAD 134 ISO 10303 363 J Java Agent Development Framework (JADE) 242, 377 Jess 348 JXTA 390 K Kardinalitätsregel 168 Kennlinie 286 Klimakomfort 286 Klimaoptimierung 248 Kollaborationsumgebung 252 Kollisionserkennung 298, 300, 305 kombinierte Pfahl-Plattengründung 79 Kommunikation 7, 60, 253, 273 Kommunikations- und Koordinationsmechanismus 368 Kommunikationskalkül 333 Kommunikationsschnittstelle 344 Kommunikationsverbund 5 komplexe Tragwirkung 296 komponentenbasierte Anpassungsmethoden 396 Konfliktbehandlung 401 Konfliktmanagement 139 konsistente Prozessmodellierung 83, 94 Konsistenz 66, 122, 127, 134, 156 Konsistenz und Korrektheit 42 Konsistenz zwischen Teilmodellen 395

Konsistenzanalyse 159, 161 Konsistenzbedingung 170 Konsistenzsicherung 224, 235 Konstruktiver Ingenieurbau 75 konstruktiver Tiefbau 53 konzeptueller Gebäudeentwurf 122, 155 Kooperation 53, 122, 127, 253, 335 Kooperationsmatrix 124, 126, 134 Kooperationsmodell 102, 198 Kooperationsmodell Geotechnik 75, 87 Kooperationspartner 189 Kooperationsplattform 58 Kooperationsszenario 203 Kooperationsumgebung 205 kooperative Gebäudeplanung 335 kooperativer Tragwerkplanungsprozess 358 Koordination 7 Koordinationspunkt 189, 198 Kriging-Methode 260 Künstliche Intelligenz 324 L lange Transaktion 128, 139 Lattice-Boltzmann 279 Laufzeitsteuerung 84, 93 Leitbilder 184 Lernfähigkeit 253 logische Fuzzy-Modelle 229 M Mapping 199 Mappingmuster 200 Mappingspezifikation 200 Marken 77, 82 Markenkonzept 81, 85 MAS-P2P 400 Massivbau 219, 220, 237 Matching 201 Mehrebenenproblem 325 Mehr-Schichten-Architektur 331 Meilenstein 107 Meilensteinplan 109

Sachverzeichnis

Mengenalgebra 122, 136 Merging 202 Mess-, Steuer- und Regelungstechnik (MSRTechnik) 274 Message Passing Interface (MPI) 243, 279 Messsensor 278 Metainformation 26, 76, 77 Metamodell-Architektur 129 mobile Verarbeitungsmethoden 336 mobiler Agent 346 Mobilität 253 modellbasiert 335 Modellharmonisierung 203 Modellmanagement 66 Modelltransfer 280 Modelltransformation 199 Modellverbund 203, 338 Modellvergleich 201 Modellzusammenführung 202 Monitoragent 256 Monitoring 57 Multiagentensystem 253, 323, 336, 343 Multiagentensystem für die Tragwerksplanung 368 Multi-User-Umgebung 289 N Nachtrag 41 Nachweisführung 223, 228 nested dissection 312 Netzgenerierung 300 Netzplan 63, 99 Netzplantechnik 24, 26 netzwerkfähiges Kooperationsmodell 4 netzwerkgerechte Kooperationsplattform 94 netzwerkgerechte Prozessmodellierung 5, 21 Neuberechnung nach Modifikation 313 Normalisierung 210

409

Numerische Simulation 243, 274 O Oberflächenmodell 284 Object Modeling Framework (OMF) 277 ObjectARX 277 Objektorientierung 127, 221 Objektpaar 201 Objektschlüssel 201 Objektstatus 188 Objektversion 137 Oktalbaum 248, 284, 297, 304, 308 Ontologie 59, 61, 332, 337 operations research 85 Optimierungsprozess 274 Organisationsmodell 107 Organisationsstruktur 35, 55 P paralleles Arbeiten 127 Parallelrechner 275 parametrischer Ansatz 159 Partialproduktmodell 121 PC-Cluster 275 Peer Service 384 PeerCAT 390 persönlicher Kooperations-Agent 362 Petri Net Markup Language (PNML) 77, 373 Petri-Netz 24, 77, 94, 358 Petri-Netz-basierte Prozessmodellierung 26 Phasengliederung 109 PID-Regler 287 Planungsakteur 36 Planungsaktivität 83 Planungsphase 198, 273 Planungsprozess 60, 81, 178 Planungsressource 83 planungsspezifisches Prozessmuster 86 Planungsstatus 227, 229 Planungsvorgang 38

410

Sachverzeichnis

Planungszustand 83 Präferenzfunktion 263 Predicted Mean Vote (PMV)-Index 285 Pre-Processor 284 Pro-Aktivität 253 Problemdekomposition 343, 361 Problemlösungszyklus 112 Produkt 129 Produkt-Daten-Modell 226 Produktinstanz 129 Produktmodell 66, 84, 121, 129, 134, 182, 219, 222, 245, 247, 274, 363 Produktmodellagent 257, 362 Produktmodellintegration 363 PROGRES 157 Projekt 139 Projekt-Agent 362 Projektkommunikationssystem 8 Projektmanagementsystem 100 Projektmodell 102 Projektserver 221, 225, 226, 231 Projektstrukturplan 99 PropertySet 278 Protégé 351 Proxyagent 254 Prozess 12, 63, 111 Prozessanalyse 22, 78, 89 Prozessbeschreibung 77 Prozess-Daten-Modell 222 Prozesslogik 112 Prozessmanagement 113 Prozess-Managementsystem 75 Prozessmodell 22, 34, 77, 84, 94, 107 Prozessmodellierung 22, 94, 359 Prozessmuster 86, 92 Prozessnetz 92 prozessrelevante Metainformation 91, 93, 94 Prozesssimulation 86 Prozesssteuerung 22, 81, 84, 90 Prozesssteuerungsumgebung 94 Prozessstruktur 34

Q Qualitätssicherung 57 Qualitätsverlust 263 Quelldatenmodell 200 R Rahmenprozess 107, 111 Raumbezug 308 Raumlufttechnik 220, 222, 226, 233 Raumplanung 36 Reaktivität 253 Redundanz 66 Referenz 146 Referenzimplementierung 94 Regel 348 Regelabhängigkeiten 169 regelbasiertes Schlussfolgerungssystem 347 Regelbasis 348 Regelkreis 276 Regelmodell 337, 342 Regelserver 352 Regelsteuerung 276 Regelungstechniker 287 Regelverarbeitung 337 Regelwerke 287 Regulierung von Zugriffen 307 Reintegration 199 relationale Datenbank 147 Relationsregel 168 Repository 145 Ressourcen-Ebene 360 Ressourcenmanagementsystem 61 Ressourcenplanung 43 Revisionsstand 130, 189 S Sandbox 145 Schlüsselinformation 54 Schlussfolgerungssystem 342, 348 Selektion 139, 144 semantische Kennzeichnung 61 semantisches Bereichsobjekt 164 semantisches Entwurfsmodul 161

Sachverzeichnis

semantisches Raumobjekt 164 Sensitivitätsanalyse 228, 229, 246, 259 Separation of Duties 365 sequentielles Arbeiten 127 Service Komposition 390 Service-Kontrakt 394 Service-orientierte Peer-to-Peer Architektur 390 Sicherung der Konsistenz 296 Sinnbild 183 Software Engineering 323 Softwareagent 253, 323, 336, 338 Softwareprototyp 112 Software-Wrapping 254, 330, 359 Soundness-Kriterium 85, 89 Spezialtiefbau 53 Sprechakt 345 sprechaktbasierte Kommunikation 332 standardisiertes Bauwerksmodell 298 Statusinformation 188 Statuswechsel 112 Stellennetz 82 STEP 128 Strömungssimulation 247 Struktursimulation 311 Subview 208 symbolische Wissensverarbeitung 333 synchrone Kooperation 127 synchrone parallele Kooperation 7 synchron-wechselseitige Kooperation 7, 131 Systemarchitektur 122, 145 Systementwurf 145 Szenario 125 T taktische Ziele 106 Teammanagement 107 teamorientiertes Projektmanagement 100 Teildatensatz 199

411

Teildatensatzanfrage 204 Teildatensatzbeschreibung 199 Teildatensatzbildung 199 Teilmenge 139 Teilmengenbildung 128 Teilmodell 146 Teilproduktmodell 337 Tekla 194 Terminplanung 44 Top-Down-Ansatz 157 topologische Struktur 299 Tragwerksmodellierung 393 Tragwerksplanung 220, 222, 233, 237, 247, 357 Transition 35 Transitionsnetz 82 transitive Hülle 138 Trendanalyse 264 U Überwachungswerkzeug 277 Ubiquität 324 UCD Dateiformat 284 Unified Modeling Language (UML) 123 V Variante 39 vereinheitlichte Systemarchitektur 129 vernetzte Kooperation 3 vernetzte Kooperationsumgebung 87 vernetzt-kooperativ 178 vernetzt-kooperative Ingenieurplanung 7 vernetzt-kooperative Tragwerksplanung 358 vernetzt-kooperativer Planungsprozess 4 Version 41 Versionierung 122, 130, 134, 147 Versionsverwaltung 147, 205 Versuchsraum 260 verteilte Bearbeitung 134

412

Sachverzeichnis

verteilte Modellierung 86 verteilte Produktmodelle 5 verteilte Prozessmodellierung 86 verteilte Simulation 5, 241 verteilte Wissensbank 131 verteiltes Produktmodell 122, 124, 127, 134, 337 verteiltes Softwaresystem 325 Vertragsmodell 59 virtual reality 247, 275 VISIT 247, 284 Visualisierung 275 visuelle Sprache 167 volumenbasierte numerische Analyse 279 Volumenmodellierung 297, 303 volumenorientierte Modellierung 247 Vorschlag-Zustimmungszyklus 202 Voxel-Modell 284 W Wahrnehmung von Planungsaktivitäten 399 Web Service 88

wechselseitiges Arbeiten 127 Wissensbank 123, 127, 220, 223 wissensbasiert 219 wissensbasierter Ansatz 123 Wissensformalisierung 159 Wissensingenieur 159 Wissensmodellierung 130 Wissensrepräsentation 220, 221, 235 Wissensverarbeitung 122, 129, 333 Workflow-Agent 364 Workflow-Eigenschaft 89 Workflow-Engine 364 Workflow-Management 9, 82, 255 Workspace 139 Wrapper-Agent 344, 366 Wrapping 344 Z Zeitplanung 42 Zielcontrolling 106 Zieldatenmodell 200 Zielkonflikt 110 Zielsystem 106