Koch, V.

Paul, N.

Pfeifer, D.

KITopen

Unterstützung der integrierten Gebäudeplanung und –Verwaltung mit einem topologischen Kerndatenmodell1  Norbert Paul, Daniel Pfeifer(*), Jutta Mülle (*), Volker Koch  Universität Karlsruhe, Germany Institut für Industrielle Bauproduktion (ifib) (*)Institut für Programmstrukturen und Datenorganisation (IPD) { volker.koch, norbert.paul }@ifib.uni-karlsruhe.de { muelle, pfeifer }@ipd.uni-karlsruhe.de 1. Einführung  Gebäude sind komplexe Unikate und werden in verschiedenen Planungsstufen und Betriebsphasen vorwiegend konstruktionsorientiert und damit im Hinblick auf Anforderungen unvollständig in Teilmodellen beschrieben. Die Modellierung über den Lebenszyklus hinweg ist weder chronologisch noch fachübergreifend konsistent und umfassend. Dieser Umstand führt zu einem hohem Mehraufwand der Planungsbeteiligten, und zu inkonsistenten Daten. Die International Alliance for Interoperability (IAI) unternimmt mit der Entwicklung der Industry Foundation Classes [4] den Versuch diese Teilmodelle zu integrieren. Der Fokus liegt hier bei Schnittstellen zum Austausch von Daten, deren integrierte Verarbeitung spielt aber nur eine untergeordnete Rolle. Im vorliegenden Beitrag wird der Versuch beschrieben, auf Basis eines topologischen Ansatzes der Gebäudemodellierung einer umfassenden Gebäudemodellierung neue Impulse zu geben.   2. Konzepte zur Datenintegration  Eine Vielzahl von wichtigen Eigenschaften eines Gebäudes sind von seiner konkreten geometrischen Form unabhängig und bleiben unverändert, wenn man es sich so deformiert vorstellt, als würde es aus einer beliebig elastischen Substanz bestehen, wobei an keiner Stelle ein Teil entfernt, eingefügt, getrennt (zerrissen) oder verklebt wird. Diese Eigenschaften heißen topologisch. Im Verlauf dieses Projektes wurde untersucht, welche dieser Eigenschaften für die Planung und den Betrieb von Gebäuden interessant sind.  Es gibt sehr vielfältige Anforderungen an die Topologie von Gebäuden. Zum Beispiel sollte die Existenz eines „gefangenen Zimmers“ vermieden werden, bestimmte Bereiche von Gebäuden müssen voneinander getrennt bleiben, andere wiederum sollen zusammenhängen, weil intensive Kommunikation stattfindet. Zudem gibt es auch weit komplexere Anforderungen an topologische Eigenschaften von Gebäuden. So ist ein Fluchtweg nur möglich2, wenn alle Räume erschlossen sind, alle Türen in Fluchtrichtung zu öffnen sind und die Umgrenzung des Fluchtweges ausreichend Feuerwiderstand hat. Dieser Beitrag zeigt an einem Teil der Topologie architektonischer Räume, dem Volumen-adjazenzgraphen (VAG) [2], wie topologisches Modellieren Anwendungen der Bauplanung integrieren kann, und somit eine interessante Basis für eine integrierte Planungsplattform bildet. Für viele topologische Eigenschaften ist jedoch eine Modellierung als Graph nicht ausreichend. Dazu sind reichaltigere Strukturen notwendig, die als Komplexe [5] bezeichnet werden.                                                  1 Die Arbeit wird gefördert im Rahmen des DFG-Projektes „Dynamische Gebäude“ Ko1488/3-1. 2 Diese Anorderung ist natürlich noch nicht hinreichend. 3. Systemarchitektur  Ein wichtiges Mittel zur Realisierung des integrativen Architekturansatzes ist die Nutzung eines gemeinsamen Datenbestandes. Für die verschiedenen Anwendungen bleiben die anwendungsspezifischen Daten gemäß dem jeweiligen Partialmodell im Einsatz. Die Integration erfolgt über die Modellierung der topologischen Relationen in einem Gebäude und in Form externer Referenzen. Da die gemeinsamen Daten auch über Jahrzehnte hinweg zugänglich und änderbar sein müssen, werden sie in einem relationalen Datenbanksystem dauerhaft gehalten. Ausführungs- und Datenhaltungsaspekte sind durch einen klassischen Schichtenansatz von einander getrennt.   Abbildung 1: Grobarchitektur eines Systems zur integrierten Gebäudeplanung  Abbildung 1 stellt die Gesamtarchitektur des Systems graphisch dar, wobei grob die folgenden vier Schichten unterschieden werden:  Die oberste Schicht repräsentiert die verschiedenen graphischen Anwendungsklienten. Mit dem Anforderungsmanager werden Anforderungen aus relativ frühen Planungsphasen eines Gebäudes erfasst. Ausgehend vom Raumprogramm können Anforderungen, die formal gut handhabbar sind, in einfacher Weise vom Anwender eingegeben werden. Zum Beispiel  kann man Räume zu Raumgruppen zusammenzufassen oder die gewünschte Distanz zu Nachbarräumen festlegen. In der Zeichnungsphase erscheinen angeforderte Räume dann als Markierungen, die vom Planer in der Grundrisszeichnung freizügig verschoben werden können, um die angeforderten Räume mit gezeichneten Räumen zu assoziieren.  Mit Hilfe des Anforderungsprüfers kann getestet werden, wie gut CAD-Zeichnungen bzw. die daraus resultierenden topologischen Eigenschaften mit den gestellten Anforderungen zusammenpassen. Dabei können viele komplexe Anforderungen an Gebäude formal als Eigenschaften des VAG definiert und mit den Standard-Algorithmen aus der Graphentheorie überprüft werden.   Die zweite Schicht behandelt die im Zusammenhang des Projekts implementierte Anwendungslogik. Einen wichtigen Aspekt bildet dabei die Ermittlung der Topologie des Gebäudes. Durch Verkleben [5] der Grundrisse werden die dreidimensionalen topologischen Relationen korrekt dargestellt, Volumenadjazenz und der Zusammenhang von angeforderten und realisierten Räumen in einer Datenbank gespeichert. Eigenschaften der Räume und ihrer Verbindungen (z.B. Flächeninhalt, Material, Durchlässigkeit) die nicht topologisch sind, werden als Kanten- und Knotengewichte des VAG mit ausgegeben. Derartige Gewichte sind z.B. auch Verweise auf die Einträge in der Materialdatenbank von LEGOE [6].   Die dritte Schicht repräsentiert bereits existierende Basisanwendungen und Werkzeuge.  Das verwendete objekt-relationale Abbildungswerkzeug [8] bildet Tabellen-Strukturen der zugrunde liegenden Datenbank (MySQL) auf Klassen bzw. Objekte aus der Welt der Programmiersprache Java ab. So können die Vorteile der objekt-orientierten Programmierung und der relationalen Datenbanken kombiniert werden. Durch die Topologiefunktionen und die Datenbankschnittstelle des Geoinformationssystems Autodesk Map [1] werden topologische Eigenschaften des Gebäudes aus den Grundrisszeichnungen und Höhenentwicklungen ermittelt.   Die unterste Schicht in Abbildung 1 repräsentiert persistente Daten, die Informationen aus allen Bereichen des Gebäudelebenszyklus enthalten.  Die Material-Datenbank und die Zeichnungsdokumente stellen dabei Artefakte dar, die aus bereits existierenden kommerziellen Anwendungen entstehen. Die integrierte Gebäude Datenbank nimmt weitere Daten auf, die für den gesamten Gebäudelebenszyklus relevant sind. Entsprechende inhaltliche Bereiche sind nach Modulen untergliedert.   4. Das Zusammenspiel der Systemkomponenten im Kontext der Anforderungsprüfung  Die Anforderungsprüfung wurde als Beispiel gewählt, weil sie an der Schnittstelle zwischen komplexen Anforderungen an ein Gebäude und dem eigentlichen Gebäudebestand liegt. In der heutigen Planungspraxis sind die Anforderungen in vielen verschiedenen Formen (Regeln, Tabellen etc.) dargestellt. Der Entwurf seinerseits erfolgt teilweise durch Handskizzen, teilweise direkt in ausschliesslich geometrieorientierten CAD Systemen. Die Verknüpfung von Anforderungen und Entwurf  ist von großer Bedeutung für den ganzen Lebenszyklus des Gebäudes.  Wie bereits erwähnt, ermöglicht es der Anforderungsprüfer, Anforderungsdaten, die mit Hilfe des Anforderungsmanagers erzeugt werden können, gegenüber den Topologiedaten eines konkreten Gebäudeplans zu prüfen.  Um die Validierung von gespeicherten Anforderungsdaten zu ermöglichen, werden die Topologie-Daten in der besprochenen relationalen Datenbank gespeichert. Mit Hilfe der Topologiefunktionen von AutoCad Map, können dabei Beziehungen zwischen angeforderten Räumen und gezeichneten Räumen visuell durch ziehen und klicken (Drag and Drop) hergestellt werden. Auf diese Weise werden alle für die Prüfung benötigten Zusammenhänge zwischen Räumen und Anforderungen hergestellt und sowohl die entsprechenden Beziehungsdaten als auch die berechnete Topologie selbst werden über AutoCad in der relationalen Datenbank abgespeichert.  Der Anforderungsprüfer liest die Anforderungsdaten aus und bildet wichtige Aspekte daraus auf Knoten und Kantenobjekte eines Anforderungsgraphen ab. Der Anwender kann das Auslesen und Abbilden der entsprechenden Daten für das jeweilige Gebäude-Projekt über die grafische Benutzeroberfläche des Anforderungsprüfers veranlassen. Analog kann der Anwender die berechneten und gespeicherten Topologie-Daten einer Version einer Gebäude-CAD-Zeichnung auswählen und vom System in einen Graphen (den VAG) überführen lassen. Auf den so entstandenen Graphen können nun mit hierfür angepaßten Graphenalgorithmen die Gebäudeanforderungen validiert werden. Abbildung 2 stellt die entsprechenden Interaktionsprozess als Prozessdiagramm schematisch dar. Anfordeungs-managerBerechneteTopologie-DatenAutoCad-Toplolgie-erweiterungCAD-ZeichnungAnforderungs-prüferAnforderungs-datenPrüfungs-berichte Abbildung 2: Interaktion der Systemkomponenten bei eine Anforderungsprüfung als Prozeßdiagramm  6. Anwendungsbeispiel: Planung der Sporthalle einer Grundschule  Für das Beispiel der Planung einer Grundschule aus [3] soll das Zusammenspiel von CAD-System, Anforderungsmanager und Anforderungsprüfer veranschaulicht werden. Hierzu wurde die Anforderungsbeschreibung zur Planung der Grundschulsporthalle aus [3] ausgewählt. Abbildung 3 zeigt eine Beispielzeichnung für die Realisierung einer entsprechenden Sporthalle.  HalleGeräteLehrer 2Lehrer 3Lehrer 1WC 1WC 2GarderobeundDusche 1Korridor 1Korridor 2Eingangs-bereichGarderobeundDusche 2 Abbildung 3: Vereinfachter Grundriß einer Schulsporthalle  Für die Darstellung der Topologie im Anforderungsprüfer kann der Anwender auswählen, welche Beziehungen zwischen gezeichneten Räumen dargestellt werden sollen. So ist beispielsweise eine getrennte Betrachtung all der Flächen zwischen Räumen möglich, die begehbar sind. Abbildung 4 zeigt den vom System berechneten Volumenadjazenzgraphen der Schulsporthalle unter Berücksichtigung der Begehbarkeit.  Neben der graphischen Darstellung der umgesetzten Topologie ermöglicht der Anforderungsprüfer die Ausgabe von Berichten. Diese Berichte können zum einen Informationen über die Erfüllung der im Anforderungsmanager eingegebenen Anforderungen behandeln. Zum anderen können weitere Bedingungen mit einfließen, die berücksichtigt werden müssen, wie beispielsweise die Einhaltung von Fluchtwegebestimmungen. Abbildung 5 zeigt das Berichtsfenster mit Ausschnitten eines Berichts über Flächenanforderungen für das Beispiel der Schulsporthalle. Dabei wird die Grundfläche des gezeichneten Raumes dahingehend überprüft, ob sie in dem Bereich liegt, der für den zugehörigen geplanten Raum in den Anforderungsmanager eingegeben wurde. Weitere implementierte Tests sind die Überprüfung auf zwei unabhängige Fluchtwege, d.h. begehbare Wege zum Außenraum und die Einhaltung der Nachbarschaftsbeziehungen zwischen angeforderten Räumen.     Abbildung 4: Die durch das System berechnete Topologie der Schulsporthalle    Abbildung 5: Berichtfenster des Anforderungsprüfers nach Überprüfung der Flächeanforderungen bzgl. der Schulsporthalle  7. Zusammenfassung und Ausblick  Unsere Ausgangsthese ist, dass die verschiedenen Zustände, die ein Gebäude im Laufe seines Lebenszyklus einnimmt, auf der Basis eines topologischen Modells in Zusammenhang gebracht werden können und hierdurch eine Integration erreicht wird. Wir haben ein topologisches Modell eingeführt, das Volumenadjazenz als wichtigen Teil der topologischen Eigenschaften von architektonischen Räumen erfasst. Darauf aufbauend wurde eine Plattform entwickelt, die Anwendungen aus den verschiedenen Bereichen als Beispiel integriert. Die verteilte Plattform basiert auf einem integrativen Systemarchitekturansatz mit einer verteilten Datenhaltung mit dem klassischen Schichtenansatz, der Ausführungs- und Datenhaltungsebene trennt. Am Beispiel der Anforderungsprüfung für den Grundriß einer Schulsporthalle wurde die Anwendbarkeit des Ansatzes illustriert und belegt. Die Arbeiten sind eingebettet in ein Projekt, in dem die dynamischen Aspekte eines Gebäudes betrachtet werden. Das hier vorgestellte Modell zeigt, dass Topologie die Raum-Bauteil-Beziehungen korrekt darstellt und diese Informationen in einem einheitlichen Modell integrieren kann. Bei darüber hinausgehenden topologischen Eigenschaften reicht die Verwendung von Graphen nicht mehr aus, sondern es muss mit allgemeineren Komplexen gearbeitet werden. Daher wird in einer weiteren Arbeit [9] der Ansatz für ein derartiges erweitertes Modell vorgestellt, um dem fast alle planungsrelevanten topologischen Eigenschaften von Gebäuden als integrierte Datenbasis zur Verfügung zu stellen3, und sogar eine Betrachtung des Gebäudelebenszyklus und somit der dynamischen Aspekte der Gebäudeplanung ermöglicht.  Damit sind eine automatisierte Beurteilung von Gebäudeentwürfen oder Entscheidungen in der Bewirtschaftung und sogar ganze Regelbibliotheken für Planungsdomänen (Krankenhaus- und Flughafenbau) denkbar.              Literaturverzeichnis  1. Autdesk Map, http://usa.autodesk.com/adsk/section/0,,2260583-123112,00.html 2. Delpy T.; Zeitouni K.: A Graph Model to Describe Topological Relationships in a 3D World; Third International Conference on Computers in Urban Planning and Urban Management, Atlanta, USA, 1993, Klosterman (Ed.), p 151-166. zitiert nach: de-Cambray B, Delpy T., Zeitouni K., o.J., A Survey on 3D Data Models in Architecture and Civil Engineering, http://citeseer.nj.nec.com/163073.html 3. Gemeindverwaltung Kirchberg, Bausekretariat (2001). Projektentwicklung Schulanlage Brunnenmoos. Anforderungsbericht der Gemeinde Kirchberg zur Erlangung enes Entwicklungskonzeptes für die Erweiterung einer Schulanlage 4. Industry Foundation Classes (IFC), http://www.iai-na.org/technical/documents.php 5. Jänich K.: Topologie; Springer 1990  6. LEGOE, http://www.legoe.de/ 7. Mülle, J.A.; Nimis, J.; Lockemann, P. C.; Hermann, M.; Schloeßer, D.; Kohler, N.: A Framework for Dealing with Dynamic Objects. In: Proceedings of the European Conference on Product and Process Modelling, ECPPM, Elsevier, 2000, pp. 49-62 8. Object Relational Bridge – Jakarta Project, http://jakarta.apache.org/ojb/ 9. Paul, N.; Bradley, P.E.; Topological Houses, geplante Veröffentlichung auf IKM 2003, Weimar, Deutschland)                                                    3 Knotentheoretische Eigenschaften können noch nicht codiert werden. 

Unterstützung der integrierten Gebäudeplanung und Verwaltung mit einem topologischen Kerndatenmodell

https://publikationen.bibliothek.kit.edu/1000011348/793705

Unterstützung der integrierten Gebäudeplanung und Verwaltung mit einem topologischen Kerndatenmodell

Abstract

Similar works

Full text

Available Versions

KITopen