Technische Einführung in FREAC

Informatik in der Architektur | InfAR

Arbeitspapiere Working Papers Nr. 2, Oktober 2010 Technische Einführung in FREAC Reinhard Koenig, Torsten Thurow, Jörg Braunes, Christian Tonn, Dirk Donath, Sven Schneider ISSN 2191-2416

Bauhaus-Universität Weimar, Professur Informatik in der Architektur, Belvederer Allee 1, 99421 Weimar Fon: +49/3643/584201, caad@architektur.uni-weimar.de, http://infar.architektur.uni-weimar.de

Reinhard Koenig, Torsten Thurow, Jörg Braunes, Christian Tonn, Dirk Donath, Sven Schneider Technische Einführung in FREAC Weimar 2010 Arbeitspapiere Informatik in der Architektur, Bauhaus Universität Weimar, Nr. 2 ISSN 2191-2416 Bauhaus-Universität Weimar, Professur Informatik in der Architektur Belvederer Allee 1, 99421 Weimar http://infar.architektur.uni-weimar.de Titelbild: Jugendstil-Wendeltreppe im Hauptgebäude © Bauhaus-Universität Weimar

Redaktionelle Anmerkung: Prof. Dr. Dirk Donath leitet die Professur Informatik in der Architektur an der Bauhaus-Universität Weimar. Dr. Reinhard König ist Vertretungsprofessor der Professur Informatik in der Architektur an der Bauhaus-Universität Weimar. Dr. Torsten Thurow, Dipl.-Ing. Jörg Braunes, Dipl.-Ing. Christian, Tonn und Dipl.-Ing. Sven Schneider sind wissenschaftliche Mitarbeiter an der Professur Informatik in der Architektur an der Bauhaus-Universität Weimar.

Der vorliegende Text ist auf Englisch erschienen: Koenig, R., Thurow, T., Braunes, J., Tonn, C., Donath, D., & Schneider, S. (2010). FREAC: A Technical Introduction to a Framework for Enhancing Research in Architectural Design and Communication.

Education and research in Computer Aided Architectural Design in Europe (eCAADe).

Arbeitspapiere Nr. 2

Bauhaus-Universität Weimar | Informatik in der Architektur

Technische Einführung in FREAC: A Framework for Enhancing Research in Architectural Design and Communication 1

2

3

4

5

Reinhard Koenig , Torsten Thurow , Jörg Braunes , Christian, Tonn , Dirk Donath , Sven Schneider 1

2

6

3

reinhard.koenig@uni-weimar.de, torsten.thurow@uni-weimar.de, joerg.braunes@uni-weimar.de, 5 6 christian.tonn@uni-weimar.de, donath@uni-weimar.de, sven.schneider@uni-weimar.de

4

Abstract Im vorliegenden Beitrag wird ein Framework für ein verteiltes dynamisches Produktmodell (FREAC) vorgestellt, welches der experimentellen Softwareentwicklung dient. Bei der Entwicklung von FREAC wurde versucht, folgende Eigenschaften umzusetzen, die bei herkömmlichen Systemen weitgehend fehlen: Erstens eine hohe Flexibilität, also eine möglichst hohe Anpassbarkeit für unterschiedliche Fachdisziplinen; Zweitens die Möglichkeit, verschiedene Tools nahtlos miteinander zu verknüpfen; Drittens die verteilte Modellbearbeitung in Echtzeit; Viertens das Abspeichern des gesamten Modell-Bearbeitungsprozesses; Fünftens eine dynamische Erweiterbarkeit sowohl für Softwareentwickler, als auch für die Nutzer der Tools. Die Bezeichnung FREAC umfasst sowohl das Framework zur Entwicklung und Pflege eines Produktmodells (FREAC-Development) als auch die entwickelten Tools selbst (FREAC-Tools).

Keywords: Softwareentwicklung; Experimentalplattform; Produktmodell; digitales Gebäudemodell.

1

Arbeitspapiere Nr. 2

Bauhaus-Universität Weimar | Informatik in der Architektur

1. Introduction Forschung im Bereich von Computer Aided Architectural Design (CAAD) besteht neben der Untersuchung, Bewertung und Einordnung bestehender digitaler Systeme in der Regel darin, neue Konzepte und Ideen für zukünftige Softwareentwicklungen auszuarbeiten. Diese Konzepte werden im Idealfall mittels Prototypen umgesetzt und evaluiert. Eine Möglichkeit, solche Prototypen zu realisieren besteht darin, kommerzielle Systeme als Basis zu nutzen und Erweiterungen für diese zu programmieren. Jedoch sind diese kommerziellen Systeme (trotz ihres großen Funktionsumfangs) häufig zu starr und unflexibel, um den oft sehr speziellen Anforderungen neuer Konzepte (z.B. interaktive und generative Entwurfssysteme, Open-Design Methoden, digitale Bauaufnahme) gerecht zu werden. Eine andere Möglichkeit für die Realisierung von Prototypen besteht in der Programmierung eigenständiger Tools "from the scratch". Neben dem sehr großen Programmieraufwand besteht hier jedoch das Problem der mangelhaften Kompatibilität mit anderen Programmen (Tools). Deshalb bleiben diese Werkzeuge oft auf spezielle Aspekte beschränkt und sind aufgrund ihres geringen Funktionsumfangs nur begrenzt evaluierbar.

Die beschriebene Situation macht deutlich, dass für die experimentelle Softwareentwicklung im Bereich der CAAD-Forschung ein Framework zur Verknüpfung verschiedener Softwaretools fehlt. Im vorliegenden Beitrag wird ein Framework für ein verteiltes dynamisches Produktmodell (FREAC) vorgestellt, welches die oben dargestellten Anforderungen erfüllt und in wesentlichen Teilen zur Verfügung steht. Die Bezeichnung FREAC umfasst sowohl das Framework zur Entwicklung und Pflege eines Produktmodells (FREAC-Development) als auch die entwickelten Tools selbst (FREAC-Tools). Entwickelt wurde FREAC als ForschungsExperimentierplattform, für die bis heute bereits zahlreiche Tools entstanden sind.

2. Konzept eines dynamischen Produktmodells Aktuelle CAAD-Systeme verwenden Bauwerks-Informations-Modelle (BIM) zur internen Abbildung ihrer Daten. Diese bieten in der Regel eine feste Strukturierung in Raum- und Bauteilobjekte sowie deren geometrische Ausprägung an. Eine Nutzer und Projekt orientierte Anpassung hinsichtlich Strukturierung und geometrischer Ausprägung ist derzeit nicht möglich. Dies ist aber bei der Umsetzung neuer Softwarekonzepte und Gebäudetypologien unabdingbar.

Kern des FREAC-Development bildet daher ein zur Laufzeit dynamisch veränderbares und erweiterbares Produktmodell. Einzelne Aspekte des Produktmodells lassen sich durch eine 2

Arbeitspapiere Nr. 2

Bauhaus-Universität Weimar | Informatik in der Architektur

Menge von Klassen und Objekten abbilden, welche wiederum aus Attributen und Methoden bestehen (Prinzip der Objektorientierten Programmierung). Ein dynamisches Modell erfordert, dass bestimmte Strukturen modifiziert bzw. erweitert werden müssen. Diese Modifikationen umfassen dabei u.a. das Hinzufügen und Ändern von Klassen, Attributen und Methoden.

Zur Umsetzung eines solchen dynamischen Produktmodells existieren verschiedene Ansätze, wobei unterschiedliche Anforderungen an Flexibilität und Performance an das Modell zu berücksichtigen sind: •

Flexibilität des Gesamtsystems, d.h. die Anpassungen von Attributen und Methoden sollen zur Laufzeit ermöglicht werden.

•

Teilweise hohe Anforderungen an die Geschwindigkeit, z.B. bei der Geometriedarstellung, oder bei der Ausführung aufwendiger numerischer Operationen

•

Effiziente Speichernutzung, insbesondere bei der geometrischen Abbildung größerer Bauwerke oder bei Details

•

Nötiges Fachwissen des Nutzers bei der Anpassung von Strukturen

Aus diesen Anforderungen ergeben sich Spannungen hinsichtlich Flexibilität auf der einen Seite und Performance, d.h. Geschwindigkeit und effektive Speichernutzung, auf der anderen Seite. Um den Anforderungen größtmöglich gerecht zu werden, wird ein heterogener Systemansatz vorgeschlagen, der Anpassungen auf verschiedenen Ebenen der Programmierung bzw. Nutzeranpassung vorsieht. Für den vorgeschlagenen Ansatz werden daher drei unterschiedliche Personengruppen vorgesehen: •

Programmierer

•

Administrator

•

Nutzer

Die Gruppe der Programmierer erstellt hauptsächlich Teilmodelle, wie z.B. zur Geometrieabbildung, Beschreibung der Raum- und Bauteilstruktur, Statik etc. Die Teilmodelle werden in der Regel mit Hochsprachen wie C++ erstellt wodurch eine hohe Performance und effiziente Speichernutzung gewährleistet wird. Eine Dynamik der Teilmodelle ist nur begrenzt möglich und wird zur Compilezeit bestimmt. Die Menge der Teilmodelle wird als Fachschale bezeichnet (Abb. 1).

Administratoren passen das Produktmodell seinen jeweiligen Aufgaben an. Anpassungen erfolgen zunächst durch Hinzuladen neuer Teilmodelle, welche anschließend modifiziert und erweitert werden können. Schnittstellen stelleneine Verbindung zwischen den fest 3

Arbeitspapiere Nr. 2

Bauhaus-Universität Weimar | Informatik in der Architektur

programmierten Teilmodellen und den darauf aufbauenden nutzerseitigen Erweiterungen von Attributen und Methoden durch bspw. Skripte dar. Die Fachschale zusammen mit den administrativen Anpassungen bzw. Erweiterungen stellen die Basisschemata dar, welche dem Nutzer zur Verfügung gestellt werden. Auf Applikationsebene füllen diese das Modell mit den jeweiligen Daten. Veränderungen am Produktmodell sind auf Basisschemata-Ebene nicht möglich.

Abb. 1: Aufbau des verteilten Produktmodells als Schalenmodell.

Die bisher entwickelten Teilmodelle nutzen das verteilte Produktmodell als BIM. Grundsätzlich ist der FREAC-Kern allerdings auch für andere Bereiche (z.B. Produktdesign oder Städtebau) adaptierbar und kann daher als verteiltes Produktmodell verstanden werden.

Die Nutzer des dargestellten Modells arbeiten in der Regel am gleichen Ort, sondern sind auf einzelne Büros oder Institutionen verteilt. Daher ist der Einsatz eines verteilten Produktmodells notwendig (Hauschild & Hübler 2003), welches den Zugriff auf das Modell „online“ ermöglicht. Idealerweise sollte dieser unmittelbar auf den zentral gehaltenen Datenbestand erfolgen. Da dies nicht in jedem Fall möglich ist, werden „Offline“- Synchronisationstechniken notwendig, welche das Splitten und spätere Zusammenfügen von Datenbeständen ermöglichen. FREAC nutzt dabei Techniken wie Transaktionen und Versionierungen mit Online-Synchronisation, welche die Speicherung der Historie von Modellen sowie ihre quasi-parallele Bearbeitung erlauben. Ein FREAC-Modell wird auf einem lokalen Computer mittels Anwendungen für spezielle Aufgaben, den Clients, bearbeitet. Alle Clients gleichen ihre Modelldaten mit denen auf einem zentralen Server ab. Anhand des Clientkonzepts wird eine reibungslose Vernetzung verschiedener Projekte ermöglicht, die, basierend auf einem gemeinsamen Modell, unabhängig voneinander entwickelt werden können. Durch die nahezu unbeschränkte Erweiterbarkeit auf Entwickler- sowie Nutzerebene stellt FREAC einen Ansatz vor, wie sich die Entwicklung von individuellen Software4

Arbeitspapiere Nr. 2

Bauhaus-Universität Weimar | Informatik in der Architektur

Insellösungen hin zu einem zusammenhängenden Kontinent digitaler Systeme verwirklichen lässt.

3. Technische Grundlagen von FREAC 3.1. Modellsynchronisation Bei dem FREAC zugrundeliegenden Ansatz erfolgt die Synchronisation von Veränderungen an einem Modell vorrangig online über kurze Transaktionen. Das heißt, dass nach jedem abgeschlossenen Veränderungsschritt, der am lokalen Modell anhand eines Clients durchgeführt wurde, einmalig die Modelländerungen an den Server und von dort wieder an alle Clients übertragen werden müssen. Das Vorgehen erlaubt eine quasiparallele Bearbeitung auf Grundlage einer sequentiellen Änderung des Modells ohne Merging-Mechanismen, beschränkt aber die Anzahl der quasiparallel arbeitenden Clients und stellt entsprechende Anforderung an die Kürze der Transaktionen. Weiter muss eine permanente Netzverbindung zwischen Clients und Server bestehen. Die zugrundeliegende persistente Datenhaltung unterstützt jedoch auch lokale Versionsverzweigungen, auf deren Grundlage OfflineSynchronisationen mit Merging-Ansatz aufbauen können.

Die Datenhaltung der FREAC-Modelle erfolgt parallel in Server und Clients. Dieser Ansatz erlaubt unter anderem eine Reduzierung der Netzlast, da nur Modelländerungen übertragen werden müssen. In der Regel sind die meisten Objektaufrufe lesender Art, so dass im Vergleich zu entfernten Methodenaufrufen meist nur auf die lokale Modellkopie zugegriffen werden muss.

Eine entscheidende Frage beim Entwurf einer Modellverwaltung ist die Größe der zu verwaltenden Modelle. Die Verwendung konventioneller Datenbanken erlaubt die Bearbeitung sehr großer Modelle, da hier der Arbeitsspeicher nicht die Modellgröße beschränkt.

Dafür ist die Zugriffsgeschwindigkeit auf Datenbankinhalte relativ langsam im Vergleich zu Modellen, welche vollständig im Arbeitsspeicher gehalten werden. Der vorgestellte FREACAnsatz geht hier einen Kompromiss ein, indem er beide Konzepte kombiniert. Diese Kombination führt zu einer Größenbeschränkung der Modelle, ermöglicht dafür aber eine höhere Zugriffsgeschwindigkeit im Vergleich zu Datenbanklösungen, da Objektinhalte im Arbeitsspeicher gehalten werden können. Des Weiteren werden Objekte erst dann in den Arbeitsspeicher geladen, wenn der erste Zugriff auf ihren Inhalt erfolgt. Die Objekte können auch wieder aus dem Arbeitsspeicher ausgelagert werden, solange auf ihren Inhalt nicht zugegriffen wird.

5

Arbeitspapiere Nr. 2

Bauhaus-Universität Weimar | Informatik in der Architektur

3.2. Dynamik der Modellstrukturen Im Bezug zur FREAC-Modellstruktur bedeutet Dynamik, dass bei einer bestehenden Datenstruktur jederzeit Objekte hinzugefügt, die Eigenschaften der Objekte erweitert, sowie neue Methoden zur Bearbeitung von Objekten erstellt werden können. Die Dynamik betrifft also sowohl Modellstruktur wie auch die darauf aufbauenden Algorithmen, wobei wir uns bei beiden vor allem auf die Erweiterbarkeit konzentrieren. Ein in dieser Art dynamisches Produktmodell ist, wie bereits erwähnt, deshalb so wichtig, da bei komplexen Artefakten nicht alle Elemente, deren Eigenschaften und Interaktionsmöglichkeiten vorherbestimmt werden können. Dies trifft nicht zuletzt auf die Abbildung von Bauwerken zu In der Regel bringt jeder Planungs- und Entwurfsprozess Sonderfälle mit sich.

FREAC wurde auf Grundlage von Microsofts Software-Plattform .NET erstellt. FREACModule mit hohen Anforderungen an Performance oder Speicherbedarf sind allerdings in unmanaged code implementiert. .NET bietet verschiedene Eigenschaften, welche sich sehr gut zur Realisierung der beschriebenen Dynamik eignen. Zum einen gibt der ReflectionMechanismus Auskunft über vorhandene Klassen und Datenstrukturen. Zum anderen können neue Assemblys (DLLs) zur Laufzeit hinzugefügt werden. Auf letztgenannter Möglichkeit basiert die Erstellung neuer Teilmodelle in FREAC. Diese Grundfunktionalitäten von .NET werden von FREAC ergänzt um erstens die Möglichkeit der Erweiterung von Objekten und Attributen zur Laufzeit um neue Attribute und um zweitens das Monitoring von Objekten und Attributen zur Laufzeit. Mit Monitoring ist im vorliegenden Kontext gemeint, das jedes Objekt und Attribut - auch zur Laufzeit hinzugefügte - in der Lage ist, andere Objekte - welche dieses beobachten - über Veränderungen zu informieren. Monitoring ist ein grundlegender Mechanismus zur Realisierung der dynamischen Erweiterbarkeit eines Modells. Ein weiterer ist das Hinzufügen von Teilmodellen zur Laufzeit durch neue Assemblys in Form von DLLs. Die Dynamik der FREAC-Modellstruktur soll in Zukunft nicht nur für Programmierer, sondern auch für Administratoren und Nutzer verfügbar sein. Auch hier bietet gerade .NET Vorteile, da im Rahmen dieser Software-Plattform verschiedene Programmiersprachen verfügbar sind. Da besonders bei Endnutzern keine Programmierkenntnisse vorausgesetzt werden können, bieten sich für die Ebene der Nutzer Ansätze der grafischen Programmierung oder des Scripting an.

6

Arbeitspapiere Nr. 2

Bauhaus-Universität Weimar | Informatik in der Architektur

4. Anwendungsbeispiele Im folgenden Abschnitt wird die Funktionsweise der FREAC-Modellstruktur anhand von ausgewählten Softwareprototypen (FREAC-Tools) beispielhaft demonstriert. Die vorgestellten Prototypen stellen zum Teil Testapplikationen zur Verifizierung bestimmter Funktionalitäten dar, sowie fortgeschrittene Anwendungen, die im Zuge verschiedener Forschungstätigkeiten entstanden sind. Im Folgenden werden die Applikationen kurz beschrieben und anschließend deren Einbindung in FREAC-Development dargestellt.

4.1. FREAC-Tools Ein FREAC-Tool ist „Colored Architecture“ (Tonn et al., 2006). Dieses widmet sich besonders dem Defizit des digitalen Farb- und Materialentwurfes, welcher vom Beginn einer Planung bis hin zur Ausführung unterstützt werden soll. „Colored Architecture“ adaptiert bewährte Vorgehensweisen, Darstellungen und Werkzeuge der Planungspraxis wie Varianten, Farbstudien, Farbharmonien und Farbkontraste, um die Gestaltung von Materialoberflächen zu unterstützen. Für die Bewertung und Beurteilung dieser Farb- und Materialkonzeptionen wurde eine Live-Radiosity-Berechnung entwickelt. Bei dieser lassen sich die Parameter Sonnenstand, Bewölkung des Himmels sowie die Farben der Oberflächen interaktiv einstellen, während man sofort die aktualisierte, realitätsnahe Radiosity-Visualisierung beurteilen kann. Mit Hilfe dieser Software lassen sich Wechselwirkungen wie z.B. Farbreflexionen der Materialien untereinander in Echtzeit darstellen und bewerten (Abb. 2).

Abb. 2: Live Radiosity-Visualisierung in „Colored Architecture“.

Ein weiteres Tool zur einfachen Modellierung von 3D-Geometrien ist der „SketchClient“ (Abb. 3, links). Es verfügt über einfache Polygonmodelling und -editing Funktionen. Dabei wird jede Änderung am Modell als Version abgespeichert und im Versionsgraphen dargestellt (Abb. 3, rechts). Ein schneller Wechsel zwischen verschiedenen Entwurfsvarianten sowie zu vorangegangenen Arbeitsständen ist jederzeit möglich. In jedem Knoten des Ver7

Arbeitspapiere Nr. 2

Bauhaus-Universität Weimar | Informatik in der Architektur

sionsgraphen wird protokolliert, welcher Nutzer zu welchem Zeitpunkt eine Änderung durchgeführt hat, und wie viele Objekte verändert wurden. Dieses Versionierungssystem ist dabei nicht auf den einzelnen Client beschränkt, sondern wird durch die FREACModellstruktur zentral bereitgestellt.

Abb. 3: Modellierwerkzeug „SketchClient“ und sein Versionsgraph-Dialog.

Bei dem dritten hier angeführten Beispiel handelt es sich nicht um einen eigenständigen Client, sondern um ein ergänzendes Teilmodell, welches der Abbildung der Raum- und Bauteilstruktur eines Gebäudes dient. Dieses Teilmodell befindet sich derzeit in der Entwicklung und orientiert sich in seinem Aufbau zu großen Teilen an den IFC. Innerhalb eines Clients wird die Gebäudestruktur in Form eines Treeview geordnet dargestellt. Diese Struktur basiert auf der Organisation in: Projekt → Grundstück → Gebäude → Geschoss → Raum oder Bauteilkategorien. Die einzelnen abstrakten Elemente des Raum- und Bauteilmodells werden mit der zugehörigen 3D-Geometrie verknüpft.

4.2. Zusammenarbeit der Teilmodelle Je nach Anwendungsgebiet verwenden die einzelnen FREAC-Tools unterschiedliche Teilmodelle, welche spezifische Aufgaben erfüllen. „ColoredArchitecture“ beispielsweise verwendet zur Darstellung der 3D-Geometrie das „GeometryModel“. Die Funktionalitäten zur Farb- und Materialwahl sowie der Live-Radiosity-Berechnung sind im „ColorModel“ implementiert. Der „SketchClient“ wiederum greift lediglich auf das „GeometryModel“ zu. Zur semantischen Abbildung eines Gebäudes wird wiederum das „BuildingElementModel“ in Verbindung mit dem „GeometryModel“ verwendet. Alle Teilmodelle und das Zusammenspiel der Clients werden vom „SyncServer“ verwaltet, wobei zwischen den Clients und dem Server lediglich Änderungen an den Modellen übertragen werden (Abb. 4). Die Clients „sehen“ immer nur die Modelle, bzw. die in den Modellen gespeicherten Objekte, die sie für ihren Anwendungsfall benötigen. Änderungen an Modellinhalten werden aber - im Gegensatz zu einem Repositorium - in Echtzeit an alle Clients weitergegeben.

8

Arbeitspapiere Nr. 2

Bauhaus-Universität Weimar | Informatik in der Architektur

Abb. 4: Teilmodelle (unten) und Interaktion zwischen Clients und dem SyncServer.

Wie im technischen Teil dieses Artikels bereits erläutert, erlaubt die dynamische Modellstruktur des FREAC-Development jederzeit das Ergänzen und Anpassen von Teilmodellen ohne die Notwendigkeit der Recompilierung bereits bestehender Teilmodelle. Damit können die FREAC-Tools jederzeit um neue Softwareprototypen für neue Anwendungsfälle ergänzt werden. Neu entwickelte Clients können dabei sowohl bestehende, wie auch neue Teilmodelle nutzen.

5. Ausblick Ziel der Entwicklung von FREAC ist es, eine flexible Plattform für verschiedene CAADForschungsprojekte zu etablieren. In einer Reihe von Forschungsprojekten wurde und werden vielfältige Clients entwickelt: Zur computerbasierten Bauaufnahme, für verschiedene Planungsaspekte wie Farbplanung oder die Ermittlung der optimalen Ausnutzung von Grundstücken, zur Generierung von Architekturlayouts sowie zur Koordination und Kommunikation in offenen kollaborativen Entwurfsprozessen. Die in diesen Projekten entstandenen Clients sind über das FREAC-Modellkonzept nahtlos miteinander verbunden. Sie demonstrieren die Potentiale des vorgestellten Ansatzes für den Austausch zwischen verschiedenen Fachdisziplinen im Planungsprozess – der Verbindung der Insellösungen zu einem Modell-Kontinent.

Wir beabsichtigen, FREAC ab Anfang 2011 für Forschungsprojekte unentgeltlich zur Verfügung zu stellen.

9

Arbeitspapiere Nr. 2

Bauhaus-Universit辰t Weimar | Informatik in der Architektur

References Hauschild, T. & H端bler, R. (2003): Techniken der Verwaltung dynamischer digitaler Bau-

werksmodelle f端r Revitalisierungsvorhaben. Proceedings of IKM 16: Internationales Kolloquium 端ber Anwendungen der Informatik und Mathematik in Architektur und Bauwesen (http://e-pub.uni-weimar.de/volltexte/2005/317/) Tonn, C., & Donath D. (2006): Color, Material and Light in the Design Process: A Software

Concept. (RivardH., MelhemH., MirescoE., Ed.). Proceedings of ICCCBE: International Conference on Computing and Decision Making in Civil and Building Engineering.

1467-1476

10