technische einführung in freac

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

Informatik in der Architektur | InfAR

Bauhaus-Universität Weimar, Professur Informatik in der Architektur, Belvederer Allee 1, 99421 Weimar Fon: +49/3643/584201, [email protected], 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 Techni-

cal 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

1

Technische Einführung in FREAC:

A Framework for Enhancing Research in

Architectural Design and Communication

Reinhard Koenig1, Torsten Thurow

2, Jörg Braunes

3, Christian, Tonn

4, Dirk Donath

5, Sven Schneider

6

[email protected],

[email protected],

[email protected],

[email protected],

[email protected],

[email protected]

Abstract

Im vorliegenden Beitrag wird ein Framework für ein verteiltes dynamisches Produktmodell

(FREAC) vorgestellt, welches der experimentellen Softwareentwicklung dient. Bei der Ent-

wicklung von FREAC wurde versucht, folgende Eigenschaften umzusetzen, die bei her-

kömmlichen Systemen weitgehend fehlen: Erstens eine hohe Flexibilität, also eine mög-

lichst hohe Anpassbarkeit für unterschiedliche Fachdisziplinen; Zweitens die Möglichkeit,

verschiedene Tools nahtlos miteinander zu verknüpfen; Drittens die verteilte Modellbear-

beitung 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äu-

demodell.


2

1. Introduction

Forschung im Bereich von Computer Aided Architectural Design (CAAD) besteht neben der

Untersuchung, Bewertung und Einordnung bestehender digitaler Systeme in der Regel da-

rin, neue Konzepte und Ideen für zukünftige Softwareentwicklungen auszuarbeiten. Diese

Konzepte werden im Idealfall mittels Prototypen umgesetzt und evaluiert. Eine Möglich-

keit, solche Prototypen zu realisieren besteht darin, kommerzielle Systeme als Basis zu nut-

zen und Erweiterungen für diese zu programmieren. Jedoch sind diese kommerziellen Sys-

teme (trotz ihres großen Funktionsumfangs) häufig zu starr und unflexibel, um den oft sehr

speziellen Anforderungen neuer Konzepte (z.B. interaktive und generative Entwurfssyste-

me, Open-Design Methoden, digitale Bauaufnahme) gerecht zu werden. Eine andere Mög-

lichkeit 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 ge-

ringen Funktionsumfangs nur begrenzt evaluierbar.

Die beschriebene Situation macht deutlich, dass für die experimentelle Softwareentwick-

lung im Bereich der CAAD-Forschung ein Framework zur Verknüpfung verschiedener Soft-

waretools 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 Forschungs-

Experimentierplattform, 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 orien-

tierte 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


3

Menge von Klassen und Objekten abbilden, welche wiederum aus Attributen und Metho-

den 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ät-

ze, 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 Geometriedar-

stellung, 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 ande-

ren Seite. Um den Anforderungen größtmöglich gerecht zu werden, wird ein heterogener

Systemansatz vorgeschlagen, der Anpassungen auf verschiedenen Ebenen der Programmie-

rung 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 Geometrie-

abbildung, Beschreibung der Raum- und Bauteilstruktur, Statik etc. Die Teilmodelle werden

in der Regel mit Hochsprachen wie C++ erstellt wodurch eine hohe Performance und effizi-

ente Speichernutzung gewährleistet wird. Eine Dynamik der Teilmodelle ist nur begrenzt

möglich und wird zur Compilezeit bestimmt. Die Menge der Teilmodelle wird als Fachscha-

le 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


4

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

sä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 Pro-

duktmodells notwendig (Hauschild & Hübler 2003), welches den Zugriff auf das Modell

„online“ ermöglicht. Idealerweise sollte dieser unmittelbar auf den zentral gehaltenen Da-

tenbestand erfolgen. Da dies nicht in jedem Fall möglich ist, werden „Offline“- Synchroni-

sationstechniken notwendig, welche das Splitten und spätere Zusammenfügen von Daten-

beständen ermöglichen. FREAC nutzt dabei Techniken wie Transaktionen und Versionie-

rungen 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 Cli-

ents gleichen ihre Modelldaten mit denen auf einem zentralen Server ab. Anhand des Cli-

entkonzepts 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 Nutzer-

ebene stellt FREAC einen Ansatz vor, wie sich die Entwicklung von individuellen Software-


5

Insellösungen hin zu einem zusammenhängenden Kontinent digitaler Systeme verwirkli-

chen 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 durch-

gefü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 Netzverbin-

dung zwischen Clients und Server bestehen. Die zugrundeliegende persistente Datenhal-

tung unterstützt jedoch auch lokale Versionsverzweigungen, auf deren Grundlage Offline-

Synchronisationen 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 übertra-

gen 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 zugegrif-

fen werden muss.

Eine entscheidende Frage beim Entwurf einer Modellverwaltung ist die Größe der zu ver-

waltenden Modelle. Die Verwendung konventioneller Datenbanken erlaubt die Bearbei-

tung 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 FREAC-

Ansatz geht hier einen Kompromiss ein, indem er beide Konzepte kombiniert. Diese Kom-

bination führt zu einer Größenbeschränkung der Modelle, ermöglicht dafür aber eine höhe-

re Zugriffsgeschwindigkeit im Vergleich zu Datenbanklösungen, da Objektinhalte im Ar-

beitsspeicher 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ön-

nen auch wieder aus dem Arbeitsspeicher ausgelagert werden, solange auf ihren Inhalt

nicht zugegriffen wird.


6

3.2. Dynamik der Modellstrukturen

Im Bezug zur FREAC-Modellstruktur bedeutet Dynamik, dass bei einer bestehenden Daten-

struktur 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 Pro-

duktmodell 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. FREAC-

Module 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 Reflection-

Mechanismus Auskunft über vorhandene Klassen und Datenstrukturen. Zum anderen kön-

nen neue Assemblys (DLLs) zur Laufzeit hinzugefügt werden. Auf letztgenannter Möglich-

keit basiert die Erstellung neuer Teilmodelle in FREAC.

Diese Grundfunktionalitäten von .NET werden von FREAC ergänzt um erstens die Möglich-

keit 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 hinzuge-

fügte - in der Lage ist, andere Objekte - welche dieses beobachten - über Veränderungen

zu informieren. Monitoring ist ein grundlegender Mechanismus zur Realisierung der dyna-

mischen 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, son-

dern auch für Administratoren und Nutzer verfügbar sein. Auch hier bietet gerade .NET

Vorteile, da im Rahmen dieser Software-Plattform verschiedene Programmiersprachen ver-

fügbar sind. Da besonders bei Endnutzern keine Programmierkenntnisse vorausgesetzt

werden können, bieten sich für die Ebene der Nutzer Ansätze der grafischen Programmie-

rung oder des Scripting an.


7

4. Anwendungsbeispiele

Im folgenden Abschnitt wird die Funktionsweise der FREAC-Modellstruktur anhand von

ausgewählten Softwareprototypen (FREAC-Tools) beispielhaft demonstriert. Die vorgestell-

ten Prototypen stellen zum Teil Testapplikationen zur Verifizierung bestimmter Funktionali-

tä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 beson-

ders dem Defizit des digitalen Farb- und Materialentwurfes, welcher vom Beginn einer Pla-

nung bis hin zur Ausführung unterstützt werden soll. „Colored Architecture“ adaptiert be-

wä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 Materialkonzep-

tionen wurde eine Live-Radiosity-Berechnung entwickelt. Bei dieser lassen sich die Parame-

ter Sonnenstand, Bewölkung des Himmels sowie die Farben der Oberflächen interaktiv ein-

stellen, während man sofort die aktualisierte, realitätsnahe Radiosity-Visualisierung beurtei-

len 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 darge-

stellt (Abb. 3, rechts). Ein schneller Wechsel zwischen verschiedenen Entwurfsvarianten

sowie zu vorangegangenen Arbeitsständen ist jederzeit möglich. In jedem Knoten des Ver-


8

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 FREAC-

Modellstruktur 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 Ent-

wicklung 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 Struk-

tur 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 Teil-

modelle, welche spezifische Aufgaben erfüllen. „ColoredArchitecture“ beispielsweise ver-

wendet zur Darstellung der 3D-Geometrie das „GeometryModel“. Die Funktionalitäten zur

Farb- und Materialwahl sowie der Live-Radiosity-Berechnung sind im „ColorModel“ im-

plementiert. 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 Zusammen-

spiel der Clients werden vom „SyncServer“ verwaltet, wobei zwischen den Clients und dem

Server lediglich Änderungen an den Modellen übertragen werden (Abb. 4). Die Clients „se-

hen“ 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 Gegen-

satz zu einem Repositorium - in Echtzeit an alle Clients weitergegeben.


9

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

Wie im technischen Teil dieses Artikels bereits erläutert, erlaubt die dynamische Modell-

struktur des FREAC-Development jederzeit das Ergänzen und Anpassen von Teilmodellen

ohne die Notwendigkeit der Recompilierung bereits bestehender Teilmodelle. Damit kön-

nen 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 CAAD-

Forschungsprojekte zu etablieren. In einer Reihe von Forschungsprojekten wurde und wer-

den 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 Kom-

munikation in offenen kollaborativen Entwurfsprozessen. Die in diesen Projekten entstan-

denen Clients sind über das FREAC-Modellkonzept nahtlos miteinander verbunden. Sie

demonstrieren die Potentiale des vorgestellten Ansatzes für den Austausch zwischen ver-

schiedenen Fachdisziplinen im Planungsprozess – der Verbindung der Insellösungen zu ei-

nem Modell-Kontinent.

Wir beabsichtigen, FREAC ab Anfang 2011 für Forschungsprojekte unentgeltlich zur Verfü-

gung zu stellen.


10

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

technische einführung in freac

Documents