Innovativer Holzsystembau

Schlussbericht zu Nr. 3.2 BNBest-BMBF 98

Zuwendungsempfänger: Förderkennzeichen: Brandenburgische Technische Universität Cottbus 0330424 Lehrstuhl Statik und Dynamik PF 10 13 44 03013 Cottbus Vorhabenbezeichnung: Verbundvorhaben „Innovativer Holzsystembau durch optimierte Fertigungs- und integrierte Planungsmethoden“ Teilvorhaben 3 „Produktmodell DtH — Durchgängiger Datentransfer zur Minimierung des Ressourcenverbrauchs“ Laufzeit des Vorhabens: 01.07.2003 – 31.01.2005

A Kurzdarstellung...... 2 1 Aufgabenstellung...... 2 2 Voraussetzungen der Durchführung des Vorhabens ...... 3 3 Planung und Ablauf des Vorhabens...... 3 4 Wissenschaftlicher und technischer Stand, an den angeknüpft wurde ...... 3 B Ausführliche Darstellung ...... 5 5 Ergebnis ...... 5 5.1 Definitionsphase...... 5 5.2 Konzeptionsphase...... 9 5.3 Erprobungsphase...... 15 5.4 Transferphase ...... 16 6 Fortschritte auf dem Gebiet des Vorhabens bei anderen Stellen...... 16 7 Zusammenarbeit mit anderen Stellen...... 16 7.1 Zusammenarbeit im Teilvorhaben...... 16 7.2 Zusammenarbeit im Verbundvorhaben ...... 16 7.3 Zusammenarbeit mit IAI-Partnern ...... 17 7.4 Ereignisse...... 18 8 Voraussichtlicher Nutzen, Verwertbarkeit des Ergebnisses...... 21 9 Erfolgte und geplante Veröffentlichungen ...... 23 Anlage [ I ] IAI-Projekt ST-5 — Structural Timber Model — Teil I: Anforderungen [ II ] IAI-Projekt ST-5 — Structural Timber Model — Teil II: Klassen-Referenz [ III ] IAI-Projekt ST-5 — Structural Timber Model — Teil III: Implementierungshilfe sowie deren englische Fassungen 1 Aufgabenstellung 2

A Kurzdarstellung

1 Aufgabenstellung

In (Holz-)Bauprojekten ist intensive Kommunikation zwischen Planern und baugewerblichen Unternehmern erforderlich, wobei umfangreiche Projektdaten binnen kurzer Projektfristen auszutauschen bzw. gemeinsam zu bearbeiten sind. Während nun interne Abläufe in Planungsbüros sowie auf Seiten des Holzbauunternehmers die Angebotserstellung, Arbeits- vorbereitung und Produktionssteuerung heute jeweils in sich durch EDV-Integrationslösun- gen abgedeckt sind, fehlt für die interdisziplinäre und unternehmensübergreifende Kommuni- kation bislang die Möglichkeit, Projektdaten umfassend und verlustlos zu übertragen bzw. redundanzarm vorzuhalten und gemeinsam zu nutzen.

Dies führt nicht nur zu hohem Aufwand für Kommunikation und Koordinierung am Bau Beteiligter, sondern auch zu Fehlern infolge unvollständig oder unrichtig übermittelter Information oder nicht abgeglichener Planungsstände. Außerdem bleiben Potentiale der Projektoptimierung — insbesondere Bauwerksoptimierung durch ganzheitliche Systembe- trachtung — mangels gemeinsamer Informationsnutzung unausgeschöpft.

Deshalb ist ein standardisiertes und interdisziplinär angelegtes Datenmodell erforderlich. Dieses muss durchgängige gemeinsame Nutzung von Projektinformation in allen Bauprojekt- phasen ermöglichen: Grundlagenermittlung, Architekturentwurf, konstruktiver Entwurf, statische Berechnung, haustechnische Fachplanung, konstruktive Detailplanung, Bauantrag und Genehmigung, Ausschreibung und Vergabe, Arbeitsvorbereitung, Vorfertigung, Errichtung, Facilities Management.

Ein solches Modell bildet die Grundlage für ressourcenoptimiertes Planen und Bauen: Bau- werke bzw. Projekte werden hinsichtlich Material, Energie und Logistik weitergehend steuer- bar, da zum Einen die nötige fachübergreifende Information über das Modell verfügbar ist und zum anderen Planungs-Iterationen kostengünstiger, schneller und fehlerärmer durch- führbar werden. 4 Wissenschaftlicher und technischer Stand, an den angeknüpft wurde 3

2 Voraussetzungen der Durchführung des Vorhabens

Mit Ausnahme von IFC decken alle bisherigen Datenmodelle zu enge Anwendungsbereiche ab bzw. beschränken sich auf nationale oder gar herstellerabhängige Insellösungen. Benö- tigt wird ein auf internationaler Ebene etabliertes Produktdatenmodell. Gerade im Holzbau sind nationale Lösungen angesichts des europaweiten Marktes für Bauprodukte und Bauproduktion nicht durchsetzungsfähig. Die installierte Basis wäre zu gering, um im Datenmodell die spezifischen Ansprüche des Holzbaus sowie diejenigen des allgemeinen Bauwesens gleichermaßen zu berücksichtigen. Das Vorhaben verlangte deshalb nach internationaler Kooperation mit der Bausoftwareindustrie und einschlägigen Industriever- bänden.

3 Planung und Ablauf des Vorhabens

Das Vorhaben wurde in das Verbund-Forschungsvorhaben „Innovativer Holzsystembau durch optimierte Fertigungs- und integrierte Planungsmethoden“ eingebettet. Dieses hat zum Ziel, Rationalisierungspotentiale im Holzsystembau, insbesondere Holzhausbau zu erschlie- ßen, die einerseits in verstärktem Einbezug von Ausbaugewerken in die Vorfertigung und andererseits in der optimalen Konzeption der teilautomatischen Fertigung liegen. Dazu sind optimierte Bauwerksentwürfe und -konstruktionen, intensivierte Kommunikation der Planer und Gewerke sowie fertigungsgerecht vorliegende Projektdaten erforderlich.

Das Teilvorhaben 3 schafft somit informationstechnische Grundlagen, die bei der praktischen Umsetzung der Ergebnisse der Teilvorhaben 1 und 2 benötigt werden. Umgekehrt bedeutet dies, dass aus diesen Teilvorhaben Anforderungskataloge für Teilvorhaben 3 abzuleiten waren. Zeitlich wurde Teilvorhaben 3 deshalb mit Nachlauf gestartet. Das Teilvorhaben gliedert sich in Definitions-, Konzeptions-, Erprobungs- und Transfer-Phase, welche in Abschnitt B5 besprochen werden.

Die ursprüngliche Laufzeit von 12 Monaten wurde kostenneutral auf 19 Monate geändert, was der erforderlichen Abstimmung auch mit internationalen Partnern enorm zugute kam sowie Erprobung und Transfer begünstigte.

4 Wissenschaftlicher und technischer Stand, an den angeknüpft wurde

Informationstechnische Anforderungen, wie oben genannt, können nur mittels eines sogenannten Produktmodells erfüllt werden. Ein zeitlicher Abriss der Forschung, Entwicklung und Standardisierung von Produktmodellen ist in der anliegenden Dokumentation [I Abschnitt 2] wiedergegeben. 4 Wissenschaftlicher und technischer Stand, an den angeknüpft wurde 4

Im Vorhaben „Produktmodell DtH — Durchgängiger Datentransfer zur Minimierung des Ressourcenverbrauchs“ wurden in der bisherigen Praxis aufgetretene Probleme und im Zusammenhang des Verbundvorhabens erkannte Unzulänglichkeiten des DtH-Modells analysiert. Es wurde eine grundlegende Neufassung des Modells erarbeitet, das vor allem von der Integration in den IFC-Standard geprägt ist. (Literaturhinweise zu IFC siehe [I Abschnitt 5.1])

Die beiden Standards ergänzen sich ideal: IFC als international anerkanntes Modell für den allgemeinen Hochbau sowie DtH als spezielles Modell für den Holzbau, das zwar bislang nur in Deutschland umgesetzt war, dessen Relevanz aber auch im skandinavischen Raum erkannt wurde.

5 Ergebnis 5

B Ausführliche Darstellung

5 Ergebnis

5.1 Definitionsphase

5.1.1 Methoden, Instrumente

Die Definitionsphase beinhaltete Analyse und Abgrenzung von Teilprozessen und Teil- modellen sowie die Festlegung der Anforderungen an das Produktmodell. Dabei standen zwei Aktivitäten im Vordergrund:

• Analyse der Prozesse in Holzbauprojekten,

• Analyse existierender Datenmodelle.

Detaillierte Ergebnisse sowie Quellenangaben sind der anliegenden Dokumentation „IAI- Projekt ST-5 — Structural Timber Model“ zu entnehmen. Ergebnisse der Definitionsphase sind in [I] festgehalten. An dieser Stelle erfolgt lediglich ein Überblick:

Seit etwa den 1990er Jahren besteht wissenschaftlich weitgehender Konsens, dass die eingangs angesprochen informationstechnischen Anforderungen nur mittels Produktmodell zu erfüllen sind. Das Konzept der Produktmodellierung stammt v.a. aus dem Flugzeug- und Fahrzeugbau und wurde auch in anderen Industrien wie Elektrotechnik und Schiffsbau umgesetzt. Technische Grundlage ist überwiegend STEP (ISO 10303). Die Entwicklung, Standardisierung und praktische Umsetzung solcher Modelle ist aus verschiedenen Gründen sehr langwierig — so auch im Bauwesen, wo als Erschwernis die fachliche und organisatorische Heterogenität der an Bauprojekten Beteiligten und die Wechselhaftigkeit der in Bau- projekten gestellten Aufgaben hinzukommt.

Speziell im Holzbau sind seit längerem für Detailplanung und Fertigung leistungsfähige integrierte EDV-Produkte verfügbar und erprobt. Für Standardisierungsbestrebungen ist dies Vorteil und Nachteil zugleich: Zum einen verfügen Softwareprodukte intern über Daten- modelle, die zur Abbildung auf Produktmodelle geeignet sind. Zum Anderen blockieren kurz- fristige Vorteile der Integrationslösungen (bilaterale Schnittstellen, welche letztendlich nur auf „Informationsinseln“ zu funktionieren vermögen) das Bestreben nach umfassend interoper- ablen, herstellerunabhängigen Lösungen, etwa dem DGfH-Standard DtH.

Auf dem Gebiet der allgemeinen Hochbauplanung, später auch Haustechnik und Facilities Management, hat sich der IFC-Standard international etablieren können und insbesondere in 5 Ergebnis 6 den letzte Jahren stark wachsende Unterstützung gefunden. In diesem Zusammenhang ist als überwiegend förderlich anzusehen, dass führende CAD-Lösungen im Architekturbereich heute intern auf Gebäudemodelle setzen (BIM, Building Information Models). Dies geschah aus der Anwenderforderung heraus, Prozesse wie funktionalen Entwurf und Mengenermitt- lung zu integrieren. Implementierung eines BIM ist Voraussetzung für die Anbindung einer Software an ein Produktmodell wie IFC. Langfristig soll mittels BIM eine der wesentlichen Grundideen der Produktmodellierung praktisch umgesetzt werden: Die Wiederverwendung von Information über ein Produkt (ein Bauwerk) innerhalb seines gesamten Lebenszyklus.

Lebenszyklus-bezogener Ansatz der Produktmodellierung

Weitere Datenmodelle mit Bedeutung im Bauwesen bzw. im Umfeld des Holzbaus sind in der Dokumentation aufgeführt.

5.1.2 Prozessmodellierung

Prozesse bzw. Aktivitäten sind gekennzeichnet durch

• Inputs und Outputs, im Zusammenhang mit Produktmodellierung insbesondere mit der eingehenden und ausgehenden Projekt- bzw. Bauwerksinformation;

• Kontrollen, d.h. Randbedingungen, welche die Möglichkeiten zur Ausführung der Aktivität einschränken;

• Mechanismen, welche die Aktivität ausführen oder unterstützen — vor allem die ausführenden Akteure sowie die verwendeten EDV-Werkzeuge.

Die Prozesse innerhalb eines Holzbauprojekts lassen sich beliebig fein aufgeschlüsselt folgenden wesentlichen Aktivitäten zuordnen:

• Architekturplanung: Planung der räumlichen Struktur und Zuordnung der Nutzungen, Einordnung in das Umfeld, formale Gestaltung. Vorwahl von Elementen der statischen und haustechnischen Systeme. Eingangsdaten sind Vorgaben des Bauherren und Daten des Baugrundstücks. 5 Ergebnis 7

• Tragwerksplanung: Planung der tragenden und aussteifenden Systeme. Dimensio- nierung von Bauteilen und Anschlüssen. Eingangsdaten sind Architekturentwurf und bauphysikalischer Entwurf, des weiteren Details der Konstruktionslösung und später der haustechnischen Planung, meist indirekt auch Bauherrenvorgaben.

• Bauphysikalische und haustechnische Planung: Planung der Gebäudehülle nach energetischen und hygroskopischen Kriterien; Planung der Netze der technischen Ausstattung. Eingangsdaten sind Bauherrenvorgaben und Architekturplanung.

• Baukonstruktion/ Werkplanung: Detailplanung von Trag- und Ausbauelementen, Anschlüssen. Eingangswerte sind die Ergebnisse aller vorgenannten Aktivitäten.

• Produktionsplanung/ Arbeitsvorbereitung: Planung der Prozesse der Vorfertigung, der Errichtung, des Ausbaus. Im teilautomatisierten Holzsystembau schließt dies die Datenübergabe an numerisch gesteuerte Fertigungsanlagen ein. Eingangsdaten sind je nach Projektfortschritt und Detaillierungsgrad die Ergebnisse der vorgenannten Aktivitäten, insbesondere der Werkplanung.

Technische Regeln, Bauordnungsrecht und bürgerliches Recht wirken steuernd auf alle o.g. Aktivitäten. Weitere Aktivitäten sind die Projektsteuerung und die Kostenplanung seitens des Bauherrenvertreters und seitens der Unternehmer. Gerade die Kostenplanung wirkt regelnd auf alle übrigen Aktivitäten. Prägend für Holzbauprojekte sind

• die zeitliche Überlappung der Aktivitäten;

• Rekursionen; iteratives Planen (Informationszuwachs innerhalb einer Aktivität führt zu Reaktionsbedarf innerhalb einer anderen Aktivität);

• das Aufgreifen vorhandener, mehr oder weniger vollständig detaillierter Entwürfe und Typenprojekte; deren Anpassung an das konkrete Projekt.

Anhand der mehrfachen Abhängigkeiten und Rückkopplungen der Aktivitäten ist erkennbar, dass kein Bauprojekt als einfache Sequenz von Aktivitäten realisierbar ist. Dies muss im Datenmodell konzeptionell berücksichtigt werden.

5.1.3 Produktmodellierung: Abgrenzung von Teilmodellen

Aus dem Prozessmodell werden Folgerungen für die Konzeption des Datenmodells sowie inhaltliche Anforderungen an das Produktmodell abgeleitet. Insbesondere werden Teilmo- delle und ihre Beziehungen identifiziert. Die gegenüber DtH 2.0 veränderte Abgrenzung von Teilmodellen und ihre internen und externen Beziehungen im Datenmodell werden in [I] 5 Ergebnis 8 implementierungs-unabhängig dargestellt und in [III] noch einmal anwendungsbezogen besprochen.

Teilmodelle werden formuliert, da Akteure mit unterschiedlicher Sichtweise und Intensität auf Teilbereiche des Bauwerksmodells zugreifen. Teilmodelle können als Ausschnitte, Betrach- tungswinkel oder Abstrahierungsvarianten des Gesamtmodells verstanden werden. Im Einzelnen sind dies:

• Physisches Bauwerksmodell: Gesamtheit der herzustellenden Bauteile, Basis für die folgenden Teilmodelle;

• Architekturmodell: Räume mit ihren Funktionen, Begrenzungen und Verknüpfungen; Merkmale der äußeren und inneren Gestalt des Bauwerks; Eigenschaften der Hülle und weiterer raumabschließender Bauteile;

• Tragwerksmodell: statische Systeme einschließlich Einwirkungen und Reaktionen, beinhaltet mechanische Abstraktionen von Bestandteilen des physischen Bauwerks- modells;

• Modell des technischen Ausbaus: beinhaltet Netze der technischen Ausstattung;

• Detaillierungs- und Produktionsmodell: Präzisierung des physischen Bauwerks- modells hinsichtlich der für die Fertigung nötigen Informationen;

• Kostenmodell.

5.1.4 Anforderungen an das Produktmodell — Pflichtenheft

Technische Anforderungen:

• Aufwärtskompatibilität zu DtH 2.0 hinsichtlich des Informationsumfanges: Allenfalls eindeutig obsolete Objekte oder Attribute dürfen entfallen.

• formal: IFC-Konformität (Auf Syntaxebene geht Kompatibilität zu DtH 2.0 auf verloren.)

• weitgehende formale Übereinstimmung mit verwandten IFC-Domänenmodellen (Stahlbau, Stahlbetonfertigteilbau)

• Unabhängigkeit von Baufachnormen, internationale Anwendbarkeit; insbesondere Aktualisierung der Materialbeschreibung

• Anbindung des bisher fehlenden Teilmodells des technischen Ausbaus 5 Ergebnis 9

• Fortschreibung des Detaillierungs- und Produktionsmodells gemäß den Anforderungen teilautomatischer Fertigung:

o Nicht nur Einzelbauteile, sondern auch Baugruppen können getrennt und die erzeugten Teile an unterschiedlichen Orten eingebaut werden.

o Zuordnung von Einzelbauteilen zu Baugruppen nicht optional, sondern verpflichtend regeln; Koordinaten von Einzelbauteilen beziehen sich auf lokales Koordinatensystem der Baugruppe

o Attribute für Toleranzangaben und Güteanforderungen, aus denen Werkzeuge und Verarbeitungsgeschwindigkeiten abgeleitet können

o Attribute zur expliziten Selektion von Werkzeugen

o Assoziation von Bearbeitungen, Bauteilen oder Baugruppen mit Steuercodes

o Unterscheidung zwischen Bearbeitungen im Werk und auf der Baustelle auszuführenden Bearbeitungen

o Unterstützung der Generierung von Stücklisten

• Unterstützung der Ablaufplanung

• Berücksichtigung paralleler Bearbeitung (concurrent engineering):

o Vereinbarungen für Versionsverwaltung; Verfolgung von Änderungen, auch über Teilmodell-Grenzen hinweg

o flexible Gliederung/ Strukturierung des Projektes im Hinblick auf Unterteilung in und Bearbeitung von Teilprojekten

Daneben bestehen folgende, über rein technische Sachverhalte hinausgehende Forderungen:

• Regelung von Konformitätsprüfungen von Implementierungen des Produktmodells

• Etablierung des Produktmodells als Standard für die Steuerung von Fertigungs- anlagen, somit Ablösung von bisherigen herstellerkontrollierten Formaten

5.2 Konzeptionsphase

Die Konzeptionsphase umfasste die Entwicklung der Produktmodellstruktur in Teilmodellen, die Entwicklung der Datenstrukturen innerhalb der Teilmodelle (dargestellt in [II]) sowie das 5 Ergebnis 10

Erstellen von Arbeits- und Ablaufplänen für die Implementierung [III]. An dieser Stelle sei nur auf einige diesbezügliche Unterschiede zum Modell DtH 2.0 eingegangen.

5.2.1 Das Metamodell

Neben einfachen Datentypen (Integer- und Fließkommazahlen, Zeichenketten, Aufzählungs- typen) und Aggregaten (Sets, Listen u.a.) sind die Klassen (Entities) die wesentlichen Bestandteile des Metamodells. Gegenüber DtH 2.0 besitzt IFC erheblich mehr Klassen, und zwar bereits schon vor Erweiterung um das Structural Timber Model. Dies hat zwei Gründe:

• Sehr viel mehr Prozesse und Disziplinen sind detaillierter zu unterstützen.

• Funktionale Einheiten, die in DtH als ein einziges Objekt abgebildet wurden, sind nun in aller Regel mittels mehrerer Objekte verschiedener Klassen abzubilden. Dies trägt der unterschiedlichen Relevanz dieser Klassen aus Sicht verschiedener Disziplinen bzw. in verschiedenen Bauprojektphasen Rechnung. Es erleichtert die Umsetzung fachspezifischer Sichten auf das Modell (sogenannte Views), die sich in fachübergrei- fenden Bereichen redundanzfrei überlappen. Beispielsweise wurde die Klasse für Bauteilquerschnitte in separate Klassen für geometrische und mechanische Parameter aufgeteilt.

Die Koexistenz fachübergreifender und fachspezifischer Daten wird außerdem durch Verer- bungsbeziehungen und die damit zusammenhängende Ebenenstruktur des Modells (beides neu gegenüber DtH 2.0) sowie durch Typ-Occurrence-Beziehungen (konsequenter als in DtH 2.0) unterstützt. Die Ebenenstruktur ist wie folgt festgelegt:

Gliederung des IFC-Metamodells in Ebenen

• Kern: gemeinsame abstrakte Konzepte,

• Interoperabilitäts-Ebene: gemeinsame konkrete Konzepte, 5 Ergebnis 11

• Domänen-Ebene: fachspezifische Konzepte,

• Ressourcen-Ebene: gemeinsame und fachspezifische Hilfskonstrukte.

Objekte der Ressourcenebene dienen lediglich der Abbildung von Eigenschaften der Objekte aus den drei anderen Ebenen. Folgerichtig besitzen Ressourcen-Objekte nicht die für die Änderungsverfolgung vorgesehenen Attribute, über welche die Klassen in Kern, Interoperabilitäts- und Domänen-Ebene aufgrund Vererbung grundsätzlich verfügen:

• GUID (global einmalige Identifikation): Anders als in DtH 2.0 wird ein Objekt nicht nur dateiweit, sondern räumlich und zeitlich global einmalig identifiziert. Dies ist eine Voraussetzung für das separate Erstellen, Verändern und Zusammenführen von Teilmodellen — nicht nur bei dateibasierter Datenhaltung sondern auch beim Einsatz von Produktmodellservern.

• Owner History (Bearbeitungs-Geschichte): Während in DtH 2.0 nur das Datum der letzten Änderung eines Objekts festgehalten wurde, werden nun Zeit der Erzeugung, Zeit der letzten Änderung, Art der Änderung, Autor der Änderung und „Besitzer“ des Objekts festgehalten.

Durch GUID und Owner History wird das Vergleichen von Planungsständen unterstützt. Auf dieser Basis können z.B. Anwendungen implementiert werden, die extern geänderte Teil- modelle auf neue, geänderte oder gelöschte Objekte abfragen und die Änderungen nach Prüfung durch den Nutzer (z.B. Planungs-Koordinator) in das Gesamtmodell übernehmen. Hier besteht hinsichtlich der praktischen Umsetzung des IFC-Modells allerdings noch Nach- holbedarf. Bisherige IFC-fähige Programme lesen und schreiben zwar bereits GUID und OwnerHistory, behalten deren Werte während der Bearbeitung des Modells häufig nicht bei.

Eine weitere Neuerung gegenüber DtH 2.0, die ebenfalls mit der Arbeit an Teilmodellen in Zusammenhang steht, sind „objektifizierte“ Beziehungen. Diese bilden Beziehungen zwischen Objekten nicht mehr als Attribut eines dieser Objekte ab, sondern führen gesonderte Objekte als Träger der Beziehung ein. Über Teilmodellgrenzen hinweg werden nur solche Beziehungsobjekte statt direkter Beziehungen verwendet. Änderungen an einem Teilmodell oder Herauslösen eines Teilmodells bedürfen dann nicht mehr des Zugriffs auf Attribute von Objekten in Teilmodellen, sondern nur noch der Anpassung entsprechender Beziehungsobjekte. Ein Beispiel solcher Beziehungen sind Zuweisungen vom Teilmodell Konstruktion zum Teilmodell Statik, anhand derer auch Konsistenzprüfung nach Änderungen in einem dieser beiden Teilmodelle möglich sind.

Ein weiteres Beispiel für „objektifizierte“ Beziehungen sind diejenigen der Konstruktion zur räumlichen Bauwerks-Gliederung: 5 Ergebnis 12

• Bauelemente umschließen Räume (wichtig für Regelprüfung oder Simulation in Bauphysik und Brandschutz);

• Gebäude oder Geschosse beinhalten Bauelemente (wichtig für logische Projekt- modellgliederung, lokale Koordinatensysteme, Bauablaufplanung und mehr).

Entsprechend letzterer Beziehung sind die Koordinaten der Bauelemente relativ zu lokalen Geschosskoordinatensystemen anzugeben, statt in globalen Koordinaten. Ferner sind Bauteile, aus denen ein Bauelement zusammengesetzt ist, im lokalen Koordinatensystem dieses Bauelements zu platzieren. Dies ist wichtig für die Vorfertigung von Bauelementen; beispielsweise ist bei Übergabe der Daten einer Wandtafel an die Steuerung einer Multifunk- tionsbrücke die Lage aller Rippen auf Wandtafel-Koordinaten zu beziehen.

Beispiel eines Bauteils und seiner Beziehungen im Datenmodell. Die meisten dieser Beziehungen sind selbst wieder Objekte.

Solche räumlichen Beziehungen und Aggregationen, aber auch Zuordnungen zu Akteuren oder zu Prozessen im Bauablauf, dienen auch der Erzeugung von Stücklisten für unterschiedliche Zwecke (Ausschreibung, Fertigungsplanung, Auslieferung usw.) anhand entsprechender Modell-Abfragen. (Beispiel einer Abfrage: Erzeuge eine Liste aller Kanthölzer im ersten Bauabschnitt.) Ferner stehen Gruppierungsbeziehungen für Stücklisten u.a. zur Verfügung.

Im übrigen sind Bauteile den Bauelementen nicht nur direkt, sondern im Falle von Wand- tafeln zunächst den Wandschichten zuzuordnen. Dies ist ebenfalls ein Erfordernis der automatisierten Fertigung der Elemente, ebenso wie die Abbildung der Verbindungen. Diese werden üblicherweise als Nagel- bzw. Klammerreihen hergestellt. In DtH 2.0 konnten Verbin- 5 Ergebnis 13 dungsmittelgruppen nur als Wolke der Eintrittspunkte abgebildet werden, nun steht auch eine parametrische Abbildung für Reihen zur Verfügung.

Wie schon in DtH 2.0 können im „Structural Timber Model“ verschiedene holzbautypische Bearbeitungen (Sägen, Fräsen, Hobeln, Applikation von Holzschutzmitteln u.a.) als separate Objekte abgebildet werden (sogenannte Bauteil-Features). Es wurde darauf geachtet,

• dass die verwendeten Datenstrukturen mit den Entsprechungen im Domänenmodell Stahlbau übereinstimmen und

• dass die aus den Bearbeitungen resultierenden Bauteilformen auch von IFC- Programmen gelesen werden können, welche die Holzbau-Erweiterungen nicht beherrschen.

Zwecks Interoperation mit domänenfremden Applikationen wurde auch die Möglichkeit vorgesehen, Verbindungsmittel parallel zu ihrer parametrischen Angabe (Produktnorm, Abmessungen, mechanische Einstufung u.dgl.) auch mittels expliziter Geometrie zu übertragen. Dies geschieht bei den meist vielfach eingefügten Verbindungsmitteln über Referenzen auf wiederverwendete Geometrie-Blöcke. Die explizite Geometrie ist außer während der interaktiven CAD-Bearbeitung der Holzbaukonstruktion auch zur Koordinierung z.B. mit dem Architekten und dem Haustechnik-Planer erforderlich.

Weitere Neuerungen betreffen die Modellierung moderner Holzwerkstoffe, wobei auf flexible, normenunabhängige Abbildung der Werkstoffeigenschaften geachtet wurde.

5.2.2 Zwischenversionen des Datenmodells

Um die Wirtschaftspartner einschließlich internationaler IAI-Partner bestmöglich einzubinden — wobei stark unterschiedliche Arbeitsfortschritte und Terminvorgaben der Partner auszugleichen waren — wurden außer den Milestones gemäß Verbundprojekt-Arbeitsplan zusätzliche Zwischenversionen an die Partner herausgegeben.

Beta 1, 03/2004 (Milestone M7): Die oben dargelegte Ebenen-Struktur bildete von Anfang an die Grundlage des Modells. Beta 1 des Datenmodells enthielt bereits vollständige Definitionen benötigter Klassen und Attribute von Baugruppen, Bauteilen, deren Bearbeitungen, Verbindungsmitteln, Baustoffen usw.. Die Definitionen wurden neben der grafischen Darstellung in EXPRESS-G vor allem auch vollständig in der präziseren Form EXPRESS angegeben und mit informellen Beschrei- bungen und Illustrationen dokumentiert.

Beta 2, 04/2004 Einige Unklarheiten der Beta 1 wurden ausgeräumt, teilweise Vereinfachungen vorgenom- 5 Ergebnis 14 men sowie aus IAI-Sicht bedenkliche produktions-bezogene Definitionen auf Konstrukte zurückgeführt, die den herkömmlichen IFC-Strukturen näher sind.

Beta 3, 05/2004 Das Modellkonzept für Bauteil-Bearbeitungen aus Beta 1 baute auf das vom Stahlbetonbau geprägten, aber unerprobten Feature-Konzept in IFC 2x2 auf. Aufgrund von Diskussionen mit den deutschen Industriepartnern wurde dieses Konzept verworfen und ein alternatives Featuremodell aus IFC 2x aufgegriffen. Damit gelang ein bei weitem einfacherer Übergang vom vorhergehenden Holzbau-Datenstandard DtH 2.0. Vor allem sind nun Prozesse der Holzbau-Detailplanung zutreffender abgebildet, was Vorteile hinsichtlich Integrität, Größe und Auswertung instantiierter Modelle bietet.

Diese Abweichung vom Stahlbetonbau-Featurekonzept fand bei Stahlbau-Vertretern in der IAI Unterstützung. Hier kam der Durchsetzung holzbaugerechter Konzepte zugute, dass zeitgleich ein Projekt zur IFC-Anpassung der „Produktschnittstelle Stahlbau“ des Deutschen Stahlbauverbandes sowie etwas später ein Projekt zur Übersetzung zwischen IFC und dem vom American Institute of Steel Construction unterstützten CIS/2-Standard stattfanden. Dort wurden ähnliche IFC-Erweiterungen benötigt, wie von uns vorgeschlagen. Die BTU Cottbus hat mit diesen Projekten engen Kontakt gehalten.

Release Candidate 1, 06/2004 (Milestone M8) Diese Version wurde als vorläufige Endversion ausgewiesen, um die Arbeitsgrundlage für Test-Implementierungen zu stabilisieren und dem Zeitplan des Verbundvorhabens gerecht zu werden.

Gegenüber Beta 3 wurden vor allem einige Klassennamen der Klarheit zugute geändert, z.B. um den Konflikt mit Stahlbetonbau-Features aufzulösen. Zur Dokumentation dieser Modell- version kamen eine Hypertext-Dokumentation einschließlich aller nicht dem eigentlichen Holzbaumodell zuzuordnenden IFC-Klassen hinzu, außerdem maschinenlesbare Fassungen der EXPRESS-Definitionen, sogenannte Kurzform- und Langform-Schemata. Letztere werden beim Compilieren von IFC-Ein-/Ausgabe-Bibliotheken verwendet.

Release Candidate 2, 10/2004 In diese Fassung flossen unterdessen erschienene Änderungen des allgemeinen IFC- Modells ein, außerdem einige Rückmeldungen von IAI-Partnern. Tiefgreifende Änderungen des Modells waren allerdings nicht mehr erforderlich.

Final Proposal, 12/2004 Hiermit wurden bereits einige Vorbereitungen zur Integration des Holzbau-Modells in das allgemeine IFC-Modell getroffen. Auch hier wurden keine bedeutsamen Änderungen 5 Ergebnis 15 gegenüber Milestone M8 mehr vorgenommen. Die eigentliche Integration (d.h. Abgleich mit den parallel laufenden IAI-Projekten und Ausgabe als neue IFC-Fassung) wird 2005 durch die IAI vorgenommen.

5.3 Erprobungsphase

Diese Phase beinhaltete das Implementieren in Anwendungssoftware bei den Industrie- partnern sowie Pilotanwendungen. Im Rahmen der Vorbereitungen zur Messe BAU und der Messepräsentation Januar 2005 in München wurden Gebäudedaten, die dankenswerter- weise vom Teilvorhaben 1 TU München zur Verfügung gestellt wurden, aus dem dort verwendeten Entwurfsprogramm ArchiCAD in die Programme von Nemetschek, Bocad und Cadwork übernommen.

Ein Geschoss des Musterhauses der TU München als IFC-Modell: Mit der Gebäudegeometrie sind Produktdaten verknüpft

Auch die verlustlose indirekte Weitergabe z.B. von ArchiCAD über Nemetschek zu Cadwork sowie weitere Detaillierung in Cadwork mit anschließender Übernahme in die Fertigungssi- mulation des Teilvorhabens 2 „Automatisierte und fertigungsoptimierte Produktionsprozesse“ der TU Braunschweig konnte eindrucksvoll gezeigt werden.

Musterhaus der TU München, in das Programm Cadwork 3D übernommen 7 Zusammenarbeit mit anderen Stellen 16

5.4 Transferphase

Dem Transfer dienen Dokumentation des Produktmodells und der Pilotanwendungen sowie die Bereitstellung von Hilfsmitteln zur Konformitätsprüfung. An der BTU wurde dazu die anliegende dreiteilige Dokumentation in englischer und deutscher Fassung erstellt, außer- dem eine HTML-Referenzdokumentation für Online- oder Offline-Zugriff mit Hyperlinks zwischen den Definitionen der zahlreichen Datentypen. Das Datenmodell wurde außerdem in EXPRESS sowie XSD (XML Schema Definition) aufbereitet. Diese Fassungen dienen als maschinenlesbare Vorlage zur Erzeugung von Ein-/Ausgabe-Routinen für den datei- oder auch modellserver-gestützen Austausch von IFC-Daten.

Im STEP-, IFC-, XML- und ifcXML-Umfeld stehen Software-Herstellern inzwischen eine Reihe von komfortablen Programmbibliotheken, Toolboxen und Viewern zur Verfügung. Durch Einbindung der EXPRESS- bzw. XSD-Schemata sind diese Tools in der Lage, mit den neuen Holzbau-Klassen umzugehen. An der BTU wurde u.a. die quelloffene STEP Class Library für syntaktische Tests der Modelldefinition und von Beispieldateien verwendet.

Weitere Transfermaßnahmen wurden und werden über die Deutsche Gesellschaft für Holzforschung im Teilvorhaben 4 des Verbundforschungsvorhabens und darüber hinaus durchgeführt.

6 Fortschritte auf dem Gebiet des Vorhabens bei anderen Stellen

Dank frühzeitiger Kontakte mit skandinavischen Interessenten und der IAI konnten der Standardisierung schadende Parallelentwicklungen vermieden werden.

7 Zusammenarbeit mit anderen Stellen

7.1 Zusammenarbeit im Teilvorhaben

Die Firmen Bocad Holz GmbH und Cadwork Informatik Software GmbH haben das Vorhaben aus Sicht des objektorientierten CAD/CAM, Friedrich + Lochner GmbH aus Sicht der Trag- werksplanung und Nemetschek AG aus Sicht der allgemeinen Hochbau- und Architektur- CAD-Planung betreut. TLConsulting hat die Harmonisierung mit IFC sichergestellt.

7.2 Zusammenarbeit im Verbundvorhaben

Von TU München, Lehrstuhl für Baurealisierung und Bauinformatik (Teilvorhaben 1 des Verbundvorhabens) wurden Möglichkeiten der Verzahnung der Gewerke und die Auswirkung auf Gebäudeentwurf und Abläufe in Fertigung und Errichtung untersucht. Daraus erwuchsen Anforderungen an das Datenmodell, insbesondere bezüglich verknüpfter Daten der Kon- 7 Zusammenarbeit mit anderen Stellen 17 struktion und des technischen Ausbaus. TU München hat außerdem Bauwerksdaten für Tests des Datenmodells zur Verfügung gestellt.

TU Braunschweig, Institut für Werkzeugmaschinen und Fertigungstechnik sowie Institut für Baukonstruktion und Holzbau (Teilvorhaben 2 des Verbundvorhabens) untersuchten die Simulation der Holzhaus-Vorfertigung und Optimierung der Produktion mittels angepassten Automatisierungsgrades, multifunktionaler Fertigungsstationen u.a. Maßnahmen in fertigenden Betrieben. Es wurden detaillierte Anforderungen ausgearbeitet, welche Information im Datenmodell enthalten sein muss, um als Eingang in die Fertigungssimulation oder auch realer Produktionssteuerungen zu dienen. In der Schlussphase des Projekts konnten mit in IFC vorliegenden Gebäudedaten des Teilvorhabens 1 Elementdaten und Stücklisten für die Fertigungssimulation des Teilvorhabens 2 gewonnen werden.

Die Deutsche Gesellschaft für Holzforschung (Teilvorhaben 4) koordinierte die Teilvorhaben und stellt durch umfangreiche Öffentlichkeitsarbeit den Transfer der Ergebnisse an die unterschiedlichen Zielgruppen sicher (Holzhaushersteller, Zimmereien, Planer, Software- anbieter u.a.m.), außerdem die Vernetzung mit Fachkreisen und Verbänden. Dies ist gerade für den Erfolg der Standardisierungsbemühungen im Teilvorhaben 3 von ausschlaggebender Bedeutung.

7.3 Zusammenarbeit mit IAI-Partnern

Im Rahmen der europäischen Vernetzungsaktivität der DGfH wurde das Datenmodell DtH bereits vor Jahren außerhalb Deutschlands, vor allem in Skandinavien, in Fachkreisen vorgestellt. Es bestand frühzeitig wechselseitiges Interesse an Harmonisierung von DtH mit IFC. Folglich wurde das Vorhaben bei der Industrieallianz für Interoperabilität (IAI) als IFC- Erweiterungsprojekt unter dem Code ST-5 „Structural Timber Model“ in Verantwortung des deutschsprachigen sowie des skandinavischen Zweigs der IAI angenommen. Während der Projektlaufzeit wurde intensiv über regelmäßige Meetings und internetbasierte Kollabora- tionsplattformen der IAI mit Firmen, Verbänden und Instituten aus Deutschland, Norwegen, Finnland, Schweden, UK und Australien im Projekt ST-5 zusammengearbeitet. Außerdem wurde ST-5 direkt mit Vertretern des abgeschlossenen IFC-Erweiterungsprojekts ST-3 (Massivbau/ Stahlbeton-Fertigteilbau), dem fortgesetzten Projekt ST-4 (Statik, Stahlbau) und dem angelaufenen Projekt ST-6 (Harmonisierung mit CIS/2, Statik, Stahlbau) abgestimmt. Dadurch wurden weitere deutsche, europäische, US-amerikanische und asiatische Partner direkt oder indirekt einbezogen.

Den deutschen Industriepartnern im Vorhaben „Produktmodell DtH — Durchgängiger Daten- transfer zur Minimierung des Ressourcenverbrauchs“ kommt diese offene internationale Zusammenarbeit in mehrerer Hinsicht zugute: Weltweite Akzeptanz der hier definierten 7 Zusammenarbeit mit anderen Stellen 18

Schnittstellen und somit Interoperabilität der deutschen Softwareprodukte auf ihren längst weltweiten Absatzmärkten werden sichergestellt. Die deutschen Partner können auf ihre Erfahrung aus der bisherigen Entwicklung des Produktmodells DtH nun auch im IFC-Umfeld aufbauen und verfügen damit über einen entscheidenden Wissensvorsprung.

7.4 Ereignisse

Koordinierungstreffen „Innovativer Holzsystembau“ 09.2003, Hameln, 18.09.2003

Teilnehmer: Partner des Verbundprojekts, Teilvorhaben 1 bis 4

Inhalt: u.v.a. Zielstellungen, Methodik, Arbeitsplan des Teilvorhabens 3; Anforderungen aus Teilvorhaben 1 und 2 an das Produktmodell

Treffen des Arbeitskreises Tragwerksplanung des IAI e.V., Nürnberg, 16.10.2003

Teilnehmer: Mitglieder der IAI (German speaking Chapter): Vertreter von Softwarehäusern im Bereich CAD und Tragwerksplanung; Vertreter der IAI Model Support Group und Implementation Support Group; Universitäten Karlsruhe, Dresden, Cottbus

Inhalt: u.v.a. Bericht über Fortschreibung von DtH als IFC-Domänenprojekt „Structural Timber Model“, Zielstellung, Koordinierung mit anderen IAI-Projekten

Arbeitstreffen „Innovativer Holzsystembau“, Braunschweig, 27.11.2003

Teilnehmer: Partner des Verbundprojekts, Teilvorhaben 2 bis 4, sowie Fa. Weinmann- Partner 7 Zusammenarbeit mit anderen Stellen 19

Inhalt: Möglichkeiten und Defizite von bisherigen Integrationslösungen, DtH und IFC auf dem Gebiet der CAD-CAM-Kopplung

Besprechung mit Weinmann Holzbausystemtechnik GmbH, St. Johann-Lonsingen, 29.01.2004

Teilnehmer: EDV-Abteilung der Fa. Weinmann; BTU Cottbus

Inhalt: Dateninhalte und technologische Basis für Datentransfers aus Sicht der Produktionsausrüstung und -steuerung einerseits und der bauprojektweiten Produktmodellierung andererseits, Möglichkeiten und Grenzen der Standardisierung

Europäisches Treffen der IAI-Arbeitsgruppe Tragwerksplanung, Karlsruhe, 22.03.2004

Teilnehmer: Mitglieder der IAI, des DSTV, der DGfH (BTU Cottbus)

Inhalt: Anwendungsszenarien des IFC-Datenmodells innerhalb der Tragwerksplanung und in Kooperation mit anderen Disziplinen in Bauprojekten, Abgleich der laufenden IAI-Projekte, v.a. zur Stahlbaudetaillierung und zum Holzbau-Modell

Arbeitstreffen Teilvorhaben 3 „Durchgängiger Datentransfer...“, Stuttgart, 30.04.2004

Teilnehmer: Vertreter der Firmen Bocad, Cadwork, Friedrich + Lochner; BTU Cottbus

Inhalt: Besprechung von Ziel und Ablauf des Projekts, Detailfragen zur Modell- konzeption

Koordinierungstreffen „Innovativer Holzsystembau“, München, 03.05.2004

Teilnehmer: Partner des Verbundprojekts

Inhalt: Ergebnisse in den Teilvorhaben, Koordinierung des Verbundprojekts

8th World Conference on Timber Engineering WCTE 2004, Lahti/Finnland, 14.–17.06.2004

Teilnehmer: >500 Teilnehmer aus der Holzbauforschung und -industrie aus 42 Ländern

Das Vorhaben „Durchgängiger Datentransfer...“ wurde als Paper und Konferenzvortrag vorgestellt.

IAI ST-5 Meeting, Helsinki/Finnland, 18.06.2004

Teilnehmer: Mitglieder der Finnish Forest Industries Federation; BTU Cottbus 7 Zusammenarbeit mit anderen Stellen 20

Inhalt: Ziele, Ablauf und Zwischenergebnisse der Projekte „FinnTimber-IFC“ und „Durchgängiger Datentransfer...“ innerhalb des IAI-Projekts ST-5 „Structural Timber Model“

Europäisches Treffen der IAI-Arbeitsgruppe Tragwerksplanung, München-Unterschleißheim, 13.09.2004

Teilnehmer: Mitglieder der IAI; BTU Cottbus

Inhalt: u.v.a. Entwicklungsstand des IFC-Datenmodells und Weiterentwicklungen für Stahlbau und Holzbau, Implementierungen für Tragwerksplanung

Koordinierungstreffen „Innovativer Holzsystembau“, München, 21.09.2004

Teilnehmer: Partner des Verbundprojekts

Inhalte: Ergebnisse in den Teilvorhaben, Koordinierung des Verbundprojekts, Planung der Transfermaßnahmen

KWF-Workshop „ELDAT in der Praxis“, Groß-Umstadt, 28.10.2004

Teilnehmer: Implementoren und Anwender des Standards ELDAT für die Forstwirt- schaft und holzverarbeitende Industrie; BTU

Inhalte: Weiterentwicklung des Standards ELDAT, Standardisierung des Informations- austauschs in der Forstwirtschaft und den anschließenden Branchen

Messe BAU 2005, München, 17.–22.02.2005

Messepräsentation von IFC am Stand von DGfH/ Holzabsatzfonds

Europäisches Treffen der IAI-Arbeitsgruppe Tragwerksplanung, Budapest, 18.02.2005

Teilnehmer: Mitglieder der IAI; BTU Cottbus

Inhalt: u.v.a. Aufbau des Structural Timber Model, Implementierung von IFC in CAD/CAE für Tragwerksplanung

Messe Ligna+ 2005, Hannover, 02.–06.05.2005

Messepräsentation von IFC am Stand von DGfH/ Holzabsatzfonds

Anmerkung: Dem BMBF-geförderten Budget des Vorhabens wurden keine Mittel für Konferenzteilnahme oder Auslandsreisen entnommen. Messebeteiligungen wurden vom Holzabsatzfonds (Absatzförderungsfonds der deutschen Forst- und Holzwirtschaft AöR) unterstützt. 8 Voraussichtlicher Nutzen, Verwertbarkeit des Ergebnisses 21

8 Voraussichtlicher Nutzen, Verwertbarkeit des Ergebnisses

Die Baubranche in Deutschland ist unter anderem gekennzeichnet durch

• organisatorische Trennung von Planern verschiedener Disziplinen und Bauausführenden, dadurch extensiver Kommunikationsbedarf über Unternehmensgrenzen hinweg,

• Rückgang von Neubautätigkeit, Zunahme von Um- und Ausbau,

• geringer Marktanteil des Holzbaus mit teilweise unflexiblen Stamm-Märkten.

Der Holzbau allgemein bzw. der Holzsystembau muss sich weitere Tätigkeitsfelder im Neu-, Um- und Ausbau erschließen, um seine Wettbewerbsfähigkeit zu verbessern. Dies liegt auch im Interesse der Sicherung lokaler Arbeitsplätze in mittelständischen Strukturen sowie der Förderung nachhaltigen Bauens. Zu diesem Zweck müssen Holzbau-Fachplaner und Holzbau-Unternehmungen unter anderem in der Lage sein, Projektinformation umfassend, schnell und unter Vermeidung von Fehlerquellen (insbesondere von redundanter Eingabe und Datenhaltung) — mit anderen Worten: kostengünstig und risikoarm — mit anderen an Bauprojekten Beteiligten auszutauschen bzw. gemeinsam zu nutzen.

Rationalisierung durch vereinheitlichte Schnittstellen und zentrale Datenhaltung

Gemeinsame Nutzung von Projektinformation ist auch die Grundvoraussetzung für umfassende Bauwerks-Optimierung, um die Anforderungen des Bauherren qualitätsgerecht, kostengünstig und ökologisch optimal zu erfüllen. Hieraus und aus o.g. Situation heraus ergibt sich die Forderung nach einem interdisziplinären, offen standardisiertem Produkt- datenmodell, wie es bislang und auch in absehbarer Zukunft allein auf IFC-Basis realisierbar ist.

Die Voraussetzungen zur Umsetzung sind dabei aus heutiger Sicht günstig:

• Alle wichtigen CAD-Programme des allgemeinen Hochbaus ermöglichen die Arbeit mit Bauwerksmodellen und unterstützen Ein- und Ausgabe von IFC.

• Wichtige CAD-Programme des Holzbaus arbeiten ebenfalls mit räumlichen objektorientierten Datenmodellen. Zwei in Deutschland und international wichtige Holzbau- 8 Voraussichtlicher Nutzen, Verwertbarkeit des Ergebnisses 22

CAD-Hersteller haben im Projekt mitgewirkt und IFC-Anbindung implementiert, ebenso ein wichtiger skandinavischer CAD-Anbieter.

• Datenmodelle der Gebäudeplanung einerseits und der Fertigung (CAM) andererseits bewegen sich aufeinander zu. Ein skandinavischer Anbieter von Fertigungs-Anlagen für den Holzsystembau beabsichtigt, IFC in Bälde umzusetzen. Ein wichtiger deutscher Anbieter verfolgt vorerst noch, in welchem Tempo IFC auf der CAD-Seite Verbreitung findet.

Nicht verschwiegen werden sollten einige Hemmnisse, die die breite Anwendung eines gemeinsam genutzten Produktdatenmodells wie IFC derzeit noch erschweren. So ist durchgängige objektorientierte (dreidimensionale) Planung aufgrund Gewohnheiten, Kenntnissen und Fertigkeiten der Anwender derzeit noch nicht konsequent und disziplin- übergreifend umgesetzt. Bestehende Anwenderprogramme müssen den Leitgedanken der Bauwerks-Modellierung noch effizienter und anwendernäher verwirklichen. Zügiges Erstellen der Modelle in der Frühphase von Bauprojekten, die Pflege des Modells im Projektverlauf, die Arbeit mit Teilmodellen und das Synchronisieren veränderter Teilmodelle bedürfen noch erweiterter Funktionalität bisheriger CAD/CAE-Anwendungen bzw. neuer Typen von Anwender-Programmen und auch Server-Software. Fragen des Vertragsrechts, der Vergütung von Planungsleistungen sind noch zu verfolgen.

Im Umfeld der in DGfH bzw. IAI eingebundenen Software-Anbieter wird im Jahr 2005 der Schwerpunkt auf der praktischen Umsetzung der Planungs-Koordinierung mittels IFC liegen. Die IAI wird Ende 2005/ Anfang 2006 neue Zertifizierungsrunden durchführen, in denen der Informationsfluss zwischen allgemeinen bzw. Architektur-CAD-Anwendungen und Ingenieur- CAD-Anwendungen eine maßgebliche Rolle in der Konformitätsprüfung spielen wird. Somit wird durchgängige Weiternutzung von Planungsdaten insbesondere in der Entwurfs-, Detail- bzw. Werkplanung ermöglicht. 9 Erfolgte und geplante Veröffentlichungen 23

9 Erfolgte und geplante Veröffentlichungen

Osterrieder, P., Richter, S., Fischer, M., A Product Data Model for Design and Fabrication of Timber Buildings, Proceedings of the 8th World Conference on Timber Engineering, wcte 2004, Lahti, Finland, ISSN 0356-9403, ISBN 951-758-443-1

Osterrieder, P., Richter, S., Durchgängiger Datentransfer. In: Rationalisierungspotential im Holzbau — Planung, Fertigung, Auf- und Ausbau. DGfH 2005

Fischer, M., Timmermans, J., Armbrecht, Ch., Richter, S., Mit Schnellverbindern in die Zukunft. In: Mikado, Organ des BDZ und EVH, Kissing, 4/2005, ISBN 3-8277-3370

Osterrieder, P., Richter, S., IFC-Standard für den Holzbau. DGfH 2005

Cottbus, Juli 2005 Prof. Dr.-Ing. Peter Osterrieder, Dipl.-Ing. Stefan Richter

IAI-Projekt ST-5 Structural Timber Model

Teil I Anforderungen

Prof. Dr.-Ing. Peter Osterrieder, Dipl.-Ing. Stefan Richter Lehrstuhl Statik und Dynamik Brandenburgische Technische Universität Cottbus [email protected]

Deutsche Übertragung von „Part I: Requirements“

Version: 1.final Status: proposal 31. Dez. 2004 Danksagung Dieses Dokument basiert auf der Arbeit der IAI-Projektgruppe ST-5 und des Forschungsvorhabens „Innovativer Holzsystembau durch optimierte Fertigungs- und integrierte Planungsmethoden; Teilvorhaben 3: Produktmodell DtH“. Das DtH- Projekt wird an der Brandenburgischen Technischen Universität Cottbus, Lehrstuhl Statik und Dynamik unter Ägide der Deutschen Gesellschaft für Holzforschung DGfH mit Mitteln des Bundesministeriums für Bildung und Forschung von Juli 2003 bis Dezember 2004 unter dem Kennzeichen 0330424 ausgeführt.

Inhalt 3

Inhalt 1 Zusammenfassung 4 Änderungen...... 4 Abkürzungen...... 5 2 Einführung 6 2.1 Motivation der Produktmodellierung...... 6 2.2 Existierende Produktmodelle...... 7 2.2.1 STEP...... 7 2.2.2 IFC...... 8 2.2.3 DtH ...... 8 2.2.4 Produktmodell-Entwicklungen in verwandten Branchen ...... 9 2.2.5 Datenmodelle für Fertigung von Holzbau-Komponenten ...... 11 2.3 Integration von DtH in IFC...... 12 2.4 Das Konzept der Teilmodelle ...... 15 3 Anforderungen 16 3.1 Anwendungsbereich des Structural Timber Model ...... 16 3.1.1 Anwendungsbereich nach Baubranchen...... 16 3.1.2 Anwendungsbereich nach Akteuren, Disziplinen...... 16 3.1.3 Anwendungsbereich nach Projektphasen ...... 17 3.2 Vertikales und horizontales Daten-Sharing, Modell-Evolution...... 17 3.3 Anforderungen nach Akteuren, Disziplinen ...... 18 3.3.1 Architekt...... 18 3.3.2 Tragwerksplaner ...... 19 3.3.3 Konstrukteur, Zeichner...... 20 3.3.4 TGA-Ingenieur ...... 20 3.3.5 Bauunternehmer...... 21 3.3.6 Zulieferer, Baustoffindustrie...... 21 3.3.7 Projektsteuerer...... 22 3.3.8 Bauherr ...... 22 3.3.9 Behörden...... 23 3.4 Anforderungen nach Projektphasen...... 23 3.4.1 Bauprozesse...... 23 3.4.2 Anwendungsfall: Vom Anforderungs-Management zur Planung...... 24 3.4.3 Anwendungsfall: Zwischen Planern ...... 25 3.4.4 Anwendungsfall: Produktinformation des Herstellers/ Lieferanten zu Planern...... 26 3.4.5 Anwendungsfall: Vom Entwurf zur Werkplanung...... 27 3.4.6 Anwendungsfall: Zwischen Projektsteuerung, Ausführung und Zulieferung...... 28 3.4.7 Anwendungsfall: Allgemeine Projektsteuerung ...... 29 3.4.8 Anwendungsfall: Von Planung und Ausführung zu Nutzung und Wartung...... 30 3.4.9 Anwendungsfall: Zwischen Nutzung und Wartung...... 31 4 Übersicht über DtH 2.0 32 4.8 Lücken in DtH 2.0...... 32 4.8.1 Fehlendes TGA-Modell...... 32 4.8.2 Eingeschränktes Fertigungsmodell...... 32 5 Anhang 34 5.1 Literatur...... 34 5.2 Abbildungsverzeichnis...... 35 4 IAI-Projekt ST-5 — Structural Timber Model — Teil I: Anforderungen

1 Zusammenfassung Dieses Dokument behandelt die Integration eines Produktmodells für Holzbauten in die Industry Foundation Classes der International Alliance for Interoperability (IAI). Kapitel 2 des Dokuments umreißt die Anforderungen der Holzbau-Industrie an das Produktdatenmodell und vergleicht vorhandene Datenmodelle. Die Integration von DtH in IFC wird kommentiert, und das beiden Modellen zugrundeliegende Konzept der Teilmodelle wird definiert. Kapitel 3 beschreibt den angestrebten Anwendungsumfang des Structural Timber Model und identifiziert die in Holzbauprojekten auszutauschende Information. Die wichtigste Basis für das Structural Timber Model, der gegenwärtige DtH-Stan- dard, wird in Kapitel 4 erläutert. (Siehe [5] für die komplette Standardbeschreibung.) Lücken in DtH sowie Unterschiede zu IFC werden angesprochen. Dem Dokument folgen die Teile „Structural Timber Model – Part II: Schema Refe- rence” (Klassen-Referenz) und “Part III: Implementation Guide” (Implementierungs- hilfe).

Änderungen rev 1.final 31. Dezember 2004 Dokument von „Übersicht“ zu „Anforderungen“ umbenannt Abschnitt 2.2.4 erweitert rev 1.rc1 02. Juli 2004 zahlreiche Aktualisierungen und Bearbeitungen in Kapitel 2 Abschnitt 3.4 mit Material des Projekts FinnTimber-IFC neugefasst Abschnitt 2.2.5 hinzugefügt, Abschnitt 4.6 erweitert rev 1.β3 06. Nov. 2003 Abbildungen und Vergleiche zu PSS in Abschnitt 4 hinzugefügt rev 1.β2 30. Sep. 2003 Abschnitt 2.2.4, Abb. 2-3, 2-5, 4-8 hinzugefügt Klärungen in den Abschnitten 3.4 und 4, Abschnitt 4.8 erweitert rev 1.β1 03. Sep. 2003 erster Entwurf 1 Zusammenfassung 5

Abkürzungen AEC architecture, engineering, and construction (Architektur, Ingenieurwesen, Baugewerbe) AVA Ausschreibung, Vergabe und Abrechnung CAD/CAM computer aided design, computer aided manufacturing CIS CIMsteel Integration Standards DIN Deutsches Institut für Normung e.V. DtH Datentransfer im Holzbau FM facility management HVAC heating, ventilation, air conditioning (Heizung, Lüftung, Klima) IAI International Alliance for Interoperability IFC Industry Foundation Class(es) ISO International Organization for Standardization ISO PAS ISO Publicly Available Specification LCA/LCC life cycle assessment (Ökobilanz), life cycle cost analysis LVL laminated veneer lumber, ein orthotroper Holzwerkstoff für balkenartige Anwendung OSB oriented strand board, ein orthotroper Holzwerkstoff für platten- und scheibenartige Anwendung PSS Produktschnittstelle Stahlbau SIP structural insulated panel, ein Sandwich aus OSB und Schaumkunststoff-Kern SLP service live planning STEP Standard for the Exchange of Product Data STLB Standardleistungsbuch für das Bauwesen VNP vertical nailed planks, Brettstapel, eine massive Holzbauweise

6 IAI-Projekt ST-5 — Structural Timber Model — Teil I: Anforderungen

2 Einführung

2.1 Motivation der Produktmodellierung Steigende Lohnkosten, Mangel an ausgebildeten Arbeitskräften, Konsolidierung des Baugewerbes, Forderung nach höherer Produktqualität und ressourcenschonendem Bauen — all dies treibt Bestrebungen nach industrialisiertem Bauen voran. Mehr und größere Baugruppen werden vorgefertigt, der Anteil automatisierter Fertigung steigt. Vorfertigung und Automatisierung sind von grundlegender Bedeutung für die Wett- bewerbsfähigkeit des Holzbaus im Vergleich zu Massiv- und Stahlbau. Andererseits sind anpassungsfähige Gebäudeentwürfe und hohe Grade technischer Ausstattung gefragt. Entsprechend werden neue Bauweisen und Bausysteme entwickelt. Hieraus erwachsen neue Herausforderungen für die Bauplaner. Die verschiedenen Planungsphasen müssen stärker integriert werden; Planung und Kommunikation der Planer müssen zeit- und kosten-effizienter werden. Dies ist besonders bedeutsam für den Holzbau: Einerseits bedarf er einer detaillierteren Planung und einer engeren Kopplung von Planung und Ausführung als im Massivbau üblich. Andererseits begegnet man im Holzbau einem vielfältigeren Mix traditioneller und moderner Bauweisen als im Stahlhochbau. Mit herkömmlichen Lösungen für den elektronischen Datenaustausch sind diese Anforderungen nicht mehr abzudecken (Abb. 2-1). Sie decken stets nur Teilgebiete der Planung und Ausführung ab und sind somit nicht geeignet, einen durchgängigen Informationsfluss herzustellen. Projektdaten werden über unzusammenhängende Dokumente in verschiedenen Formaten weitergegeben, die kaum synchron gehalten werden können. Zusätzlich erschweren proprietäre Formate die Implementierung und gefährden langfristig Zugriff auf die Daten.

Abb. 2-1 Datenaustausch über her- Abb. 2-2 Gemeinsame Datennutzung kömmliche Schnittstellen über ein Produktmodell Architect Architect Engineer Bldg.Services Engineer Bldg.Services Product Model Work Prep. Draftsman Work Prep. Draftsman

Machine A Machine B Machine A Machine B

Daher wird ein neues Datenmodell benötigt, welches sämtliche Gebiete der Bau- planung und Ausführung gleichermaßen abdeckt. Dieses Modell ist mit Blick auf das Produkt (das Bauwerk) statt mit Blick auf einzelne Applikationen zu entwickeln; man spricht daher von einem Produktmodell. Einige der Vorteile dieses Ansatzes sind un- mittelbar aus Abb. 2-2 ersichtlich: Die Anzahl an Schnittstellen sinkt. Alle Kommuni- kations-Endpunkte sind gleich gut angebunden. Redundanzen und somit Fehler- 2 Einführung 7 quellen werden verringert. Planungsänderungen werden schneller weitergegeben, dabei entstehende Konflikte können zeitiger aufgedeckt und bereinigt werden. Darüber hinaus werden Bau- und Ausführungsplanung in der Produktmodellierung als interdisziplinäre Optimierungsaufgabe verstanden. Das Ziel ist ein Produkt, welches dem Auftraggeber größtmöglichen Wert innerhalb gegebener Kosten-, Zeit- und anderer Restriktionen liefert. Das Produktmodell unterstützt die Optimierung, indem es einen ganzheitlichen Blick auf das Projekt gestattet. Information über alle Aspekte, die das Optimum beeinflussen, werden zusammengeführt. Ein Produktmodell erfüllt typischerweise folgende Kriterien: • Information steht im Kontext. So, wie man es von einer fachgerechten Bauzeichnung erwartet, sollen die elektronisch übermittelten Daten klare Bedeutung besitzen und die Intentio- nen des Planers widerspiegeln. Beziehungen zwischen verschiedenen Aspekten des Projekts werden verdeutlicht. • Systemunabhängigkeit wird gewahrt. Systemunabhängigkeit geht weiter als Computer-Plattformunabhängigkeit. Die Strukturierung von Projektdaten soll nicht einseitig anhand einer Software, Disziplin oder eines Prozesses organisiert werden. Statt dessen ist die große Vielfalt and Planungs- und Bauprozessen und der dabei verwendeten Hilfsmittel von vornherein zu berücksichtigen. Dies führt letztendlich zu einem Fokus auf das Produkt anstatt eines Fokus auf eine Applikation. • Während des gesamten Projekts erfolgt Informationszuwachs. Planen bedeutet Lernen und Problem-Lösen. Zuvor generierte Information ist zu erfassen, zu ergänzen und zu berichtigen, während das Projekt fort- schreitet. Das Datenmodell muss diese iterativen Prozesse unterstützen. Sukzessive Planungsphasen verwenden vorhandene Information weiter und akkumulieren neu generierte Information. • Datenformate sollen nicht proprietär sein. Konformität ist zu prüfen. Die Mittel und Wege, Information elektronisch weiterzugeben sind neutral zu entwickeln und offen zu publizieren. Implementierungen sind mittels festgelegter Prozeduren auf Konformität zu testen.

2.2 Existierende Produktmodelle

2.2.1 STEP Die Standard-Familie ISO 10303 alias STEP [1] gibt Methoden und Modelle für Repräsentation und Austausch von Produktdaten in einer Vielzahl von Branchen an. STEP besteht im Wesentlichen aus • Beschreibungs-, Implementierungs-, Testmethoden, • generischen Modellen (common resources), • spezialisierten Modellen (Application Protocols, ergänzt durch Application Modules). 8 IAI-Projekt ST-5 — Structural Timber Model — Teil I: Anforderungen

Die STEP-Dokumentation wird kostenpflichtig durch nationale Standardisierungs- Institutionen vertrieben. Implementierungshilfen sind in Form zahlreicher kommer- zieller Entwickler-Tools und Datenmanagement-Lösungen, aber auch mit der freien STEP Class Library des NIST verfügbar.

2.2.2 IFC Nach verschiedenen Ansätzen im Rahmen der ISO und des STEP-Standards wurde klar, dass weder die Standardisierungsprozesse der ISO noch der anfänglich mono- lithische Ansatz der STEP Application Protocols den Anforderungen der multi- disziplinären Bauindustrie gerecht wird. Dies führte zur Entwicklung der Industry Foundation Classes [2] als Industriestandard (im Gegensatz zu einem sogenannten formalen Standard). Die IFC wurden von vornherein mit Blick auf interdisziplinäre Zusammenarbeit konzipiert. Die IFC sind schichtenweise gegliedert in • gemeinsame Ressourcen, • Kern, • Interoperabilitäts-Schicht (interdisziplinär), • Domänen-Schicht (spezialisiert auf Disziplinen). Die IFC setzen auf die untersten STEP-Ebenen auf (STEP-Teile 11, 21) und verwenden Teile der mittleren STEP-Ebene in der Ressourcen-Schicht (STEP-Teile 41, 42, 43). Der zurückgezogene Entwurf zu STEP Teil 106 „Building Construction Core Model“ war eine der Grundlagen der IFC-Entwicklung. Das IFC-Modell unterstützen in den ersten Versionen Architektur, Technische Gebäudeausrüstung, Facilities Management und Kostenermittlung. In neueren Versionen kamen Grundlagen der Ingenieurplanung sowie weitere TGA- und FM- Elemente hinzu. Implementierungs-Support und Zertifikation ist unter Bedingung der IAI-Mitgliedschaft möglich. Software-Toolboxen für STEP sowie speziell für IFC stehen zur Verfügung (z.B. EPM Technology EXPRESS/IFC Toolbox, Eurostep IFC Toolbox, oder QualiSTEP CSC). Abstraktionen wie die SABLE APIs des BLIS- Projekts sind in Entwicklung.

2.2.3 DtH DtH ist ein deutsches Produktmodell, das unter dem Dach der DGfH durch die BTU Cottbus und mehrere Software-Häuser entwickelt wurde. DtH hat gemeinsame Wurzeln mit PSS, dem deutschen Produktmodell für den Stahlbau [3]. PSS und DtH basieren auf STEP Teil 11 und 21. Anwendungsbereiche von DtH sind der Ingenieur- holzbau, Zimmermannsbau und Fertighausbau. DtH orientiert sich an Sichtweise und Sprache des Ingenieurs, Architekts und Bauausführenden. Die erste Fassung Version 1.05 (02.1996) enthielt drei Teilmodelle: Statik, Konstruk- tion, Kosten [4]. Mit Version 2.0 (12.1999) kamen das Teilmodell Architektur, Erweiterungen des Teilmodells Konstruktion und verbesserte STEP-Konformität hinzu [5]. DtH verwendet feature-basierte parametrische Bauteilbeschreibungen, um Erforder- nissen sowohl der Ingenieurplanung als auch der Fertigung gerecht zu werden. Wichtiges Prinzip ist geringe Redundanz sowohl auf Ebene des Modellkonzeptes als auch letztendlich in DtH-Dateien. Ein weiteres Merkmal von DtH ist seine geringe Komplexität; es werden z.B. keine Vererbungsbeziehungen verwendet. 2 Einführung 9

DtH-Dokumentation ist kostenfrei erhältlich. Implementierungssupport konnte lediglich im Rahmen der beiden zu den Versionen 1.0 und 2.0 führenden F&E-Vorhaben geleistet werden. DtH-Implementoren können seit DtH 2.0 STEP-Werkzeuge ein- setzen.

2.2.4 Produktmodell-Entwicklungen in verwandten Branchen Stahlbau Im Stahlbau sind das CIMsteel Logical Product Model (CIS/2 LPM, fortgeschrieben durch Steel Construction Institute, UK) und PSS des DSTV [3] gebräuchlich. Neuere Versionen des LPM decken außer statischer Berechnung, Konstruktion und Werk- planung von Stahltragwerken zu einem gewissen Grade auch generelle Prozesse des Bauwesens ab, namentlich Ablaufplanung und Kostenrechnung. In fachspezifischen Punkten wie dynamischer Berechnung oder Maßtoleranzen gehen die Fähigkeiten von LPM über die von IFC hinaus. Derzeit wird seitens des American Institute of Steel Construction die Möglichkeit des Mappings zwischen LPM und IFC untersucht. PSS ist ein Modell ähnlichen Anwendungsbereichs wie LPM bei geringerem Leistungsumfang. PSS ist dadurch weniger komplex und einfacher zu implementieren. PSS war die Hauptquelle für das IAI-Projekt ST-4, welches die Tragwerkspla- nungs-Domäne in IFC eingebracht hat. Die ST-4-Erweiterungen bilden eine wichtige Grundlage für das Projekt ST-5.

Proprietäre Produktmodelle in der Bauplanung Verschiedene Hochbau-CAD- und Stahlbau-CAD-Pakete basieren auf eigenent- wickelten Produktmodellen, auch als Building Information Models bezeichnet. Diese Modelle sind Ergebnis der Anwenderforderung nach enger Integration von CAD mit anderen branchenüblichen Anwendungen wie Mengenermittlung, Berechnungspro- gramme und CAM. Anders als standardisierte Produktmodelle sind proprietäre Modelle auf hersteller- spezifische Lösungen beschränkt, welche Prozesse innerhalb des Rahmens einzelner Unternehmen (Planungsbüros oder Ausführende) integrieren.

Möbelindustrie Im europäischen Projekt funSTEP wurde ein Application Protocol für die Möbel- industrie entwickelt, das derzeit zur Aufnahme als ISO 10303 Teil 236 vorbereitet wird. FunSTEP greift auf zahlreiche Teile der unteren und oberen Schichten von ISO 10303 zurück. Hauptzweck von funSTEP ist der Austausch von Produktdaten zwischen Möbel-Herstellern, -Vertrieb und Einrichtungs-Designer. Es werden abgedeckt: • Produktdefinition, Produktkataloge, einfache und komplexe Möbel, • Geometrie, Maße, Parameter, Konfiguration, Qualität, Zubehör, Preise, • Inneneinrichtung, Raumdefinition und -darstellung, Möbelplatzierung. Zwar überschneiden sich IFC und funSTEP in gewissem Maße hinsichtlich der Beschreibung von Möbeln als Ausstattungsgegenstand, jedoch gibt es keine Über- schneidung hinsichtlich der Herstellung, namentlich der Holzbearbeitung. Während die ST-5-Erweiterungen für IFC auch zerspanendes Bearbeiten und Fügen von Holz- werkstoffen berücksichtigt, gibt es in funSTEP keine Vorkehrungen für die Integra- tion von Detailplanung und Fertigung. 10 IAI-Projekt ST-5 — Structural Timber Model — Teil I: Anforderungen

Abb. 2-3 Geschichtliche Einordnung von Produktmodellen1

1.05

DtH Datentransfer im Holzbau

DtH 2.0

DGfH

04.2000

PSS Produktschnitt- stelle Stahlbau

Ein Produktmodell PSS für den Stahlbau (Haller)

DSTV NC protocol DSTV uniform material designations DSTV interface between structural analysis and CAD

DSTV

ST-5

ST-1 ST-4

oun-

ST-4.2

ST-6

IAI

IFC Industry F dation Classes

IFC 1.0 IFC 1.5.1 IFC 2.0 IFC 2x ifcXML IFC 2x2

finished started

SCI

CIS/2.1

CIS/1.0 CIMsteel Integration Standards

CIMsteel CIS/1 Computer Inte CIS/2 grated Manu- facturing for Constructional Steelwork

Eureka program

- building elem.

225 228 230 106

STEP)

XBF

interoperability models in the works

ISO 10303-225 IS published

ISO

PDES STEP initial ISO 10303 parts 1, 11, 21 etc circa 30 APs in the initial proposed standard (pt.201 - 2D release: drawing works, e.g Product Data pt.203 - 3D drawing Standard for the pt. Exchange Exchange of Product pt. - HVAC Specification Model Data pt. - steel frames pt. - BCCM (bldg constr. core model)

'Echange

CADLIB

Transfert

Freiform-

Schnittstelle

et de

CALS

Standard d

flächen-

VDA-PS

VDA-FS

SET

ATLAS project

COMBI project

DIN

Esprit program

AFNOR

1.0

IGES IGES 3.0 IGES 6.0 Initial Graphics Exchange Specification

ANSI

ICAM program

U.S.AF

1973 1980

1982

1984

1986

1987

1988

1991

1993

1994

1995

1996

1997

1998

1999

2000

2001

2002

2003 2004

1 [9], [10], [11], [12] 2 Einführung 11

Forstwirtschaft 2002 wurde der deutsche Schnittstellenstandard ELDAT herausgegeben, welcher Kriterien eines Produktmodells weitgehend entspricht. Der Standard dient dem Austausch von Rohholz-Produktdaten (Holzlisten, Werkmaßprotokolle) einschließ- lich Vertrags-, Rechnungs- und Lieferdaten zwischen Waldbesitzern, Holzabnehmern (insbesondere Sägewerke und Zellstoffindustrie), Holzhändlern, Einschlagunter- nehmen und Speditionen. Der Standard ist auf dateibasierten Datenaustausch mittels kommagetrennter Textdateien oder XML-Dateien orientiert. Das Datenmodell besteht aus einem Dutzend Entitäten mit einer großen Anzahl Attribute. Dazu gehört ein umfangreiches kontrolliertes Vokabular. Die Anwendungsfälle und Informations- inhalte von ELDAT und DtH / IFC Structural Timber Model überlappen sich derzeit noch nicht, könnten sich aber auf lange Sicht in Berührungspunkten treffen.

2.2.5 Datenmodelle für Fertigung von Holzbau-Komponenten Europäischer und nordamerikanischer Holzbau sind geprägt durch steigende Anteile von Vorfertigung unter Einsatz numerisch gesteuerter und halbautomatischer Produk- tionsanlagen. Dementsprechend sind Werkplanung und Fertigung eng gekoppelt. Zwei Beispiele für weithin eingesetzte Integrationslösungen werden nachfolgend besprochen. Von Seiten der CAD-Softwarehäuser besteht das Interesse, die diversen Daten- modelle durch einen Standard wie DtH oder IFC zu ersetzen. CAM-Integratoren haben jedoch bisher wenig Interesse an offenen Lösungen gezeigt. Die nordamerika- nische Initiative WINStep (Wood Industry Standard for the Exchange of Product data), die sich aus einigen CAD-Häusern und Maschinen-Lieferanten zusammensetzt, möchte die Situation durch ein einheitliches Protokoll für CAD/CAM-Integration in der Holzbearbeitung verbessern. Das Protokoll soll Produktdaten, Prozessdaten und Technologie-Daten abdecken. Eine Spezifikation ist derzeit noch nicht veröffentlicht.

Hundegger-Schnittstelle von CAD nach NC-Abbundmaschinen Die von Hans Hundegger Maschinenbau GmbH definierte Schnittstelle wird für Inte- grationslösungen zwischen Holzbau-CAD und Balkenbearbeitungszentren verwendet. Die Schnittstelle benutzt zeilenorientierte tabulierte Textdateien, d.h. mit festen Zeichenpositionen. Die Dateien enthalten im Wesentlichen • einen Kopf mit kurzer Projektangabe, • eine Liste aller zu fertigenden Balkenpositionen. Jede Position wird durch Stückzahl, Sortierklasse, parametrischer Rohteilmaße sowie Daten zu Paketierung und Einbauort beschrieben. • Jeder Balkenposition sind Bearbeitungen zugeordnet. Bearbeitungen werden als Maschinen-Makro identifiziert; d.h. der Bearbeitungstyp wird aus der Sicht der Funktionalität der Maschine bestimmt, nicht vom Standpunkt der Bauteilform. • Bearbeitungen werden parametrisch definiert; die Bedeutung der Parameter hängt wiederum vollkommen vom jeweiligen Maschinen-Makro ab. Allerdings beschreiben die Parameter im Wesentlichen die Geometrie der Bearbeitung, nicht den genauen Pfad und die Geschwindigkeiten der Werkzeuge. Die Menge verfügbarer Makros hängt vom Maschinentyp und der Firmware-Revision ab. Mehr als 80 Makros können zur Auswahl stehen. Es sind also nicht nur Daten der 12 IAI-Projekt ST-5 — Structural Timber Model — Teil I: Anforderungen herzustellenden Bauelemente, sondern auch Wissen über Maschinenfunktionen und deren optimalen Einsatz erforderlich, um den Input für die Hundegger-Schnittstelle zu erzeugen. Allerdings wird kein eigentlicher NC-Code übermittelt.

Weinmann-Schnittstelle von CAD nach Holzrahmenbau-Anlagen Die von Weinmann Holzbausystemtechnik GmbH, SEMA GmbH und GranIT GmbH definierte Schnittstelle wird für CAD/CAM-Integrationslösungen im Holzrahmenbau verwendet. Die Schnittstelle verwendet zeilenorientierte Textdateien mit komma- getrennten Argumenten. Pro Datei wird eine Baugruppe beschrieben (Wand-, Decken-, Dach-Segment). Die Dateien enthalten im Wesentlichen • einen Kopf mit Parametern der Baugruppe als Ganzes, • eine Liste aller stabförmigen Bauteile mit ihrer Größe, Anordnung und Bearbeitungen, • eine Liste aller Beplankungen mit ihren Materialien, Form, Anordnung, Bearbeitungen und Nagelreihen. Die Schnittstelle basierte ursprünglich auf einem 2D-Koordinatensystem mit zusätz- licher Schichten-Information. Sie wurde jüngst um eine dritte Koordinate ergänzt, um auch komplexere Bausysteme abzudecken. Nahezu keine maschinenspezifische Infor- mation wird übertragen. Zwar existieren Schlüsselwörter für Sägen, Fräsen und Bohren, jedoch wird das eigentliche Werkzeug im Nachhinein durch die Firmware der Maschine gewählt. Wie bei der Hundegger-Schnittstelle werden Geometriedaten der herzustellenden Form übertragen, keine tatsächlichen Werkzeugwege.

2.3 Integration von DtH in IFC

Abb. 2-4 Anwendungsbereiche der gegenwärtigen IFC- und DtH-Standards

preliminary demolition design

conversion design, struct. building calculation lifecycle conservation detailing IFC use prefabrication 2x2 2.0 erection DtH

Nutzen Sowohl DtH als auch IFC basieren auf STEP und dem Konzept der Teilmodelle (siehe Abschnitt 2.4). Die derzeitige IFC-Spezifikation enthält extensive Unter- stützung für Architekturentwurf, technische Gebäudeausrüstung, Projekt-Steuerung und Facilities Management. Tragwerksplanung wird neuerdings hinsichtlich statischer Berechnung, nicht aber hinsichtlich (Holzbau-)Konstruktion unterstützt. Hingegen bietet sich DtH für statische Berechnung, Konstruktion und Werkplanung von Holzbauwerken an, während des auf anderen Gebieten des Bauwesens nicht oder kaum einsetzbar ist. Die Idee liegt daher nahe, DtH und IFC zu kombinieren. 2 Einführung 13

Der Nutzen eines Wechsels zu IFC besteht für existierende DtH-Implementierungen in Gewinn an Kommunikationsmöglichkeit mit allgemeinen Hochbau-CAD- und TGA-CAD-Anwendungen sowie in Einsatzfähigkeit über den deutschen Markt hinaus. Der Nutzen für IFC besteht in Vervollständigung des Anwendungsbereiches der IFC. Da DtH bereits implementiert und praktisch angewendet wurde, werden Definition, Dokumentation und Test der ST-5-Erweiterungen beschleunigt.

Strategie der Modellierung Diverse nötige Erweiterungen wurden bereits vom IAI-Projekt ST-4 „Structural Analysis Model and Steel Construction”2 und dem IAI-Projekt ST-3 „Precast Con- crete Construction” eingebracht, siehe Abb. 2-5. Dadurch wird es möglich, die ST-5- Erweiterungen in den oberen IFC-Ebenen separiert einzufügen.

Abb. 2-5 Erweiterungen zu IFC 2x durch die Projekte ST-3, ST-4, ST-53

Precast Archi- Construc- Structural Steel Timber HVAC Electrical FM Concrete tecture tion Mgmt Analysis Construction Construction Domain Domain Domain Construction Domain Domain Domain Domain Domain Domain Domain Layer

Shared Shared Shared Shared Shared Shared Bldg Bldg Services Spatial Management Facilities Building Elements Additions Elements Elements Elements Elements Elements Extension Interoperability Layer

IFC 2x platform Control Process Product Product ISO/PAS 16739 Exten- Exten- Exten- Exten. Additions non-platform part: sion sion sion Extn. next candidates Kernel out of platform IFC 2x ST-3 ST-4 ST-5 Core Layer project project project

Material Geometry ...... Resource Resource harmo- harmo- harmo- nization nization nization with BEC with PSS, with DtH Material Geometric Profile Measure Repre- Topology CIS/2 Property Model sentation Resource Resource Resource Resource Resource Resource

Resource Layer

Additions Geometric Profile Measure Repre- Topology Profile Structural Model Extension Extension sentation Extension Property Load Additions Extension Resource Resource Extension Resource Resource Resource

Die ST-5-Modellerweiterungen werden unter Beachtung folgender Regeln formuliert: • Tiefe Eingriffe in die IFC-Architektur sind zu vermeiden. Somit wird zügige Integration erreicht.

2 Dem Projekt ST-4 folgt derzeit ein Anschlussprojekt zur Definition von IFC-Erweiterungen der Stahlbau-Detaillierung.

3 Siehe [13] und [14]. Die ST-3- und ST-4-Vorschläge wurden größtenteils in IFC 2x2 übernommen. Ein neues Schema „Structural Elements Domain“ vereinigt die Stahl- und Stahlbetonbau-Domänen. Die Holzbau-Domäne soll ebenfalls Teil der Structural Elements Domain werden. 14 IAI-Projekt ST-5 — Structural Timber Model — Teil I: Anforderungen

• Funktionalitäten, die bereits in IFC verfügbar sind oder von anderen derzeit laufenden IAI-Projekten bereitgestellt werden, sollen nicht dupliziert werden. • Kompatibilität zu anderen Domänen der Tragwerks- und Detailplanung (Stahlbau, Stahlbetonbau, Stahlbetonfertigteilbau) ist zu erzielen. • Unabhängigkeit von Produkt- und Bemessungsnormen ist zu wahren. • Die komplette Funktionalität des DtH-Modells ist zu erhalten (sofern nicht Einverständnis über Hinfälligkeit bestimmter Strukturen besteht).

Grenzen der DtH/IFC-Harmonisierung Aus verschiedenen Gründen — allein schon wegen Namenskonventionen — werden IFC-Dateien, welche die künftigen Holzbau-Erweiterungen nutzen, nicht kompatibel zu DtH-Dateien sein. Trotz Inkompatibilität auf Datei-Ebene wird allerdings Aufwärtskompatibilität auf Modellebene bestehen, da das Structural Timber Model eine Übermenge des DtH-Modells sein wird. Es dürfte daher beispielsweise möglich sein, DtH-Dateien in IFC-Dateien zu konvertieren. 2 Einführung 15

2.4 Das Konzept der Teilmodelle Zwecks breiter und internationaler Anwendbarkeit in der Bauindustrie wird das Produktmodell in Teilmodelle gegliedert (siehe [8], Abschnitt 2). Im Folgenden werden die Begriffe • Architekturmodell, • Statikmodell, • Konstruktionsmodell, • Fertigungsmodell, • Bauwerksmodell verwendet. Ein vollständiges Produktmodell für das Bauwesen allgemein und den Holzbau im Besonderen enthält natürlich weitere Teilmodelle, beispielsweise für HLS-Planung, Abrechnung oder Projektsteuerung.

Das Architekturmodell beschreibt geometrische, funktionelle und ästhetische Aspekte des Bauwerks. Es enthält Repräsentationen physischer Bauteile wie Decken, Wände, Stützen sowie Repräsentationen aphysischer Elemente wie Raumfunktionen oder Fluchtwege.

Das Statikmodell idealisiert das Tragwerk des Bauwerks einschließlich der Einwirkungen. Es enthält mechanische Abstraktionen sowie Mittel zur Bestimmung der Tragsicherheit, Gebrauchstauglichkeit und Dauerhaftigkeit.

Das Konstruktionsmodell liefert Information über Bauteile: Materialien, Formen, Bearbeitungen, Verbindungen usw..

Das Fertigungsmodell ist eine Verfeinerung und Erweiterung des Konstruktionsmodells. Es enthält Informa- tion bezüglich Vorfertigung, Transport und Errichtung.

Das Bauwerksmodell enthält sämtliche physischen Elemente des tragenden und raumabschließenden Systems und somit Teile des Architektur- und des Konstruktionsmodells. Elemente des Statikmodells werden mit Teilen des Bauwerksmodells assoziiert. Das Bauwerksmodell ist ein dreidimensionales virtuelles Gebäude, welches tragende und nichttragende Komponenten umfasst. Es stellt das Zentrum des Produktmodells dar. Alle anderen Teilmodelle stehen mit ihm in Beziehung bzw. sind direkt abgeleitet. Teilmodelle können Objekte gemeinsam verwenden. Optimale Formulierung des Produktmodells strebt geringst mögliche Redundanz hinsichtlich des Metamodells — um Zweideutigkeit zu vermeiden — und hinsichtlich des instantiierten Modells an — um Fehlerquellen bei Planungsänderungen zu vermeiden. 16 IAI-Projekt ST-5 — Structural Timber Model — Teil I: Anforderungen

3 Anforderungen

3.1 Anwendungsbereich des Structural Timber Model

3.1.1 Anwendungsbereich nach Baubranchen Zu berücksichtigen sind: • Bauhauptgewerbe, vor allem: • Fertighausbau, • Ingenieurholzbau, • Zimmermannsbau. Teilweise zu berücksichtigen sind: • Fassadenbau, • Ausbau, • Brückenbau, • Schalungs- und Gerüstbau, • Baustoffindustrie.

3.1.2 Anwendungsbereich nach Akteuren, Disziplinen4 Zu berücksichtigen sind: • Architekt, • Tragwerksplaner, • Konstrukteur/ Zeichner, • Bauunternehmer, • Zulieferer. Teilweise zu berücksichtigen sind: • Bauherr, • Projektsteuerer, • Behörden, • TGA-Ingenieur, TGA-Unternehmer.

4 Die Konzepte Akteur, Rolle und Disziplin werden in diesem Dokument nicht scharf unterschieden. Ein Akteur kann mehrere Rollen übernehmen, andererseits kann ein und dieselbe Rolle durch mehrere Akteure ausgefüllt werden. 3 Anforderungen 17

3.1.3 Anwendungsbereich nach Projektphasen Die Hauptanwendung des Structural Timber Model sind Neubauprojekte des Hoch- baus. Es ist ferner relevant in Umbau und Sanierung und zueinem gewissen Grade in Abrissprojekten. Innerhalb von Projekten sind folgende Phasen von primärem Interesse: • Tragwerksentwurf, • Ausführungsplanung des Tragwerks, • Werkplanung, • Arbeitsvorbereitung. Ferner sind von Interesse • Vorfertigung, • Errichtung, • Objekt-Dokumentation. Teilweise von Interesse ist • Vorentwurf.

3.2 Vertikales und horizontales Daten- Sharing, Modell-Evolution Vertikales Sharing erfolgt zwischen Akteuren verschiedener Rollen. Ein Beispiel ist die gemeinsame Nutzung von Geometriedaten durch ein CAD-Programm und ein Finite-Elemente-Rechenprogramm. Horizontales Sharing erfolgt zwischen Akteuren mit gleicher Rolle, z.B. die gemeinsame Nutzung von Geometrie- und Featuredaten zwischen zwei CAD-Konstruktions- programmen. Ein dazwischen liegender Fall ist Sharing zwischen Akteuren ähnlicher Rollen, z.B. gemeinsame Nutzung von Bauteildaten zwischen Architektur-CAD und Konstruk- tions-CAD. Während letzteres Bearbeitungs-Details als Features betrachtet, wird ersteres nur einen geometrieorientierten Blick auf diese Details erlauben. Evolution: Die Menge an Information nimmt während der verschiedenen Planungs- und Ausführungsphasen zu: • Grobstrukturen werden in Einzelbauteile verfeinert. • Details der Bauteile werden konstruiert. • Qualitativ neue Information wird hinzugefügt, in dem weitere Teilmodelle erarbeitet werden. • Beziehungen zwischen Teilmodellen werden aufgezeigt. • Der Entwurf wird optimiert, unzweckmäßige Entscheidungen berichtigt, die Planung an geänderte Rahmenbedingungen (z.B. Vorgaben des Bauherren) angepasst. 18 IAI-Projekt ST-5 — Structural Timber Model — Teil I: Anforderungen

Folglich muss die Modellstruktur die Entwicklung vom Generischen zum Spezifi- schen unterstützen. Sie muss gemeinsame Elemente und Verknüpfungen der Teil- modelle vorsehen. Versionsinformation muss hinterlegt werden, um dem iterativen Charakter der Planungsprozesse Rechnung zu tragen. Im Structural Timber Model enthaltene Information dient unter anderem • der Ableitung des Tragwerksmodells vom Architekturmodell, • der statischen Berechnung des Holztragwerks, • der Detailplanung im Anschluss an Entwurf und Berechnung, • Anschluss-Planung in Verbindung mit Anschlussbemessung, • Arbeitsvorbereitung, basierend auf Detail- und Anschlussplanung.

3.3 Anforderungen nach Akteuren, Disziplinen

3.3.1 Architekt • empfängt diverse funktionelle, technische und nichttechnische Anforderungen vom Bauherren und Behörden, empfängt die Grundstückssituation vom Vermesser; • erstellt räumliche, funktionelle und ästhetische Aspekte des Gebäudemodells; • modelliert Teile des Tragwerks des Gebäudes; • prüft die Ausführungsplanung des Tragwerksplaners oder Unternehmers hinsichtlich funktioneller, formaler u.a. Gesichtspunkte; • prüft das TGA-Modell auf Unverträglichkeiten. Umfang und Detaillierungsgrad der Architekturplanung hängen stark vom Bauwerks- typ, vertraglichen Konstellationen und lokaler Praxis ab. Der Architekt legt üblicher- weise Superstrukturen wie Wände und Decken und deren wesentliche Bauweise fest. Aufgaben der Detailplanung werden mehr oder weniger weitgehend dem Tragwerks- planer bzw. dem technischen Büro des Unternehmers übertragen. Das detaillierte Konstruktionsmodell muss, wenn es dem Architekten zur Abstim- mung übergeben wird, nicht notwendigerweise die komplette Geometrie von sekun- dären Elementen wie Verbindungsmitteln enthalten, sofern diese nicht besonderen ästhetischen Ansprüchen genügen müssen.5 Wichtig ist, dass in spezialisierten Kon- struktions-Programmen erzeugte Bauteil-Repräsentationen im Wesentlichen auch von Anwendungen außerhalb der Holzbau-Domäne interpretiert werden können. Falls Komponenten lediglich als Referenz auf eine Bibliothek oder einen Katalog übergeben werden, muss diese Bibliothek allen relevanten Projektpartnern zur Verfü-

5 Beispiele: Es kann nötig sein, Stabdübel in sichtbaren Brettschichtholz-Rahmen explizit darzustellen, da derartige Knoten wesentlich zum Erscheinungsbild des Bauwerks beitragen können. Andererseits wird es genügen, Balkenschuhe innerhalb verkleideter Decken lediglich symbolisch zu repräsentieren. 3 Anforderungen 19 gung stehen. Ferner muss die Bibliothek unter Umständen noch lange nach Projekt- ende zugänglich sein.

3.3.2 Tragwerksplaner • empfängt Architekturmodell und Informationen des Vermessers und Geotechnikers; • modelliert das Tragwerk; • entscheidet über Baustoffe tragender Bauteile und wesentliche Tragwerksdetails; • prüft Werkplanung auf Tragsicherheit, Gebrauchtauglichkeit und Dauerhaftigkeit. Vorrangige Aufgabe des Tragwerksplanung ist die Erarbeitung des Statikmodells auf der Basis des Architekturmodells. Außer räumlicher Geometrie wird dazu verschiedene Kontextinformation benötigt, etwa Identifikation einer ‚Geschossdecke im Wohngebäude’, ‚tragende/ nichttragende Wand’ oder Anforderungen an Feuerwider- stand. Liegt diese Information in maschinenlesbarer Form vor, kann ein Teil der statischen Modellierung programmgestützt erfolgen. Das Statikmodell besteht aus Untermodellen, die mehr oder weniger gekoppelt sind. Alle Tragwerke sind räumlich, können und werden jedoch oft zweidimensional modelliert.6 Tragende Holzbauteile sind nahezu ausschließlich mittels 2-Knoten- Balkenelementen abzubilden. Knoten können Auflager oder Verbindungen repräsen- tieren, welche oftmals nachgiebig sind. Einige Bemessungsverfahren im Holzbau verwenden höhere Abstraktionen als Stab- tragwerke. Beispielsweise werden Holztafelwände mittels genormter vereinfachter Verfahren berechnet, welchen bestimmte Annahmen zum Kraftfluss und Verformun- gen zugrunde liegen. Werkstoffe in Holztagwerken sind generell anisotrop.7 Da das Tragverhalten von Holzwerkstoffen zeit- und feuchteabhängig ist, wird entsprechende Kontextinfor- mation aus dem Architekturmodell benötigt. Darüber hinaus hängt Materialverhalten von Querschnittsparametern ab.8 Sofern Materialeigenschaften für den horizontalen Datenaustausch hinterlegt werden, sollten Verweise auf zugehörige Produkt- bzw. Bemessungsnorm angegeben werden. Es sollte auch explizit erkennbar sein, ob die Werte in der Methode der Grenzzu- stände (in Verbindung mit Teilsicherheitsbeiwerten) oder in der Methode der zulässi-

6 Ein Holztragwerk ist eigentlich als 4D-Problem anzusehen, da die Zeitachse von Bedeutung ist. Statische Berechnungen werden allerdings nur an relevanten Zeitpunkten geführt, etwa zu Beginn und nach sehr langem Einwirken von Last.

7 Derzeit unterstützt IFC nur isotrope Materialien.

8 Beispiele: Eurocode 5 gibt Modifikationsfaktoren für die Biegetragfähigkeit an, die von der Quer- schnittshöhe relativ zu einer Bezugshöhe abhängen. Bei Brettschichtholz hängt die Tragfähigkeit nicht nur von den Querschnittsdimensionen, sondern auch von der Anordnung der Lamellen ab. Lamellen unterschiedlicher Sortierklasse können vorteilhaft kombiniert werden. 20 IAI-Projekt ST-5 — Structural Timber Model — Teil I: Anforderungen gen Spannungen (mit in den Spannungen enthaltenem globalem Sicherheitsbeiwert) anwendbar sind.9 Wäre das Modell nur auf die Methode der Grenzzustände ausgerichtet, so könnte seine Anwendbarkeit erheblich verzögert werden, solange Normen und Hersteller- Unterlagen noch nicht vollständig vom Konzept der zulässigen Spannungen auf das semiprobabilistische Konzept umgestellt sind. Es ist auch denkbar, dass nicht standardisierte Bauteile weiterhin mittels zulässiger Spannungen und zulässiger Kräfte bemessen werden.

3.3.3 Konstrukteur, Zeichner • empfängt das Architekturmodell und das Statikmodell; • stellt die Konstruktionsdetails des Bauwerks fertig; • prüft das TGA-Modell auf Kollisionen. Das Konstruktionsmodell wird teilweise vom Architektur- und teilweise vom Statik- modell abgeleitet. [Selbstverständlich hat die Konstruktion Auswirkung auf Archi- tektur und Statik. Insbesondere sind wesentliche Teile der Konstruktion noch vor der Statik zu entwerfen.] Zuordnungen von Elementen der Konstruktion zu Elementen der statischen Berechnung sind im Allgemeinen M:N-Abbildungen. Beispielsweise können mehrere Balkenelemente der statischen Berechnung einen einzigen Vollholz- balken repräsentieren, oder ein Balken der statischen Berechnung kann mehrere parallele Deckenbalken repräsentieren. Zuordnungen architektonischer zu Konstruktionselementen sind ebenfalls im Allge- meinen M:N-Abbildungen, können aber oft auf 1:N-Abbildungen zurückgeführt werden. Z.B. besteht eine Wand aus mehreren Ständern, Beplankungen, Verbin- dungsmitteln usw.. Diese Abbildungen sind mittels Beziehungs-Objekten zu speichern, um spätere Änderungen über Teilmodelle hinweg durchführen zu können, z.B. wenn der Bauherr Änderungen der Gebäudekonzeption wünscht. Allerdings ist die Änderungsverfol- gung weit weniger einfach als die ursprüngliche Generierung der Beziehungs- Objekte. Teilt beispielsweise ein Architektur-CAD-Programm eine Wand in zwei Wände oder entfernt eine Wand, so müsste entweder das Architektur-CAD- Programm eine neue gültige Zuordnung erzeugen oder das Ingenieur-CAD/CAE- Programm die veralteten Beziehungen erkennen und korrigieren. Zwar ist die Kopplung von Teilmodellen und die Lösung von Widersprüchen bei Planungsänderungen immer noch Gegenstand der Forschung, jedoch bieten IFC bereits die Mittel (aber nicht Methoden) der Modellkopplung an. Methoden sind generell nicht Gegenstand der IFC-Modelldefinition.

3.3.4 TGA-Ingenieur • empfängt das Architekturmodell und soweit nötig das Statikmodell;

9 Diese Angabe ist nicht nur im horizontalen Datenaustausch während des Projektes nützlich, sondern auch in späteren Umbauprojekten, wenn die Produktdatenblätter oder Normen eventuell nicht mehr verfügbar sind. 3 Anforderungen 21

• erzeugt das energetische Gebäudemodell (diese Aufgabe wird manchmal auch vom Architekten oder Tragwerksplaner ausgeführt); • erzeugt die Modelle der Gebäudeversorgungsnetze; • prüft das architektonische und Konstruktionsmodell auf Kollisionen. Das Gebäudemodell muss in allen Bereichen, in denen technische Ausbauelemente angeordnet werden sollen, explizite geometrische Information enthalten. Beispiels- weise müssen Anordnung und Form von Pfosten in Ständerwänden bekannt sein, falls keine separate Installationsebene zur Verfügung steht. Die explizite Form von Komponenten wie Metallverbindern wird generell nicht benötigt. Jedoch ist Information über Mindestabstände zwischen Durchbrüchen und Verbindungen und Bauteilbegrenzungen erforderlich. Derartige Information wird derzeit nicht ausdrücklich vom Tragwerksplaner übermittelt, was oft in zeitraubenden und fehlerträchtigen Planrückläufen und -korrekturen resultiert. Ferner ist die generelle Information über tragende oder aussteifende Funktion von Bauteilen für die Durchbruchsplanung relevant. Um das energetische Gebäudemodell zu erstellen, ist Kontextinformation (wie Klassi- fizierung in Außen- und Innenwände und -decken) und funktionelle Information über Räume erforderlich, ebenso wie thermische und hygroskopische Materialeigen- schaften.

3.3.5 Bauunternehmer • agiert auf Basis des Architektur-, Konstruktions- und TGA-Modells und prüft diese Modelle auf Widerspruchsfreiheit, Machbarkeit und Wirtschaft- lichkeit. • erzeugt das Fertigungsmodell (Planung von Herstellung, Transport und Errichtung). Das Fertigungsmodell enthält Produktionsdaten wie Bauabläufe und Stücklisten. Moderner Holzbau ist von hohem Vorfertigungsgrad geprägt. Wettbewerbsfähigkeit verlangt einerseits höhere Automatisierung der Produktion von Holzbau-Komponen- ten, aber andererseits größtmögliche Flexibilität der Baukonstruktion. Um diesen Konflikt zu lösen, muss der Planungsprozess nahtlos und konsistent vom Vorentwurf bis zur Produktion durchlaufen. Schnelle und fehlerfreie Herleitung der Fertigungs- daten aus der Ausführungsplanung ist gefordert. Daher sind Bauteile und Verbindungen feature-orientiert und parametrisch zu model- lieren. Modelle, die lediglich explizite Geometriedaten enthalten, sind ungeeignet zur Generierung von Steuerungsdaten für Maschinen. Beispielsweise müssen Bohrungen, Zapfen, Kerven usw. als separate Features formuliert werden, um diese mittels numerisch gesteuerter Abbundanlagen fertigen zu können.

3.3.6 Zulieferer, Baustoffindustrie • stellt Architekten, Ingenieuren und Bauunternehmern Produktinformation zur Verfügung. 22 IAI-Projekt ST-5 — Structural Timber Model — Teil I: Anforderungen

Externe elektronische Kataloge — oder Bibliotheken von Materialien und Bauteilen — sind von großer Bedeutung für das Structural Timber Model. Derartige Kataloge und Bibliotheken müssen von der Baustoffindustrie gepflegt werden. • Gibt Angebote an den Bauunternehmer ab; • empfängt Materialbestellungen vom Bauunternehmer. Insbesondere in Nordamerika und Skandinavien werden zunehmend mehr und größere Komponenten beim Zulieferer statt beim Bauunternehmer vorgefertigt. Der Zulieferer benötigt daher Zugriff auf Bauwerksdaten. Allerdings werden die für den Zulieferer bestimmten Daten oft aus dem ursprünglichen Projekt-Kontext heraus- gelöst und in einen neuen Kontext des Lieferauftrages gestellt. [Lieferaufträge werden eventuell auch schon zeitlich vor Zustandekommen des eigentlichen Bau- projektes ausgelöst.]

3.3.7 Projektsteuerer • prüft Planungen des Architekten und Ingenieurs; • ermittelt Mengen und erstellt Ausschreibungen; • erstellt Ablaufpläne; • prüft technische und nichttechnische Dokumentation des Bauunternehmers. Das Gebäudemodell, das dem Projektsteuerer zur Prüfung, Kostenkontrolle und Ablaufplanung vorgelegt wird, muss nicht unbedingt die vollständige Geometrie untergeordneter Bauteile enthalten.

3.3.8 Bauherr • gibt funktionelle und ästhetische Anforderungen vor und setzt Kostenrahmen; • stimmt technischer und nichttechnischer Dokumentation des Architekten, Ingenieurs und Bauunternehmers zu; • empfängt die vollständige technische Dokumentation des Architekten, Ingenieurs und Bauunternehmers während und zum Ende des Projekts. In frühen Projektphasen visualisiert der Architekt üblicherweise das Bauwerk mittels Zeichnungen und 3D-Renderings, um dem Bauherren den Entwurf zu vermitteln. Zu diesem Zeitpunkt sind meist noch keine holzbauspezifischen Informationen erforderlich, außer bei besonderen Sichtholzkonstruktionen, bei denen Darstellungen exponierter Details wünschenswert sind. Gegen Ende des Projekts erhält der Bauherr die Dokumentation des ausgeführten Gebäudes. Liegt diese als Produktmodell vor, so können bei entsprechender Lang- lebigkeit des Datenformats und der Datenträger zu späterem Zeitpunkt Daten für Umbau, Verkauf oder Abriss gewonnen werden. 3 Anforderungen 23

3.3.9 Behörden • prüfen Bauanträge anhand technischer, formaler und rechtlicher Anforderungen bezüglich Gesichtspunkten des Städtebaus, des Brandschutzes, des Energiebedarfs, des Schallschutzes usw.; • inspizieren die Baustelle; • prüfen das ausgeführte Bauwerk auf Übereinstimmung mit den genehmigten Planunterlagen. Der geforderte Detailgrad einzureichender Planungen hängt von nationalen und lokalen Regelungen und dem Bauwerkstyp ab, ebenso die geforderte Form der Plan- unterlagen. Elektronischer Datenaustausch mit Behörden wir künftig an Bedeutung gewinnen.

3.4 Anforderungen nach Projektphasen Der Inhalt dieses Abschnitts wurde freundlicherweise vom Projekt FinnTimber-IFC zur Verfügung gestellt.

3.4.1 Bauprozesse Folgende Hauptphasen eines Bauvorhabens werden identifiziert: Anforderungs-Defi- nition, Entwurf, Werkplanung, Ausführung, Nutzung und Wartung. Wichtige Meilen- steine eines Bauvorhabens sind 1 Auslösung des Projekts, 2 Zustimmung zum Entwurf, 3 Genehmigung des Bauantrags, 4 Baubeginn, 5 Übergabe. Während und nach Abschluss des Bauvorhabens werden folgende Aufgaben ausge- führt: Projektsteuerung, behördliche Überwachung, Anforderungs-Management, Planungskoordination, Architektur-, Tragwerks-, TGA- u.a. Planung, Errichtung, Vorfertigung, Materiallieferung, Nutzung, Wartung. Nachfolgende Abschnitte analysieren die Datenflüsse zwischen den Aufgaben wäh- rend einzelner Projektphasen. 24 IAI-Projekt ST-5 — Structural Timber Model — Teil I: Anforderungen

3.4.2 Anwendungsfall: Vom Anforderungs-Management zur Planung

Abb. 3-1 Datenfluss vom Anforderungs-Management zur Planung

Requirements definition Building design Construction planning Construction Use, Maintenance Project Marke- Project managmt. ting Design 4 Construction Construction mgmt. Feasibility Project control control supervision study 1 planning 2

Authority Authority control 3 Authority control control of design of construction

Requirements Requirements Requirements Requirements Requirements Requirements management management management management management management

Design Requirements Design Construction coordination definition coordination supervision/ DC

Architectural Requirements Preliminary Detailed Construction design definition design design supervision/ ARCH

Structural Preliminary Detailed Construction design design design supervision/ STRUCT

HVAC Preliminary Detailed Construction design design design supervision/ HVAC

Preliminary Detailed Other design design Construction design LCC, LCA, supervision/ Other SLP

Tende- Construction Procurement Procure- Construction Construction ring planning planning ment 5

Component Marketing of Component Tende- Production Procure- Component Component production product solutions design ring planning ment production delivery

Material Marketing of Tende- Material supply product info ring deliveries

Use of the Use building

Building Maintenance maintenance

Projektphase gesamtes Vorhaben Sender Planungs-Koordinator, Architekt Sendende App. Applikationen für Anforderungsdefinition und -verwaltung Empfänger Planer (Architekt, Tragwerksplaner, TGA, LCC, LCA, SLP) Empfangende Planungsprogramme (CAD), Applikation LCC-, LCA- und SLP-Applikationen Inhalt Raumprogramm Räume, Bauteile, Systeme des technischen Ausbaus Anforderungen an: Qualität, Energieeffizienz, Lebensdauer, Ressourcenverbrauch, Umweltverträglichkeit 3 Anforderungen 25

3.4.3 Anwendungsfall: Zwischen Planern

Abb. 3-2 Datenfluss zwischen Planern