Verbundvorhaben "Innovativer Holzsystembau"

Transcription

Schlussbericht
zu Nr. 3.2 BNBest-BMBF 98
Zuwendungsempfänger:
Förderkennzeichen:
Brandenburgische Technische Universität Cottbus
Lehrstuhl Statik und Dynamik
PF 10 13 44
03013 Cottbus
0330424
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
1
2
3
4
B
5
6
7
8
9
Kurzdarstellung...............................................................................................................2
Aufgabenstellung...........................................................................................................2
Voraussetzungen der Durchführung des Vorhabens ....................................................3
Planung und Ablauf des Vorhabens ..............................................................................3
Wissenschaftlicher und technischer Stand, an den angeknüpft wurde .........................3
Ausführliche Darstellung ...............................................................................................5
Ergebnis ........................................................................................................................5
5.1
Definitionsphase.....................................................................................................5
5.2
Konzeptionsphase..................................................................................................9
5.3
Erprobungsphase .................................................................................................15
5.4
Transferphase ......................................................................................................16
Fortschritte auf dem Gebiet des Vorhabens bei anderen Stellen................................16
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
Voraussichtlicher Nutzen, Verwertbarkeit des Ergebnisses ........................................21
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, Arbeitsvorbereitung und Produktionssteuerung heute jeweils in sich durch EDV-Integrationslösungen abgedeckt sind, fehlt für die interdisziplinäre und unternehmensübergreifende Kommunikation 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 Systembetrachtung — 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 Bauprojektphasen 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: Bauwerke bzw. Projekte werden hinsichtlich Material, Energie und Logistik weitergehend steuerbar, 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 durchfü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 Industrieverbä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.
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
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 Teilmodellen 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 „IAIProjekt 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 Bauprojekten 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 Datenmodelle, die zur Abbildung auf Produktmodelle geeignet sind. Zum Anderen blockieren kurzfristige Vorteile der Integrationslösungen (bilaterale Schnittstellen, welche letztendlich nur auf
„Informationsinseln“ zu funktionieren vermögen) das Bestreben nach umfassend interoperablen, 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 Mengenermittlung 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. Dimensionierung 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 Teilmodelle 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, Betrachtungswinkel 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 Bauwerksmodells;
•
Modell des technischen Ausbaus: beinhaltet Netze der technischen Ausstattung;
•
Detaillierungs- und Produktionsmodell: Präzisierung des physischen Bauwerksmodells hinsichtlich der für die Fertigung nötigen Informationen;
•
5.1.4
Kostenmodell.
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 Fertigungsanlagen, 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ählungstypen) 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übergreifenden 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 Vererbungsbeziehungen 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
•
Domänen-Ebene: fachspezifische Konzepte,
•
Ressourcen-Ebene: gemeinsame und fachspezifische Hilfskonstrukte.
11
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 Teilmodelle 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 Nachholbedarf. 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 Projektmodellgliederung, 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 Multifunktionsbrü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 Wandtafeln 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 IFCProgrammen 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 Beschreibungen 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 Modellversion 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 IFCModells 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 Industriepartnern sowie Pilotanwendungen. Im Rahmen der Vorbereitungen zur Messe BAU und der
Messepräsentation Januar 2005 in München wurden Gebäudedaten, die dankenswerterweise 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 Fertigungssimulation 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
5.4
16
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ßerdem 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.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 Tragwerksplanung und Nemetschek AG aus Sicht der allgemeinen Hochbau- und ArchitekturCAD-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-
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, Softwareanbieter 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 IFCErweiterungsprojekt 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 Kollaborationsplattformen 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 Datentransfer zur Minimierung des Ressourcenverbrauchs“ kommt diese offene internationale
Zusammenarbeit in mehrerer Hinsicht zugute: Weltweite Akzeptanz der hier definierten
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. WeinmannPartner
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 Modellkonzeption
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
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 Forstwirtschaft und holzverarbeitende Industrie; BTU
Inhalte: Weiterentwicklung des Standards ELDAT, Standardisierung des Informationsaustauschs 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
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 Produktdatenmodell, 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-
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 IngenieurCAD-Anwendungen eine maßgebliche Rolle in der Konformitätsprüfung spielen wird. Somit
wird durchgängige Weiternutzung von Planungsdaten insbesondere in der Entwurfs-, Detailbzw. 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
dth@statik.tu-cottbus.de
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 DtHProjekt 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
2.2.2
2.2.3
2.2.4
2.2.5
STEP............................................................................................................................7
IFC...............................................................................................................................8
DtH ..............................................................................................................................8
Produktmodell-Entwicklungen in verwandten Branchen ............................................9
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
3.1.2
3.1.3
Anwendungsbereich nach Baubranchen....................................................................16
Anwendungsbereich nach Akteuren, Disziplinen......................................................16
Anwendungsbereich nach Projektphasen ..................................................................17
3.2 Vertikales und horizontales Daten-Sharing, Modell-Evolution.....................17
3.3 Anforderungen nach Akteuren, Disziplinen ..................................................18
3.3.1
3.3.2
3.3.3
3.3.4
3.3.5
3.3.6
3.3.7
3.3.8
3.3.9
Architekt ....................................................................................................................18
Tragwerksplaner ........................................................................................................19
Konstrukteur, Zeichner..............................................................................................20
TGA-Ingenieur ..........................................................................................................20
Bauunternehmer.........................................................................................................21
Zulieferer, Baustoffindustrie......................................................................................21
Projektsteuerer...........................................................................................................22
Bauherr ......................................................................................................................22
Behörden....................................................................................................................23
3.4 Anforderungen nach Projektphasen...............................................................23
3.4.1
3.4.2
3.4.3
3.4.4
3.4.5
3.4.6
3.4.7
3.4.8
3.4.9
Bauprozesse...............................................................................................................23
Anwendungsfall: Vom Anforderungs-Management zur Planung..............................24
Anwendungsfall: Zwischen Planern ..........................................................................25
Anwendungsfall: Produktinformation des Herstellers/ Lieferanten zu Planern.........26
Anwendungsfall: Vom Entwurf zur Werkplanung ....................................................27
Anwendungsfall: Zwischen Projektsteuerung, Ausführung und Zulieferung............28
Anwendungsfall: Allgemeine Projektsteuerung ........................................................29
Anwendungsfall: Von Planung und Ausführung zu Nutzung und Wartung..............30
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
4.8.2
Fehlendes TGA-Modell.............................................................................................32
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-Standard, 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 Reference” (Klassen-Referenz) und “Part III: Implementation Guide” (Implementierungshilfe).
Ä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
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 Wettbewerbsfä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 zeitund 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 herkömmliche Schnittstellen
Abb. 2-2
Gemeinsame Datennutzung
über ein Produktmodell
Architect
Engineer
Work Prep.
Machine A
Architect
Bldg.Services
Draftsman
Machine B
Engineer
Work Prep.
Product
Model
Machine A
Bldg.Services
Draftsman
Machine B
Daher wird ein neues Datenmodell benötigt, welches sämtliche Gebiete der Bauplanung 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 unmittelbar aus Abb. 2-2 ersichtlich: Die Anzahl an Schnittstellen sinkt. Alle Kommunikations-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-, Zeitund 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 Intentionen 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 fortschreitet. 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
Die STEP-Dokumentation wird kostenpflichtig durch nationale StandardisierungsInstitutionen vertrieben. Implementierungshilfen sind in Form zahlreicher kommerzieller 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 monolithische Ansatz der STEP Application Protocols den Anforderungen der multidisziplinä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 FMElemente 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 BLISProjekts 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 Ingenieurholzbau, 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, Konstruktion, 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 Erfordernissen 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 einsetzen.
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 Werkplanung 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 Tragwerksplanungs-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 eigenentwickelten 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, Berechnungsprogramme und CAM.
Anders als standardisierte Produktmodelle sind proprietäre Modelle auf herstellerspezifische 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öbelindustrie 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 Überschneidung hinsichtlich der Herstellung, namentlich der Holzbearbeitung. Während
die ST-5-Erweiterungen für IFC auch zerspanendes Bearbeiten und Fügen von Holzwerkstoffen berücksichtigt, gibt es in funSTEP keine Vorkehrungen für die Integration von Detailplanung und Fertigung.
1
[9], [10], [11], [12]
2004
2003
2002
ANSI
ISO
SCI
IAI
ST-6
IFC 2x2
ifcXML
IFC 2.0
ST-5
ST-4.2
ST-4
ST-1
DSTV
PSS 04.2000
IFC 1.0
IFC 1.5.1
PSS
IFC
Ein Produktmodell
für den Stahlbau
(Haller)
DSTV NC protocol
DSTV uniform material
designations
DSTV interface between
structural analysis and CAD
Industry Foundation Classes
2001
CIS/2.1
CIS/1 finished
CIS/2 started
CIMsteel Integration
Standards
CIS/1.0
Computer Integrated Manufacturing for
Constructional
Steelwork
CIMsteel
Eureka program
IFC 2x
ISO 10303-225
IS published
circa 30 APs in the
works, e.g.
pt.225 - building elem.
pt.228 - HVAC
pt.230 - steel frames
pt.106 - BCCM (bldg.
constr. core model)
interoperability models
in the works
parts 1, 11, 21 etc
pt.201 - 2D drawing
pt.203 - 3D drawing
Standard for the
Exchange of Product
Model Data
initial ISO 10303
(STEP) release:
initial proposed standard
STEP
Product Data
Exchange
Specification
PDES
XBF
2000
1999
1998
1997
1996
1995
COMBI project
1994
CALS
ATLAS project
DIN
flächen-Schnittstelle
VDA-FS Freiform-
1993
IGES 6.0
IGES 3.0
CADLIB
VDA-PS
et de Transfert
SET Standard d'Echange
AFNOR
Esprit program
U.S.AF
IGES 1.0
Initial Graphics
Exchange
Specification
1991
1988
1987
1986
1984
ICAM program
DGfH
DtH 2.0
DtH 1.05
Datentransfer
im Holzbau
Abb. 2-3
1982
1980
1973
10
Geschichtliche Einordnung von Produktmodellen1
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, Einschlagunternehmen 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 Informationsinhalte 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 Produktionsanlagen. 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 Datenmodelle durch einen Standard wie DtH oder IFC zu ersetzen. CAM-Integratoren
haben jedoch bisher wenig Interesse an offenen Lösungen gezeigt. Die nordamerikanische 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 Integrationslö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
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 kommagetrennten 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ätzlicher Schichten-Information. Sie wurde jüngst um eine dritte Koordinate ergänzt, um
auch komplexere Bausysteme abzudecken. Nahezu keine maschinenspezifische Information 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
Anwendungsbereiche der gegenwärtigen IFC- und DtH-Standards
demolition
conversion
conservation
IF
C
use
2x
2
preliminary
design
design, struct.
calculation
building
lifecycle
detailing
2.
0
Abb. 2-4
prefabrication
erection
Dt
H
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 Unterstü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 Concrete Construction” eingebracht, siehe Abb. 2-5. Dadurch wird es möglich, die ST-5Erweiterungen in den oberen IFC-Ebenen separiert einzufügen.
Erweiterungen zu IFC 2x durch die Projekte ST-3, ST-4, ST-53
Abb. 2-5
HVAC
Domain
Architecture
Domain
Electrical
Domain
Construction Mgmt
Domain
FM
Domain
Precast
Concrete
Construction
Domain
Structural
Analysis
Domain
Steel
Construction
Domain
Timber
Construction
Domain
Domain Layer
Shared
Bldg Services
Elements
Shared
Spatial
Elements
Shared
Management
Elements
Shared
Facilities
Elements
Shared
Building
Elements
Shared Bldg
Elements
Extension
Additions
Product
Exten.
Extn.
Additions
Interoperability Layer
IFC 2x platform
ISO/PAS 16739
non-platform part:
next candidates
Control
Extension
Process Product
Exten- Extension sion
Kernel
out of platform
IFC 2x ST-3 ST-4 ST-5
Core Layer
Material
Resource
Geometry
Resource
...
...
...
...
Material
Property
Resource
Geometric
Model
Resource
Profile
Resource
Measure
Resource
Representation
Resource
Topology
Resource
Profile
Extension
Resource
Measure
Extension
Resource
Representation
Extension
Topology
Extension
Resource
project
project
project
harmonization
with BEC
harmonization
with PSS,
CIS/2
harmonization
with DtH
Resource Layer
Additions Geometric
Model
Extension
Profile
Property
Resource
Structural
Load
Resource
Additions
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
• 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 Information 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
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 Hochbaus. 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 DatenSharing, 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-Konstruktionsprogrammen.
Ein dazwischen liegender Fall ist Sharing zwischen Akteuren ähnlicher Rollen, z.B.
gemeinsame Nutzung von Bauteildaten zwischen Architektur-CAD und Konstruktions-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 Planungsund 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
Folglich muss die Modellstruktur die Entwicklung vom Generischen zum Spezifischen unterstützen. Sie muss gemeinsame Elemente und Verknüpfungen der Teilmodelle 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 Bauwerkstyp, vertraglichen Konstellationen und lokaler Praxis ab. Der Architekt legt üblicherweise Superstrukturen wie Wände und Decken und deren wesentliche Bauweise fest.
Aufgaben der Detailplanung werden mehr oder weniger weitgehend dem Tragwerksplaner bzw. dem technischen Büro des Unternehmers übertragen.
Das detaillierte Konstruktionsmodell muss, wenn es dem Architekten zur Abstimmung übergeben wird, nicht notwendigerweise die komplette Geometrie von sekundären Elementen wie Verbindungsmitteln enthalten, sofern diese nicht besonderen
ästhetischen Ansprüchen genügen müssen.5 Wichtig ist, dass in spezialisierten Konstruktions-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 Projektende 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 Feuerwiderstand. 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-KnotenBalkenelementen abzubilden. Knoten können Auflager oder Verbindungen repräsentieren, welche oftmals nachgiebig sind.
Einige Bemessungsverfahren im Holzbau verwenden höhere Abstraktionen als Stabtragwerke. Beispielsweise werden Holztafelwände mittels genormter vereinfachter
Verfahren berechnet, welchen bestimmte Annahmen zum Kraftfluss und Verformungen zugrunde liegen.
Werkstoffe in Holztagwerken sind generell anisotrop.7 Da das Tragverhalten von
Holzwerkstoffen zeitund feuchteabhängig ist, wird entsprechende Kontextinformation 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 Grenzzustä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
8
Derzeit unterstützt IFC nur isotrope Materialien.
Beispiele: Eurocode 5 gibt Modifikationsfaktoren für die Biegetragfähigkeit an, die von der Querschnittshö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
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 HerstellerUnterlagen 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 Statikmodell abgeleitet. [Selbstverständlich hat die Konstruktion Auswirkung auf Architektur 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 Vollholzbalken repräsentieren, oder ein Balken der statischen Berechnung kann mehrere
parallele Deckenbalken repräsentieren.
Zuordnungen architektonischer zu Konstruktionselementen sind ebenfalls im Allgemeinen 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, Verbindungsmitteln 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 Änderungsverfolgung weit weniger einfach als die ursprüngliche Generierung der BeziehungsObjekte. Teilt beispielsweise ein Architektur-CAD-Programm eine Wand in zwei
Wände oder entfernt eine Wand, so müsste entweder das Architektur-CADProgramm eine neue gültige Zuordnung erzeugen oder das Ingenieur-CAD/CAEProgramm 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. Beispielsweise 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 Klassifizierung in Außen- und Innenwände und -decken) und funktionelle Information über
Räume erforderlich, ebenso wie thermische und hygroskopische Materialeigenschaften.
3.3.5 Bauunternehmer
• agiert auf Basis des Architektur-, Konstruktions- und TGA-Modells und
prüft diese Modelle auf Widerspruchsfreiheit, Machbarkeit und Wirtschaftlichkeit.
• 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-Komponenten, 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 Fertigungsdaten aus der Ausführungsplanung ist gefordert.
Daher sind Bauteile und Verbindungen feature-orientiert und parametrisch zu modellieren. 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
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 herausgelöst und in einen neuen Kontext des Lieferauftrages gestellt. [Lieferaufträge
werden eventuell auch schon zeitlich vor Zustandekommen des eigentlichen Bauprojektes 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 Langlebigkeit 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 Planunterlagen. 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-Definition, Entwurf, Werkplanung, Ausführung, Nutzung und Wartung. Wichtige Meilensteine 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 ausgefü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ährend einzelner Projektphasen.
24
3.4.2 Anwendungsfall: Vom Anforderungs-Management zur
Planung
Abb. 3-1
Datenfluss vom Anforderungs-Management zur Planung
Building design
Requirements definition
Project
Project
managmt.
mgmt. Feasibility 1
study
Project
planning
Authority
control
Marketing
Design
control
2
Authority control
of design
Construction planning
4
Requirements
management
Requirements
management
Design
coordination
Requirements
definition
Design
coordination
Architectural
design
Requirements
definition
Requirements
management
Requirements
management
Detailed
design
Construction
supervision/ ARCH
Structural
design
Preliminary
design
Detailed
design
Construction
supervision/ STRUCT
HVAC
design
Preliminary
design
Detailed
design
Construction
supervision/ HVAC
Preliminary
design
LCC, LCA,
SLP
Detailed
design
Construction
supervision/ Other
Tende- Construction Procurement
ring
planning
planning
Construction
Component
production
Marketing of
product solutions
Requirements
management
Construction
supervision/ DC
Preliminary
design
Other
design
Use, Maintenance
Construction
supervision
Authority control
of construction
3
Requirements
management
Construction
Construction
control
Tendering
Component
design
Material
supply
Marketing of
product info
Procurement
Construction
5
Production Procure- Component Component
planning
production
delivery
ment
Tendering
Material
deliveries
Use of the
building
Use
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
Applikation
Planungsprogramme (CAD),
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
Building design
Project
Project
managmt.
mgmt. Feasibility 1
study
Project
planning
Authority
control
Marketing
Design
control
2
Authority control
of design
Requirements
management
Requirements
management
Design
coordination
Requirements
definition
Design
coordination
Architectural
design
Requirements
definition
Requirements
management
Requirements
management
Detailed
design
Construction
supervision/ ARCH
Structural
design
Preliminary
design
Detailed
design
Construction
supervision/ STRUCT
HVAC
design
Preliminary
design
Detailed
design
Construction
supervision/ HVAC
Preliminary
design
LCC, LCA,
SLP
Detailed
design
Construction
supervision/ Other
ring
planning
planning
Construction
Component
production
Marketing of
product solutions
Requirements
management
Construction
supervision/ DC
Preliminary
design
Other
design
Use, Maintenance
Construction
supervision
Authority control
of construction
3
Requirements
management
Construction
Construction
control
4
Tende- Production
planning
ring
Component
design
Material
supply
Marketing of
product info
Tendering
Procurement
Construction
5
Procure- Component Component
production
delivery
ment
Material
deliveries
Use of the
building
Use
Building
maintenance
Maintenance
Projektphase
Entwurf
Sender
Sendende App. Planungs-, LCC-, LCA- und SLP- Applikationen
Empfänger
Empfangende
Applikation
Visualisierung, Kollisionsprüfung,
Inhalt
Räume, Bauteile, technische Ausbauelemente
Bauweisen und Ausbausysteme
3D-Form, Platzierung
Materialien
(LCC-, LCA-, SLP-Analyse)
Änderungswünsche
26
3.4.4 Anwendungsfall: Produktinformation des Herstellers/
Lieferanten zu Planern
Abb. 3-3
Datenfluss vom Zulieferer zu Planern
Building design
Project
Project
managmt.
mgmt. Feasibility 1
study
Project
planning
Authority
control
Marketing
Design
control
2
Authority control
of design
4
Requirements
management
Requirements
management
Design
coordination
Requirements
definition
Design
coordination
Architectural
design
Requirements
definition
Requirements
management
Requirements
management
Detailed
design
Construction
supervision/ ARCH
Structural
design
Preliminary
design
Detailed
design
Construction
supervision/ STRUCT
HVAC
design
Preliminary
design
Detailed
design
Construction
supervision/ HVAC
Preliminary
design
LCC, LCA,
SLP
Detailed
design
Construction
supervision/ Other
ring
planning
planning
Construction
Component
production
Marketing of
product solutions
Requirements
management
Construction
supervision/ DC
Preliminary
design
Other
design
Use, Maintenance
Construction
supervision
Authority control
of construction
3
Requirements
management
Construction
Construction
control
Tendering
Component
design
Material
supply
Marketing of
product info
Procurement
Construction
5
planning
production
delivery
ment
Tendering
Material
deliveries
Use of the
building
Use
Building
maintenance
Maintenance
Projektphase
Entwurf
Sender
Hersteller und Lieferanten
Sendende App. Produktbibliotheken
Empfänger
Empfangende
Applikation
Anwendungen des Vorentwurfs,
Inhalt
Bauteile, technische Ausbauelemente
3D-Form, (Platzierung)
spezifische Eigenschaften
Lebensdauer unter Gebrauchsbedingungen, LebensdauerDeklaration
Kosteninformation, Preisinformation
3 Anforderungen
27
3.4.5 Anwendungsfall: Vom Entwurf zur Werkplanung
Abb. 3-4
Datenfluss vom Entwurf zur Werkplanung
Building design
Project
Project
managmt.
mgmt. Feasibility 1
study
Project
planning
Authority
control
Marketing
Design
control
2
Authority control
of design
Construction
Authority control
of construction
3
Requirements
management
Requirements
management
Requirements
management
Design
coordination
Requirements
definition
Design
coordination
Architectural
design
Requirements
definition
Requirements
management
Requirements
management
Detailed
design
Construction
supervision/ ARCH
Structural
design
Preliminary
design
Detailed
design
Construction
supervision/ STRUCT
HVAC
design
Preliminary
design
Detailed
design
Construction
supervision/ HVAC
Preliminary
design
LCC, LCA,
SLP
Detailed
design
Construction
supervision/ Other
ring
planning
planning
Construction
Component
production
Marketing of
product solutions
Requirements
management
Construction
supervision/ DC
Preliminary
design
Other
design
Use, Maintenance
Construction
supervision
Construction
control
4
Tende- Production
planning
ring
Component
design
Material
supply
Marketing of
product info
Procurement
Construction
5
production
delivery
ment
Tendering
Material
deliveries
Use of the
building
Use
Building
maintenance
Maintenance
Projektphase
Entwurf, Werkplanung
Sender
Planer (Architekt, Tragwerksplaner, TGA)
Sendende App. Planungsprogramme (CAD)
Empfänger
Arbeitsvorbereitung
Werk-, Komponenten-Planer
Empfangende
Applikation
Mengen- und Kostenermittlung
Bauablaufplanungs-Anwendungen
Werk- und Komponenten-Planungsprogramme
Inhalt
Bauteile, technische Ausbauelemente
3D-Form, Platzierung
spezifische Eigenschaften
28
3.4.6 Anwendungsfall: Zwischen Projektsteuerung, Ausführung
und Zulieferung
Abb. 3-5
Datenfluss zwischen Projektsteuerung, Ausführung und Zulieferung
Building design
Project
Project
managmt.
mgmt. Feasibility 1
study
Project
planning
Authority
control
Marketing
Design
control
2
Authority control
of design
4
Requirements
management
Requirements
management
Design
coordination
Requirements
definition
Design
coordination
Architectural
design
Requirements
definition
Requirements
management
Requirements
management
Detailed
design
Construction
supervision/ ARCH
Structural
design
Preliminary
design
Detailed
design
Construction
supervision/ STRUCT
HVAC
design
Preliminary
design
Detailed
design
Construction
supervision/ HVAC
Preliminary
design
LCC, LCA,
SLP
Component
production
Material
supply
Detailed
design
Construction
supervision/ Other
ring
planning
planning
Construction
Marketing of
product solutions
Requirements
management
Construction
supervision/ DC
Preliminary
design
Other
design
Use, Maintenance
Construction
supervision
Authority control
of construction
3
Requirements
management
Construction
Construction
control
Tendering
Component
design
Marketing of
product info
Procurement
Construction
5
planning
production
delivery
ment
Tendering
Material
deliveries
Use of the
building
Use
Building
maintenance
Maintenance
Projektphase
Werkplanung, Ausführung
Sender
Projektsteuerer
Bauunternehmer und Zulieferer
Sendende App. Projektsteuerung, Bauablaufplanung,
Lieferverwaltung
Empfänger
Projektsteuerer
Bauunternehmer und Zulieferer
Empfangende
Applikation
Projektsteuerung, Bauablaufplanung,
Lieferverwaltung
Inhalt
Lieferungen, Lieferzeiten
bauseitige Anforderungen: Stellplatz, Hebezeuge
3 Anforderungen
29
3.4.7 Anwendungsfall: Allgemeine Projektsteuerung
Abb. 3-6
Datenfluss von und zur Projektsteuerung
Building design
Project
Project
managmt.
mgmt. Feasibility 1
study
Project
planning
Authority
control
Marketing
2
Authority control
of design
Requirements
management
Design
coordination
Project
managmt.
Requirem.
definition
Architectural
design
Project
managmt.
Requirem.
definition
Structural
design
Requirements
management
Requirements
management
Detailed
design
Construction
supervision/ ARCH
Project
managmt.
Preliminary
design
Detailed
design
Construction
supervision/ STRUCT
HVAC
design
Project
managmt.
Preliminary
design
Detailed
design
Construction
supervision/ HVAC
Other
design
Project
managmt.
Construction
Project
managmt.
Component
production
Project
managmt.
Material
supply
Project
managmt.
LCC, LCA,
SLP
Detailed
design
Construction
supervision/ Other
ring
planning
planning
Marketing of
product solutions
Requirements
management
Construction
supervision/ DC
Preliminary
design
Preliminary
design
Use, Maintenance
Construction
supervision
Authority control
of construction
3
Requirements
management
Construction
Construction
control
4
Requirem.
managmt.
Design
coordination
Design
control
Tende- Production
planning
ring
Component
design
Marketing of
product info
Tendering
Procurement
Construction
5
production
delivery
ment
Material
deliveries
Use of the
building
Use
Building
maintenance
Maintenance
Projektphase
gesamtes Bauvorhaben
Sender
Projektsteuerung
alle Akteure
Sendende App. Projektsteuerung, Bauablaufplanung,
Kostenkontrollprogramme
Empfänger
Projektsteuerung
alle Akteure
Empfangende
Applikation
Projektsteuerung, Bauablaufplanung,
Kostenkontrollprogramme
Inhalt
Aufgaben, Unteraufgaben
Aufgaben-Abfolge, -Dauer
Abhängigkeiten der Aufgaben
Aufgaben-Ergebnisse
Kostenkontroll-Information
30
3.4.8 Anwendungsfall: Von Planung und Ausführung zu Nutzung
und Wartung
Abb. 3-7
Datenfluss zur Nutzung und Wartung
Building design
Project
Project
managmt.
mgmt. Feasibility 1
study
Project
planning
Authority
control
Marketing
Design
control
2
Authority control
of design
4
Requirements
management
Requirements
management
Design
coordination
Requirements
definition
Design
coordination
Architectural
design
Requirements
definition
Requirements
management
Requirements
management
Detailed
design
Construction
supervision/ ARCH
Structural
design
Preliminary
design
Detailed
design
Construction
supervision/ STRUCT
HVAC
design
Preliminary
design
Detailed
design
Construction
supervision/ HVAC
Preliminary
design
LCC, LCA,
SLP
Detailed
design
Construction
supervision/ Other
ring
planning
planning
Construction
Component
production
Marketing of
product solutions
Requirements
management
Construction
supervision/ DC
Preliminary
design
Other
design
Use, Maintenance
Construction
supervision
Authority control
of construction
3
Requirements
management
Construction
Construction
control
Tendering
Component
design
Material
supply
Marketing of
product info
Procurement
Construction
5
planning
production
delivery
ment
Tendering
Material
deliveries
Use of the
building
Use
Building
maintenance
Maintenance
Projektphase
Übergabe des Bauwerks
Sender
Planer, Ausführende
Sendende App. Planungsprogramme, Dokumentationsprogramme
Empfänger
Nutzer, Wartung
Empfangende
Applikation
Wartungs-Anwendungen
LCC-Applikationen
Inhalt
Wartungsplanungs-Information: Räume, Bauelemente, technische
Ausbauelemente; Wartungspläne
Lebenszyklus-Information
Nutzungsdauer-Information
3 Anforderungen
31
3.4.9 Anwendungsfall: Zwischen Nutzung und Wartung
Abb. 3-8
Datenfluss zwischen Nutzung und Wartung
Building design
Project
Project
managmt.
mgmt. Feasibility 1
study
Project
planning
Authority
control
Marketing
Design
control
2
Authority control
of design
Construction
Authority control
of construction
3
Requirements
management
Requirements
management
Requirements
management
Design
coordination
Requirements
definition
Design
coordination
Architectural
design
Requirements
definition
Requirements
management
Requirements
management
Detailed
design
Construction
supervision/ ARCH
Structural
design
Preliminary
design
Detailed
design
Construction
supervision/ STRUCT
HVAC
design
Preliminary
design
Detailed
design
Construction
supervision/ HVAC
Preliminary
design
LCC, LCA,
SLP
Detailed
design
Construction
supervision/ Other
ring
planning
planning
Construction
Component
production
Marketing of
product solutions
Requirements
management
Construction
supervision/ DC
Preliminary
design
Other
design
Use, Maintenance
Construction
supervision
Construction
control
4
Tendering
Component
design
Material
supply
Marketing of
product info
Procurement
Construction
5
planning
production
delivery
ment
Tendering
Material
deliveries
Use of the
building
Use
Building
maintenance
Maintenance
Projektphase
Nutzung und Wartung
Sender
Eigentümer, Dienstleister, (Nutzer)
Sendende App. Wartungsplanung
Wartungs-Applikationen
Mängelerfassung
Empfänger
Eigentümer, Dienstleister, (Nutzer)
Empfangende
Applikation
Wartungsplanung
Wartungs-Applikationen
Mängelerfassung
Inhalt
Mängelberichte
Anfordern von Leistungen
Wartungsaufgaben, Termine, Ausführung
32
Die Abschnitte 4.1–4.7 sind für den deutschsprachigen Leser weniger von Interesse
und werden hier nicht wiedergegeben. Er sei auf die englische Fassung diese Dokuments und auf die DtH-Referenz [5] verwiesen.
4.8 Lücken in DtH 2.0
4.8.1 Fehlendes TGA-Modell
DtH enthält keine Klassen für Elemente der technischen Gebäudeausrüstung. Grund
ist, dass während der Entwicklungsphasen des DtH-Modells kein Interesse bei einschlägigen deutschen Softwarehäusern gewonnen werden konnte, Anbindungen an
ein augenscheinlich auf Holzbau beschränktes Datenmodell zu definieren. Demgegenüber sind in IFC 2x2 bereits umfassende Teilmodelle für den technischen Ausbau
vorhanden.
4.8.2 Eingeschränktes Fertigungsmodell
Unterscheidung von Vorfertigung und Vor-Ort-Montage
Verbindungen können in DtH als vormontiert oder als auf der Baustelle herzustellen
gekennzeichnet werden. Für Bearbeitungen wie z.B. Bohrungen fehlt ein solches
Attribut. Diese Information wäre in der Arbeitsvorbereitung, Montageplanung und
Qualitätssicherung nützlich. Bearbeitungen wie z.B. Oberflächenbehandlungen und
Holzschutzmaßnahmen könnten sogar noch weitergehend differenziert werden in
solche die vor Werkstatfertigung, nach Werkstattfertigung aber vor Auslieferung,
oder auf der Baustelle herzustellen sind.
Technologische Abfolgen
Generell besteht nur in Form des geordneten LIST-Attributes jedes Bauteils für seine
Bearbeitungen die Möglichkeit, Abfolgen technologischer Prozesse abzubilden. Tatsächliche Abhängigkeiten und bauteilübergreifende Abläufe können nicht erfasst
werden.
Trennen von Baugruppen
Es ist in DtH möglich, bei durchgehenden Sägeschnitten durch Balken oder Platten
sowohl die dabei entstehenden Bauteile als auch das ursprüngliche Rohbauteil als
Objekt abzulegen. Dies ermöglicht Produktionsplanung mit dem Ziel bestmöglicher
Maschinenauslastung und Materialnutzung. Dieser Mechanismus ist jedoch nicht
anwendbar für ganze Baugruppen. Es ist jedoch üblich, dass Wand- und Deckensegmente so groß wie anlagentechnisch möglich produziert, dann in tatsächlich benötigte Größen geteilt und an verschiedenen Orten im Bauwerk oder sogar in verschiedenen Projekten verbaut werden. Daher müssen nicht nur Einzelbauteile, sondern
auch Aggregationen von Bauteilen als Objekte sowohl vor als auch nach dem Auftrennen repräsentiert werden.
33
Baugruppen, Superstrukturen
In DtH gibt es drei Möglichkeiten, Bauteile zu Baugruppen zusammenzufassen. Zum
Einen ist diese Mehrdeutigkeit des Modells nicht wünschenswert, zum Anderen hat
jede der drei Möglichkeiten Unzulänglichkeiten:
• In erster Linie ist das Entity BUILDING_PART zur Repräsentation von
Baugruppen zu verwenden. Jedoch stimmt die physische Gliederung in
Wand- und Deckensegmente im Fertigungsmodell im Allgemeinen mit der
willkürlichen oder programmabhängigen Gliederung im Architekturmodell
nicht überein, so dass die Überschneidung der beiden Teilmodelle hinsichtlich dieses Entities nicht wünschenswert ist.
Zudem werden in DtH Bauteilkoordinaten im globalen Koordinatensystem
angegeben, nicht wie für die Fertigungsplanung wünschenswert in lokalen
Koordinaten der Baugruppe.
• Baugruppen können auch mittels des Entities MEMBER_LOCATION modelliert
werden. Jedoch gibt es hierbei nur Verweisbeziehungen von den Teilen zur
Baugruppe, nicht von er Baugruppe zu deren Einzelteilen.
Außerdem können diesem Entity keine Bearbeitungen zugewiesen werden,
was aber gerade im Holzrahmenbau erforderlich wäre.
• Das allgemein für Gruppierungen zur Verfügung stehende Entity
STRUCTURE besitzt den Nachteil, keinerlei Eigenschaften wie Transportgewicht oder Bearbeitungen zugewiesen bekommen zu können.
Maschinensteuerung
Es ist in DtH nicht vorgesehen, Bauteilen oder Baugruppen Maschinensteuerungsdaten zuzuweisen, weder direkt in DtH-Dateien noch als Referenz auf externe
Dateien.
34
5 Anhang
5.1 Literatur
[1]
ISO 10303: Industrial Automation Systems and Integration - Product Data
Representation and Exchange. International Organization for Standardization, ,
TC184/SC4, http://www.tc184-sc4.org/
[2]
Industry Foundation Classes (IFC) – Release 2x Edition 2 Addendum 1.
International Alliance for Interoperability, 2004, http://www.iaiinternational.org/iai_international/Technical_Documents/R2x2_final/
[3]
Standardbeschreibung Produktschnittstelle Stahlbau. Deutscher StahlbauVerband, Düsseldorf, 2000/2004,
http://www.deutscherstahlbau.de/asp/biblioaussdet.asp?auss=7
[4]
DtH-Produktschnittstelle für den Datenaustausch im Holzbau, Version 1.05.
Deutsche Gesellschaft für Holzforschung, München, 1996
[5]
Jörn Weichert, Peter Osterrieder: Produktmodell DtH 2.0 für den Ingenieurholzbau, Zimmermannsbau und Fertighausbau. Brandenburgische Technische
Universität Cottbus, Germany, 2000, ISSN 1615-3952,
http://www.statik.tu-cottbus.de/dth
[6]
IFC 2x Model Integration Guide. IAI Model Support Group, 2002,
http://www.iai-international.org/iai_international/Technical_Documents/
documentation/Ifc2xModelIntegration/Model_Integration_Guide_v1.00.pdf
[7]
IFC 2x Extension Modelling Guide. IAI Model Support Group, 2001,
http://cig.bre.co.uk/iai_international/Technical_Documents/documentation/Ifc2
x_EMG/EMG-Base.htm
[8]
Industry Foundation Classes – Release 2x; IFC Technical Guide. IAI Model
Support Group, 2000, http://www.iai-international.org/iai_international/
Technical_Documents/documentation/IFC_2x_Technical_Guide.pdf
[9]
Thomas Liebich, Jeffrey Wix, et al: Standard Analysis – Current Situation –
Building Models. prodAEC deliverable D4.1.2, 2002, http://www.prodaec.com/
[10] Curtis Parks: IGES – Historical Milestones. NIST, 2003,
http://www.nist.gov/iges/milestones.html
[11] What is STEP? – Organisation/ History (ISO). ProSTEP iViP Association,
2003, http://www.prostep.org/en/stepportal/was/orga/
[12] STEP Management Overview – History of STEP. PDIT Inc.; 1996
[13] Christoph Hörenbaum, Peter Katranuschkov, Thomas Liebich, Matthias Weise,
et al: IAI ST-4 Released Drafts. iCSS project, 2001–2002, http://cib.bau.tudresden.de/icss/structural_papers.html
5 Anhang
35
[14] Kari Karstila, Kalle Serén, et al: IAI ST-3 Released Drafts. 2002,
http://www.eurostep.fi/public/PCC_IFC/English/
[15] Kari Karstila: FinnTimber-IFC — Data exchange use cases and requirements.
Product data exchange and sharing for timber construction. 2004
5.2 Abbildungsverzeichnis
Abb. 2-1
Datenaustausch über herkömmliche Schnittstellen .....................................6
Abb. 2-2
Gemeinsame Datennutzung über ein Produktmodell ..................................6
Abb. 2-3
Geschichtliche Einordnung von Produktmodellen....................................10
Abb. 2-4
Anwendungsbereiche des gegen- wärtigen IFC- und DtH-Standards.......12
Abb. 2-5 Erweiterungen zu IFC 2x durch die Projekte ST-3, ST-4, ST-5 ...............13
Abb. 3-1
Datenfluss vom Anforderungs-Management zur Planung ........................24
Abb. 3-2
Datenfluss zwischen Planern.....................................................................25
Abb. 3-3
Datenfluss vom Zulieferer zu Planern.......................................................26
Abb. 3-4
Datenfluss vom Entwurf zur Werkplanung...............................................27
Abb. 3-5 Datenfluss zwischen Projektsteuerung, Ausführung und Zulieferung ......28
Abb. 3-6
Datenfluss von und zur Projektsteuerung..................................................29
Abb. 3-7
Datenfluss zur Nutzung und Wartung .......................................................30
Abb. 3-8
Datenfluss zwischen Nutzung und Wartung .............................................31
(Abb. 3-1…Abb. 3-8 mit freundlicher Genehmigung des Projektes FinnTimber-IFC)
IAI-Projekt ST-5
Teil II
Klassen-Referenz
Deutsche Übertragung von „Part II: Schema Reference“
Version: 1.final
Status: proposal
31. Dez. 2004
Danksagung
integrierte Planungsmethoden; Teilvorhaben 3: Produktmodell DtH“. Das DtHProjekt wird an der Brandenburgischen Technischen Universität Cottbus, Lehrstuhl
Inhalt
3
Inhalt
1 Zusammenfassung
5
Gegenwärtiger Stand................................................................................................................5
Änderungen..............................................................................................................................6
2 Einführung
8
2.1 Voraussetzungen ..............................................................................................8
2.2 Konzepte und Begriffe .....................................................................................8
2.2.1
2.2.2
2.2.3
2.2.4
Zusammenfassung der Begriffe...................................................................................8
Konzepte der modellierten Objekte .............................................................................9
Konzepte der Modell-Architektur..............................................................................11
Konzepte geometrischer Modellierung......................................................................13
3 Modell-Erweiterungen
14
3.1 Zusammenfassung der Datentypen und Property Sets...................................14
3.1.1
3.1.2
3.1.3
Durch ST-5 vorgeschlagene neue Definitionen.........................................................14
Durch ST-5 vorgeschlagen Änderungen bestehender Definitionen...........................14
Durch ST-5 verwendete, unveränderte bestehende Definitionen (Auswahl).............15
3.2 IfcTimberConstructionDomain-Schema........................................................15
3.3 Einordnung der Modell-Erweiterungen in die IFC-2x2-Architektur.............16
4 Materialien, Querschnitte
17
4.1 Material-Ressourcen ......................................................................................17
4.1.1
4.1.2
4.1.3
4.1.4
IfcMaterial .................................................................................................................17
IfcRelAssociatesMaterial...........................................................................................17
IfcExtendedMaterialProperties ..................................................................................17
Weitere Material-Ressourcen ....................................................................................18
4.2 Formen, Querschnitte, Profil-Ressourcen......................................................19
4.2.1
4.2.2
Repräsentation geometrischer Formen ......................................................................19
Formparameter ..........................................................................................................20
4.3 Mengen, Materialqualität...............................................................................20
4.3.1
4.3.2
IfcElementQuantity ...................................................................................................20
Pset_TimberElementQuality......................................................................................21
5 Bauelemente
22
5.1 Bauteile und Zurüstteile: Occurrence Objects ...............................................22
5.1.1
5.1.2
IfcBeam, IfcColumn, IfcMember ..............................................................................22
Zurüstteile..................................................................................................................22
5.2 Bauteile und Zurüstteile: Typ-Objekte ..........................................................23
5.2.1
5.2.2
5.2.3
IfcBeamType, IfcColumnType, IfcBeamTypeEnum, IfcColumnTypeEnum............23
IfcMemberType .........................................................................................................23
IfcMemberTypeEnum ...............................................................................................26
5.3 Baugruppen ....................................................................................................26
5.3.1
5.3.2
5.3.3
IfcElementAssembly, IfcWall, IfcSlab, IfcRoof........................................................26
IfcWallTypeEnum .....................................................................................................27
Schichten von Baugruppen (IfcBuildingElementPart) ..............................................27
4
IAI-Projekt ST-5 — Structural Timber Model — Teil II: Klassen-Referenz
6 Detaillierung, Anschlüsse
29
6.1 Bearbeitungen: Feature-Modellkonzept.........................................................29
6.2 Bearbeitungen: Property Sets.........................................................................32
6.2.1
6.2.2
6.2.3
6.2.4
6.2.5
6.2.6
6.2.7
IfcShapeAspect..........................................................................................................32
IfcShapeAspectProperties..........................................................................................33
IfcShapeAspectBendingProperties ............................................................................34
IfcShapeAspectCutoutProperties ...............................................................................35
IfcShapeAspectHoleProperties ..................................................................................38
IfcShapeAspectSignatureProperties...........................................................................39
IfcShapeAspectSurfaceProperties..............................................................................40
6.3 Bearbeitungen: Erweiterte Properties ............................................................41
6.3.1
6.3.2
6.3.3
6.3.4
6.3.5
6.3.6
Unterklassen von IfcShapeAspectProperties .............................................................41
6.4 Anschlüsse: Occurrence Objects....................................................................44
6.4.1
6.4.2
6.4.3
IfcFastener .................................................................................................................44
IfcMechanicalFastener (entfällt)................................................................................45
IfcDiscreteAccessory.................................................................................................45
6.5 Anschlüsse: Typ-Objekte...............................................................................46
6.5.1
6.5.2
6.5.3
IfcFastenerType .........................................................................................................46
IfcMechanicalFastenerType ......................................................................................46
IfcDiscreteAccessoryType.........................................................................................48
6.6 Anschlüsse: Property Sets..............................................................................48
6.6.1
6.6.2
6.6.3
6.6.4
6.6.5
6.6.6
6.6.7
6.6.8
Pset_ElementComponentCommon............................................................................48
Pset_FastenerGlue .....................................................................................................49
Pset_FastenerGroup...................................................................................................49
Pset_MechanicalFastenerBolt....................................................................................50
Pset_MechanicalFastenerScrew ................................................................................51
Pset_MechanicalFastenerNail....................................................................................51
Pset_MechanicalFastenerStaple ................................................................................52
Pset_MechanicalFastenerNailPlate............................................................................52
6.7 Anschlüsse: Beziehungs-Objekte...................................................................53
7 Statische Berechnung
54
7.1 Materialien .....................................................................................................54
7.1.1
7.1.2
7.1.3
IfcMechanicalMaterialProperties...............................................................................54
IfcMechanicalTimberMaterialProperties...................................................................54
7.2 Querschnitte ...................................................................................................59
7.2.1
IfcStructuralProfileProperties ....................................................................................59
7.3 Statische Elemente .........................................................................................60
7.3.1
IfcStructuralMember .................................................................................................60
7.4 Lasten, Systeme, Tragfähigkeitsnachweise ...................................................60
8 Anhang
62
8.1 Literatur..........................................................................................................62
1 Zusammenfassung
5
1 Zusammenfassung
Die Motivation des Vorhabens, Anforderungen an das Datenmodell und die Wurzeln
des Modellvorschlags im DtH-Standard werden im vorangestellten Dokument “Structural Timber Model – Part I: Requirements” (Anforderungen) besprochen.
Kapitel 2 im vorliegenden Dokument führt grundlegende Konzepte und Begriffe ein.
Kapitel 3 fasst den Umfang der auf IFC 2x2 aufzusetzenden Erweiterungen zusammen. Verbindungspunkte zum bestehenden IFC-Modell und nötige Änderungen
werden aufgezeigt.
Kapitel 4 bis 7 definieren die Datentypen des Structural Timber Model. Mit Diskussion gekennzeichnete Abschnitte und Fußnoten sind nicht Bestandteil der eigentlichen Modell-Definition. Alternativ ist Dokumentation in HTML verfügbar.
Das Dokument wird durch den folgenden Teil “Structural Timber Model – Part III:
Implementation Guide” (Implementierungshilfe) ergänzt.
Gegenwärtiger Stand
Dieses Dokument gibt den abschließenden Vorschlag des Datenmodells wieder.
Namen, Attribute und ganze Definitionen können sich noch im Zuge der Integration in den IFC-Standard durch die IAI Model Support Group ändern.
6
Änderungen
rev 1.final 31. Dezember 2004
IfcMemberType: Klärung und Illustrationen zu Bauteilachsen und
Material-Ausrichtung, ‘Fiber’ kann auch eine Richtung sein;
IfcWall: Diskussion hinzugefügt;
IfcWallTypeEnum: neuer Bezeichner FRAME;
IfcShapeAspectCutoutProperties: geometrisches Modell ist unabhängig
von Stahl- oder Holzbauweise (Weiteres regeln View-Definitionen);
IfcShapeAspectSurfaceProperties: Name in der Anwendungs-Definition
für Stahlteile durch Purpose ersetzt, IfcMaterialSelect anstelle IfcMaterial
erwähnt, Shape kann auch auf mehrere Repräsentationen zugleich
verweisen (nützlich bei Baugruppen);
Kapitel 3 aktualisiert;
geringfügige Textkorrekturen
rev 1.rc2
27. Oktober 2004
Abschnitt 5.4 gelöscht, 5.1 und 5.2 neugeordnet: IfcMember aus IFC 2x2
Addendum 1 als universelle Bauteilklasse zusammen mit IfcMemberType
verwendet, erweiterte Nutzung von IfcPlate(Type(Enum)) zurückgezogen;
IfcRelAssociatesMaterial, IfcMemberTypeEnum: auf IFC 2x2 Addendum 1 aktualisiert;
IfcElementAssembly: IfcWall, IfcSlab, IfcRoof als Alternativen hinzugefügt;
IfcShapeAspectSurfaceProperties: Verwendung des Attributs Name
geändert, Attribute Purpose und EntireBody hinzugefügt;
IfcShapeAspectCutoutProperties: Erläuterung von ‘Cut’ erweitert;
IfcMechanicalFastenerType: Leerzeichen in Typbezeichnern entfernt;
IfcExtendedMaterialProperties: Property-Bezeichner leicht gekürzt;
Kapitel 3 aktualisiert;
verschiedene kleinere Textkorrekturen
rev 1.rc1
02. Juli 2004
Abschnitte 2.2, 3, 5.3, 5.4, 6.1 aktualisiert und erweitert;
Pset_TimberMemberMaterial in Pset_TimberElementQuality umbenannt
und einige Properties nach IfcExtendedMaterialProperties verschoben;
Anwendungsdefinition von IfcPlate ediert, IfcPlateTypeEnum bereinigt;
IfcFeatureProperties in IfcShapeAspectProperties und die fünf
Untertypen entsprechend umbenannt;
Attribut IfcShapeAspectProperties.Type umbenannt, Attribute Order
gelöscht und durch ein Property in Abschnitt 6.3.1 ersetzt;
Anwendung des Surface Model in IfcShapeAspectCutoutProperties
erläutert;
IfcShapeAspectSurfaceProperties: drei Arten der Oberflächen-Angabe
erläutert, Anmerkung zu CIS/2 und Flächen-Attribut hinzugefügt;
mehrere von CIS/2 abgeleitete Properties ergänzt, Property für Schichtenanzahl von Beschichtungen gelöscht;
Repräsentation von Verbindungsmittel-Gruppen nach IfcFastener
verschoben und ediert;
Löschung von IfcMechanicalFastener vorgeschlagen;
Attribute und Anwendungsdefinition von IfcMechanicalFastenerType
erweitert;
1 Zusammenfassung
7
Abschnitt 6.6 bereinigt, Psets für Stab- und Einlass-/Einpressdübel
gelöscht;
Attribute in IfcMechanicalTimberMaterialProperties und erweiterte
Materialeigenschaften umbenannt
rev 1.β3
19. Mai 2004
Diskussion zu IfcElementQuantity hinzugefügt;
Brettstapel-Elemente von Abschnitt 5.1.2 nach 5.1.3 verschoben;
geometrische Repräsentation von IfcMemberType und IfcPlateType
erweitert, um Shape Aspects für Form-Features nutzen zu können;
alternative Extrusion zur Repräsentation von IfcPlateType hinzugefügt;
Abschnitt 5.3 erweitert;
Abschnitt 5.4 hinzugefügt;
sämtliche feature-bezogenen Entities und Psets von β2 gelöscht;
ausführliche Diskussion der Modellierungs-Entscheidungen zu Features
hinzugefügt;
Definitionsänderung von IfcShapeAspect hinzugefügt;
neu: IfcFeatureProperties, IfcFeatureBendingProperties,
IfcFeatureCutoutProperties, IfcFeatureHoleProperties,
IfcFeatureSignatureProperties, IfcFeatureSurfaceProperties;
Feature-Psets in extended properties von IfcFeatureProperties
umgewandelt;
Abschnitte 2.2 und 3 aktualisiert
rev 1.β2
07. April 2004
Illustrationen in Kapitel 6 ergänzt;
IfcHoleFeatureType: 3 von 4 informellen Vorschriften entfernt;
IfcMiterFeatureType: Anmerkung zu Attributen erweitert, Diskussion
hinzugefügt;
IfcTimberFeatureType: Klärung zu ShapeIsSquare;
IfcTimberFeatureTypeEnum: Punkte RIDGE und CHASE in EDGECUT
integriert, CUT in ENDCUT umbenannt, Konfiguration TWO zu
ENDCUT hinzugefügt, TABLEDSCARF in SCARF integriert;
Pset_ProcessingFeatureCommon: Fußnote zu Toleranzen;
Neue Properties in Pset_MechanicalFastenerGroup, ~Nail, ~Staple und
~Dowel;
IfcExternalSpace in IfcSpatialStructureElementProxy umbenant, Attribut
QuantityMultiplier gelöscht;
IfcRelAssignsToProductWithPlacement gelöscht;
IfcMechanicalWoodbasedBeamMaterialProperties und ~PanelMaterialProperties durch IfcExtendedMaterialProperties ersetzt
rev 1.β1
15. März 2004
erster Entwurf
8
2 Einführung
2.1 Voraussetzungen
Der Leser sollte mit den grundlegenden Teilen von [1] vertraut sein, insbesondere mit
der Sprache EXPRESS (STEP Teil 11).
Die Bestandteile des Structural Timber Model werden als Erweiterung aufsetzend auf
[2] formuliert. Zugrundeliegende Konzepte und Prinzipien der Modell-Architektur,
von denen einige in den nächsten Unterabschnitten besprochen werden, sind in [3]
dokumentiert.
2.2 Konzepte und Begriffe
2.2.1 Zusammenfassung der Begriffe
Begriffe in Abschnitt 2.2.2 (Modellbestandteile):
Element (building element),
Member,
Assembly,
Component,
Feature: Geometrisches Feature, Bearbeitungs-Feature,
Connection,
Semi-finished product.
Begriffe in Abschnitt 2.2.3 (Modell-Architektur):
Occurrence Object,
Type Object,
Property Set,
Objectified Relationship.
Begriffe in Abschnitt 2.2.4 (geometrische Modellierung):
Shape Representation,
Mapped Representation,
Parametric Modeling,
Feature-based Geometric Modeling.
2 Einführung
9
2.2.2 Konzepte der modellierten Objekte
Element (building element)
• ist ein physisch existierendes Objekt — es besitzt einen festen Körper und
besteht aus einem oder mehreren Materialien;
• ist ein Produkt — es wird geschaffen (gefertigt oder geliefert) und verbleibt
dauerhaft im Bauwerk oder wird vorübergehend im Bauvorhaben
verwendet.
Element kann ein zusammengesetztes oder „atomares“ Objekt bezeichnen. Spezifischere Begriffe für Aggregationen (assemblies) and „atomare“ Objekte (members,
components) werden im Folgenden definiert. Building Elements formen das Tragwerk
und das raumabschließende System des Bauwerks und werden dauerhaft verbaut.
Hinweis: Im Holzbau wird der Begriff Element oft für vorgefertigte Baugruppen verwendet, beispielsweise für Wandsegmente. Im vorliegenden Dokument
wird der Begriff mit allgemeinerer Bedeutung wie oben beschrieben gebraucht,
um eine mit dem bestehenden IFC-Modell einheitliche Bezeichnungsweise
einzuhalten.
Member
• ist ein Building Element, das meist aus einem einzigen Rohteil besteht;
• kann Räume begrenzen;
• hat oftmals Tragfunktion.
Beispiele für Members sind Sparren, Pfosten und Beplankungen.
Assembly
• ist eine Baugruppe — ein Element, das aus mehreren kleineren Elementen
zusammengesetzt ist;
• begrenzt of Räume;
• hat oft Tragfunktion.
Beispiele für Assemblies sind Wandsegmente und Dachbinder.
Man beachte, dass Assembly als Teil des Konstruktionsmodells konzeptionell nicht
mit Bauteilen des Architekturmodells wie Wänden oder Dächern gleichzusetzen ist.
Component
• ist ein Element von untergeordneter Bedeutung hinsichtlich des gesamten
Bauwerks;
• stellt üblicherweise keinen Raumabschluss her;
• kann Tragfunktion aufweisen;
• kann ein Verbindungsmittel (fastener) oder Zubehör (accessory) sein.
Beispiele für fasteners sind Nägel. Beispiele für accessories sind Balkenschuhe,
Elektro-Kanäle und Fensterrahmen.
Hinweis: In der Baustoffindustrie wird der Begriff Component oft für vorgefertigte Produkte wie Wandsegmente oder Dachbinder gebraucht. In diesem Doku-
10
ment wird dem Gebrauch in IFC entsprechend die oben erläuterte Bedeutung
zugrunde gelegt.
Feature: Geometrisches Feature, Bearbeitungs-Feature
Ein geometrisches Feature ist ein Bestandteil der Form eines Bauelements, welches
einer Ausgangsform Verfeinerungen aufprägt (shape aspect). Beispiele sind Gehrungen und Öffnungen.
Ein Bearbeitungs-Feature ist ein physischer Bestandteil eines Bauelementes, der
einem Rohbauteil durch einen Bearbeitungsprozess während der Vorfertigung oder
auf der Baustelle aufgeprägt wird. Oftmals wird dabei ein geometrisches Feature
geschaffen. Beispiele sind Gehrungsschnitte, Bohrlöcher oder Oberflächen-Beschichtungen.
Im vorgeschlagenen Structural Timber Model wird nicht zwischen geometrischen und
Bearbeitungs-Features unterschieden. Ein Bearbeitungs-Feature wird als geometrisches Feature mit zusätzlicher technologischer Information aufgefasst.
Ein Bearbeitungs-Feature wird durch einen zugehörigen Fertigungsprozess geschaffen. Die dem Feature zugeordnete technologische Information beschreibt nicht diesen
Prozess selbst, sondern dient dazu, den Prozess zu planen. Beispielsweise kann einem
Bohrloch die Information zugeordnet werden, ob auf ausrissfreie Bohrlochmündung
zu achten ist.
Connection
• ist ein Anschluss — eine physische Verbindung zwischen zwei oder mehr
Bauelementen;
• kann Verbindungsmittel, Zubehörteile oder Features als vermittelnde
Bestandteile erfordern;
• wird durch einen Fertigungsprozess während der Vorfertigung oder
Errichtung hergestellt;
• hat oft Tragfunktion.
Ein Beispiel ist der Anschluss eines Neben- an einen Hauptträger mittels Balkenschuh und Nägeln. Ein weiteres Beispiel ist ein geleimter Keilzinkenstoß an einer
Brettschichtholz-Rahmenecke.
Man beachte, dass die Connection als Beziehung zwischen verbundenen Teilen
konzeptionell verschieden von der Aggregation ist, der Beziehung zwischen einer
Baugruppe und ihren Bestandteilen.
Semi-finished product
ist ein Rohling, ein Element, welches in einem Herstellungsprozess für die Erzeugung
eines oder mehrerer Bauelemente verwendet wird.1 Es kann ein einfaches oder
zusammengesetztes Element sein. Beispiele sind
• keilgezinkte Vollholzbalken, die zu kürzeren Balken zugeschnitten werden;
1
Ein präziserer Begriff wäre semi-finished element. Ferner wird auch der Begriff Werkstück gebraucht
(workpiece).
2 Einführung
11
• großformatige Holzwerkstoffplatten, die in passende Platten aufgeteilt
werden;
• Wand-, Decken- oder Dach-Segmente, die so groß hergestellt werden wie
anlagentechnisch möglich und dann in die tatsächlich benötigten Größen
aufgetrennt werden.
Ein Rohling wird nicht innerhalb des Bauwerks platziert. Darin unterscheidet er sich
von den daraus hergestellten Bauteilen, welche an bestimmten Orten im Bauwerk
angeordnet werden. Aus ein und demselben Rohling gewonnene Teile können sogar
in unterschiedlichen Gebäuden oder Bauvorhaben Verwendung finden.
Die Klassen zur Repräsentation von Rohlingen sind dieselben wie für die letztendlichen Bauteile. Es können lediglich Instanzen mit anderer räumlicher Einordnung
erforderlich werden.
2.2.3 Konzepte der Modell-Architektur
Occurrence Object
oder “eingefügtes Objekt” stellt exakt ein physisches Element dar, das durch seine
räumliche Anordnung eindeutig identifiziert werden kann.
Mehrere Occurrence Objects können gleiche Eigenschaften und Features aufweisen,
unterscheiden sich aber stets bezüglich der Platzierung im Bauwerk. Die Stückzahl
von Bauteilen, die zur Errichtung eines Bauwerks benötigt wird, ergibt sich durch
Abzählen der Occurrence Objects.
Type Object
stellt eine Kategorie oder einen Stil mehrerer Elemente dar (oder eines oder keines
Elements).
Ein Typ-Objekt wird üblicherweise verwendet, wenn eine Mehrzahl von Elementen
mit gleicher Form, gleichem Material und sonstigen übereinstimmenden Spezifikationen auftritt. Es werden dann keine duplizierten Daten in den jeweiligen Occurrence Objects mehr benötigt. Statt dessen werden diese Daten dem Typ-Objekt zugeordnet und ein Verweis zwischen Typ und Occurrence angelegt.
Eine Reihe von Fähigkeiten der Occurrence Objects sind nicht in Typ-Objekten verfügbar. Beispielsweise können Typ-Objekte keine Aggregationen bilden, d.h. es gibt
keine zu Baugruppen zusammengesetzten Bauteiltypen.
Property Set
stellt eine Sammlung von Eigenschaften mehrerer Objekte dar (oder eines oder keines
Objekts).2
Ein Property Set wird typischerweise als Pool von miteinander verwandten Attributen
benutzt. Es kann mit mehreren Occurrence Objects verknüpft sein und wird dann
shared property set genannt.
2
Im Kontext der IFC-Architektur bezeichnet man Property Sets (namentlich IfcPropertySetDefinition)
auch als „partielle Typen“ — im Unterschied zu Typ-Objekten.
12
Die Definition eines Objektes (und zwar eines Occurrence- oder Type-Objektes) wird
durch die angefügten Property Sets verfeinert. Mehrere an das selbe Objekt angefügte
Property Sets können sich ergänzen bzw. bei Überschneidungen zuvor gesetzte
Properties überschreiben.
Ein Property Set bildet einen Baum von Properties (im häufigsten und einfachsten
Fall eine Liste von Properties). Jedes Property besitzt einen Namen und einen Wert.
Ist eine Eigenschaft eines Objektes noch nicht bekannt oder nicht sinnvoll zu belegen,
so wird das betreffende Property aus dem Property Set ausgelassen.
Es werden zwei Arten von Property Sets unterschieden:
• “Model driven” Property Sets sind Bestandteil des IFC-Modells. Sie sind in
der Sprache EXPRESS definiert.
• “Data driven” Property Sets sind erweiterbare Sammlungen von Properties.
Sie sind außerhalb des IFC-Modells definiert. Die Bedeutung der Properties
ist nicht durch ihre Unterklasse, sondern durch das Namens-Attribut
festgelegt.
Data driven Property Sets können in von der IAI herausgegebenen Dokumenten
definiert sein oder per Absprache zwischen Implementoren festgelegt werden,
potentiell sogar per projektweiser Übereinkunft von Endanwendern. Property Sets
gestatten dadurch „private“ Modell-Erweiterungen für spezielle Anwendungssoftware
auf Ebene der Attribute.3
Objectified Relationship
stellt eine Beziehung zwischen Objekten mittels eines besonderen Objektes her. Diese
Beziehungs-Objekte sind eine mächtigere Alternative zur einfacheren Methode,
Beziehungen durch ein Attribut eines der in Beziehung stehenden Objekte
darzustellen. Objectified Relationships erlauben
• Abtrennung der Beziehungs-Semantik von den in Beziehung stehenden
Objekten;
• nähere Beschreibung der Beziehung durch Klasse und Attribute des
Beziehungs-Objektes;
• Realisierung von Beziehungen über Schemagrenzen des IFCSchichtenmodells hinweg.
Beziehungs-Objekte in IFC können 1:1- oder 1:N-Beziehungen repräsentieren. M:NBeziehungen können oft in M Instanzen von 1:N-Beziehungen aufgelöst werden.4
Der übliche Fall ist eine binäre Beziehung zwischen 1 Bezugsobjekt und 1...N bezogenen Objekten. Ein Sonderfall ist eine ternäre Beziehung, an der zusätzlich 1…n
3
Darüber hinaus sind private Modellerweiterungen auch auf Eben der Klassen mittels IfcProxy und
IfcBuildingElementProxy möglich.
4
M:N- oder auch 1:N-Beziehungen sind teilweise durch die Kardinalität inverser Attribute der in
Beziehung zu stellenden Klassen verboten.
Beispiel 1: Eine Klausel in der Klasse IfcObject betreffs des inversen Attributs IsDefinedBy verbietet,
dass ein Occurrence Object durch mehr als ein Typ-Objekt definiert wird.
Beispiel 2: Die Größenbeschränkung des inversen Attributs Decomposes der Klasse IfcObject besagt,
dass ein Objekt in höchstens einer Aggregation als Teil auftreten kann.
2 Einführung
13
realisierende Objekte teilhaben (untergeordnete Objekte, deren einziger Zweck die
Herstellung der Beziehung ist).
2.2.4 Konzepte geometrischer Modellierung
Shape Representation
ist eine Sammlung geometrischer Objekte, welche die Form eines Elements symbolisieren. Ein Element kann mehrere Shape Representations in verschiedenen Kontexten
besitzen, z.B. für verschiedene Detaillierungsgrade. Modellierungs-Methoden für die
Form von Elementen sind unter anderem die Constructive Solid Geometry (CSG, d.h.
boolsche Verknüpfungen von Grundformen), Boundary Representation (B-Rep, d.h.
Beschreibung eines Körpers über seine Oberflächen) und Bounding Box (einhüllender Quader).
Mapped Representation
Die IFC erlauben, dass mehrere Elemente eine Shape Representation gemeinsam
verwenden. Dies erfolgt durch einen sogenannten Mapping-Mechanismus. Eine
Quelle, die representation map, wird von mehreren Zielen referenziert, den mapped
items. Zwischen Quelle und jedem Ziel kann noch eine Cartesische Transformation
erfolgen (Verschiebung, Drehung, Spieglung und/ oder Skalierung).
Parametric Modeling
Außer durch oben genannte geometrische Modellierungs-Methoden können Formen
auch mittels Kontroll-Parametern beschrieben werden. Einfache Modifikationen der
Parameter können komplexe Formänderungen hervorrufen. Die Parameter können
hilfreich sein, Formen in verschiedenartigen Anwendungen zu interpretieren. Voraussetzung ist, dass geeignete Parameter standardisiert wurden.
Feature-based Geometric Modeling
fasst geometrische Aspekte einer Form als zusätzliche untergeordnete Form auf.
(Siehe auch geometrisches Feature weiter oben.) Dadurch steht qualifiziertere Information über den Form-Aspekt und seine Beziehung zur übergeordneten Form zur
Verfügung. Form-Features können wiederum parametrisch modelliert werden.
Die Persistenz von Feature-Daten ist in iterativen Design-Prozessen besonders
bedeutsam. Zwar ist es möglich, Feature-Information aus unstrukturierten GeometrieDaten mittels Techniken der Feature-Erkennung zu reproduzieren. Dies ist jedoch
eine aufwändige Herangehensweise.
Durch feature-orientiertes Modellieren können nicht nur Formen beschrieben werden.
Es erlaubt darüber hinaus auch, nichtgeometrische Produktdaten einem jeweiligen
Form-Aspekt zuzuweisen. Ferner können Beziehungen zu geometrischen Objekten,
welche die Parameter eines Form-Aspektes bestimmen, für spätere Weiterbearbeitung
des Modells hinterlegt werden.
Parametrisches und feature-orientiertes Modellieren kann unter Umständen Schwierigkeiten beim Konvertieren zwischen gewachsenen Modell-Architekturen bereiten.
14
3.1 Zusammenfassung der Datentypen und
Property Sets
3.1.1 Durch ST-5 vorgeschlagene neue Definitionen
• IfcTimberConstructionDomain-Schema
(sollte in das IfcStructuralElementsDomain-Schema integriert werden)
• IfcShapeAspectProperties, IfcShapeAspectBendingProperties,
IfcShapeAspectCutoutProperties, IfcShapeAspectHoleProperties,
IfcShapeAspectSignatureProperties, IfcShapeAspectSurfaceProperties
• Pset_ElementComponentCommon, Pset_FastenerGlue,
Pset_FastenerGroup, Pset_MechanicalFastenerBolt,
Pset_MechanicalFastenerNail, Pset_MechanicalFastenerNailPlate,
Pset_MechanicalFastenerScrew, Pset_MechanicalFastenerStaple
• Pset_TimberElementQuality
• IfcMechanicalTimberMaterialProperties
3.1.2 Durch ST-5 vorgeschlagen Änderungen bestehender
Definitionen
• IfcMaterial: nicht mehr auf isotrope Materialien beschränkt
• IfcMechanicalFastener: gelöscht
• IfcMechanicalFastenerType: Attribute hinzugefügt, Anwendungsdefinition
erweitert
• IfcMemberType, IfcFastener, IfcExtendedMaterialProperties,
IfcStructuralMember:
Anwendungsdefinitionen erweitert
• IfcShapeAspect: Pflicht-Attribut in optionales Attribut geändert; informelle
Vorschrift hinzugefügt
• IfcSharedComponentElements-Schema: Property Sets für
Verbindungsmittel
• IfcMaterialPropertyResource-Schema: zusätzliche Klasse
IfcMechanicalTimberMaterialProperties als weitere unmittelbare
Unterklasse von IfcMechanicalMaterialProperties
• IfcWallTypeEnum: ein zusätzlicher Bezeichner
15
3.1.3 Durch ST-5 verwendete, unveränderte bestehende
Definitionen (Auswahl)5
• IfcRelAssociatesMaterial
• IfcGeneralMaterialProperties, IfcHygroscopicMaterialProperties
• IfcRectangleProfileDef, IfcCircleProfileDef, IfcCompositeProfileDef,
IfcArbitraryClosedProfileDef, IfcIShapeProfileDef
• IfcElementQuantity
• IfcBeam, IfcColumn, IfcMember, IfcMemberTypeEnum,
IfcDiscreteAccessory, IfcDiscreteAccessoryType, IfcFastenerType,
IfcElementAssembly, IfcWall, IfcSlab, IfcRoof, IfcBuildingElementPart
• IfcRelConnectsWithRealizingElements
• IfcStructuralProfileProperties
3.2 IfcTimberConstructionDomain-Schema6
Anwendungsfeld des IfcTimberConstructionDomain-Schemas in Verbindung mit
weiteren auf die Repräsentation physischer Aspekte von Bauwerken gerichtete
Schemata sind die Detailplanung sowie die Vorfertigung und Errichtung von
Holzbauwerken. Es werden sowohl moderne Holzbausysteme und Holzwerkstoffe als
auch traditionelle Bauweisen unterstützt.
HISTORIE: Neu von ST-5 vorgeschlagenes Schema.
Schema-Schnittstellen (4):
REFERENCE FROM IFCKERNEL
(IfcPropertySetDefinition);
REFERENCE FROM IFCMEASURERESOURCE
(IfcAreaMeasure,
IfcBoolean,
IfcLabel,
IfcLengthMeasure,
IfcPlaneAngleMeasure,
IfcPositiveLengthMeasure,
IfcPositivePlaneAngleMeasure);
REFERENCE FROM IFCPROPERTYRESOURCE
(IfcProperty);
REFERENCE FROM IFCREPRESENTATIONRESOURCE
(IfcShapeAspect);
5
Als Referenz für künftige IFC-Entwicklungen werden hier einige bereits vorhandene Klassen
angegeben, die vom Structural Timber Model mitverwendet werden.
6
Der komplette Inhalt dieses Schema sollte in die IfcStructuralElementsDomain integriert werden, da
weitreichende Überlappungen mit der Stahlbau-Detaillierung bestehen. In diesem Dokument wird das
Schema lediglich deshalb separat gehalten, um die Modellerweiterungen und ihre Schnittstellen zu
vorhandenen Datentypen zu verdeutlichen.
16
Klassen (6):
IfcShapeAspectBendingProperties, IfcShapeAspectCutoutProperties,
IfcShapeAspectHoleProperties, IfcShapeAspectProperties,
3.3 Einordnung der Modell-Erweiterungen in
die IFC-2x2-Architektur
Abb. 3-1
Erweiterungen, Änderungen und Schnittstellen im IFC-Modell
erweiterte
AnwendungsDefinition
...
6 neue Entities
soll inte- 1 neue Psets
griert werden
Architecture
Domain
Structural
Analysis
Domain
Structural
Elements
Domain
Timber
Construction
Domain
Shared
Facilities
Elements
Shared
Management
Elements
Shared
Component
Elements
Shared
Building
Elements
Domain Layer
Shared
Bldg Services
Elements
Process
Extension
IFC 2x2 Plattform
ISO/PAS 16739
außerhalb der
Plattform
neu von ST-5
1 geänd.
Attribut
Core Layer
...
Resource Layer
Measure
Resource
erweit. Anwendungs1
Entity
gelöscht,
Product Control
definition,
1
Entity
erweitert,
Exten- Extenerweiterte
8 neue Psets,
sion
sion
erweiterte Anwen- Aufzählung
dungsdefinitionen
Kernel
1 neues Entity,
erweiterte Anwendungsdefinitionen
Representation
Resource
Property
Resource
Profile
Property
Resource
Material
Property
Resource
4 Schemaschnittstellen zur TimberConstructionDomain
17
4.1 Material-Ressourcen
4.1.1 IfcMaterial7
Definition der IAI: Eine homogene Substanz, die zur Formung von Elementen verwendet werden kann. — Siehe [2] für die vollständige Definition.
Anmerkung: Verwendung anisotroper Materialien ist im IfcMaterialPropertyResource-Schema und den Anwendungsdefinitionen entsprechender ElementKlassen beschrieben.8
4.1.2 IfcRelAssociatesMaterial9
Definition der IAI: Beziehungsobjekt zwischen einer Material-Definition und
Bauteilen, auf die diese Material-Definition zutrifft. […] — Siehe [2] für die vollständige Definition.
Diskussion
IFC 2x2 Addendum 1 erweiterte die auf IfcRelAssociatesMaterial.RelatedObjects
zutreffenden Datentypen auf Unterklassen von IfcTypeProduct, z.B. IfcMemberType.
Dies wird die vorzugsweise Materialzuordnung im Structural Timber Model sein.
Typ-Objekte (im Gegensatz zu eingefügten Objekten = Occurrences) sollen soviel
wie möglich von der Bauteil-Konfiguration enthalten, einschließlich MaterialInformation. Gleiches ist auch im Stahlbau vorgesehen, siehe [4] Teil II.
4.1.3 IfcExtendedMaterialProperties10
Definition der IAI: Eine Container-Klasse für nutzerdefinierte Materialeigenschaften.
Damit wird ein Mechanismus bereitgestellt, im IFC-Modell nicht vorgesehene Eigenschaften zuzuweisen. — Siehe auch [2] und Abschnitt 7.1.3.
HISTORIE: Neue Klasse in IFC 2x.
Erweiterte Anwendungs-Definition vorgeschlagen von ST-5.
Anwendungs-Definition für Eigenschaften von Holz und Holzwerkstoffen
Dies ist eine Zusammenstellung von Eigenschaften bezüglich der Holzqualität und
Verhaltens unter Feuchte-Einfluss.
7
definiert im IfcMaterialResource-Schema; Teil der IFC-2x2-Plattform
8
Relevante Klassen sind Unterklassen von IfcElement, besonders Unterklassen von IfcBuildingElement, sowie Unterklassen von IfcBuildingElementType.
9
definiert im IfcProductExtension-Schema; Teil der IFC-2x2-Plattform
10
definiert im IfcMaterialPropertyResource-Schema (außerhalb der IFC-2x2-Plattform)
18
Name
Property-Typ
Daten-Typ
Definition
Material-Qualität
Species
Holzart von Vollholz, BrettschichtIfcProperty\
IfcLabel
holz oder Brettstapeln
SingleValue
Strength\
Sortierklasse hinsichtlich
IfcProperty\
IfcLabel
Grade
mechanischer Eigenschaften
SingleValue
Appearance\ IfcProperty\
Sortierklasse hinsichtlich
IfcLabel
Grade
ästhetischer Eigenschaften
SingleValue
Brettschichtholz, Brettstapel, Sperrholz
Layup
Konfiguration der Lamellen
IfcProperty\
IfcLabel
SingleValue
Layers
Anzahl der Lamellen;
IfcProperty\
IfcInteger
Anzahl von Furnierlagen abzüglich
SingleValue
gleichgerichteter Lagen
Plies
Gesamtanzahl der Furnierlagen
IfcProperty\
IfcInteger
SingleValue
Feuchte-Einfluss
Moisture\
bezogene Holzfeuchte
IfcProperty\
IfcPositive\
Content
SingleValue
RatioMeasure
Dimensional\ IfcProperty\
Schwind- und Quellmaß
IfcPositive\
Change\
SingleValue
RatioMeasure
Coefficient
Thickness\
Dickenquellung
IfcProperty\
IfcPositive\
Swelling
SingleValue
RatioMeasure
Hinweis: Verhältniswerte wie Holzfeuchte und Quellmaß werden oft in %
angegeben. Diese Werte sind durch 100% zu dividieren, um sie als
dimensionsloses IfcPositiveRatioMeasure abzulegen.
IfcExtendedMaterialProperties dient ferner als Container für Materialeigenschaften,
die in bauphysikalischen Berechnungen benötigt werden, z.B. die Wärmeleitfähigkeit.
Siehe [2] für die entsprechende Anwendungs-Definition.
4.1.4 Weitere Material-Ressourcen11
IfcGeneralMaterialProperties enthält die Dichte. IfcHygroscopicMaterialProperties
enthält die Dampfdurchlässigkeit. Siehe [2] für Definitionen dieser Klassen. Siehe
Abschnitt 4.3 für materialbezogene Property Sets. Siehe Abschnitt 7.1 für statische
Materialeigenschaften.
11
definiert im IfcMaterialPropertyResource-Schema (außerhalb der IFC-2x2-Plattform)
19
4.2 Formen, Querschnitte, Profil-Ressourcen
4.2.1 Repräsentation geometrischer Formen
Siehe auch “Part III: Implementation Guide” sowie Geometrie-Anwendungsdefinitionen von Bauteilobjekten in folgen Abschnitten.
Standardformen stabförmiger Bauteile
Holzbauteile können oft durch IfcExtrudedAreaSolid grafisch repräsentiert werden.12
Für derartige Extrusionen verwendete Profile (Attribut IfcExtrudedAreaSolid.SweptArea) sind vor allem
• IfcRectangleProfileDef
z.B. für NH-, BSH- und LVL-Balken;
• IfcCircleProfileDef
z.B. für Rundholz;
• IfcCompositeProfileDef
z.B. für zusammengesetzte Querschnitte;
• IfcArbitraryClosedProfileDef z.B. für industrielle Komposit-Querschnitte;
• IfcIShapeProfileDef
z.B. für industrielle Doppel-T-Balken.
In diesen Standardfällen erfolgt die Extrusion in Längsrichtung [d.h. orthogonal zum
Profil, somit ist der Querschnitt identisch mit dem Profil und die Schnittlänge identisch mit der Extrusionslänge]. Weitere Übereinkünfte werden in den geometrischen
Anwendungs-Definitionen der entsprechenden Bauteil- und Bauteiltyp-Klassen
getroffen.
Standardformen plattenartiger Bauteile
IfcArbitraryClosedProfileDef ist die nützlichste Profildefinition für ebene flächige
Bauteile (Holzwerkstoffplatten) mit beliebigem Umriss. IfcRectangleProfileDef
könnte potentiell bei rechteckigen Platten verwendet werden, jedoch wird [zwecks
Einheitlichkeit und wegen des zentrischen lokalen Koordinatenursprungs des Rechteckprofils] IfcArbitraryClosedProfileDef auch für vorgezogen. Die Extrusion erfolgt
in Dickenrichtung, rechtwinklig zum Profil. Somit ist das Profil identisch mit dem
Plattenumriss und die Extrusionsrichtung identisch mit der Materialdicke.
Platten- und brettartige Bauteile können alternativ auch wie Balken in Längsrichtung
extrudiert werden. Die Plattendicke muss dann der Profilbeschreibung entnommen
werden.
Weitere Übereinkünfte werden in den geometrischen Anwendungs-Definitionen der
entsprechenden Bauteil- und Bauteiltyp-Klassen getroffen.
Abweichende Bauteilformen
Irreguläre Bauteilformen wie Pult- und Satteldachbinder aus BSH oder LVL sowie
gekrümmte Binder bis hin zu Bögen können meist als IfcExtrudedAreaSolid mit
seitwärts extrudierter IfcArbitraryClosedProfileDef modelliert werden. IfcSectionedSpine mit längsgerichteter gekrümmter Erzeugender wäre ebenfalls anwendbar.
12
IfcExtrudedAreaSolid ist im IfcGeometricModelResource-Schema definiert. Profil-Definitionen
finden sich im IfcProfileResoure-Schema. Beide Schemata gehören zur IFC-2x2-Plattform.
20
Gekrümmte Balken mit lediglich leichter Vorkrümmung — wie sie zwecks teilweisen
Ausgleichs von Verformungen unter Last v.a. bei BSH-Balken eingeprägt wird —
sind als gerade Balken zu repräsentieren. Die Vorkrümmung wird lediglich als
nichtgeometrische Eigenschaft des Bauteil angegeben.
Gebogenes Sperrholz ist einfach gekrümmt und kann deshalb durch seitwärtige
Extrusion dargestellt werden, nötigenfalls in Verbindung mit Clipping. Die Extrusionsrichtung ist dann senkrecht zur Sperrholzdicke. Andere Schalen, etwa aus genagelten Bohlen zusammengesetzte freie Formen, können doppelt gekrümmt sein und
sind dann mittels des gegenwärtigen IFC-Geometriemodells lediglich näherungsweise
durch IfcFacetedBrep modellierbar.
Voll detaillierte Formen von Holzbauteilen einschließlich aller Bearbeitungen,
namentlich zimmermannsmäßig und mittels Abbundanlagen zu produzierende
Formen, werden in der Regel mittels IfcFacetedBrep modelliert.
Andere komplizierte Formen wie die von Verbindungsmitteln, z.B. Balkenschuhen,
können mit IfcFacetedBrep oder als 2D-Projektionen dargestellt werden.
Aggregationen (Baugruppen)
Die geometrische Repräsentation einer Baugruppe wird nicht explizit modelliert, da
sie sich aus der Summe der Repräsentationen ihrer Bauteile ergibt. Es kann aber eine
zusätzliche vereinfachte Repräsentation explizit gegeben werden.
Vereinfachte Repräsentation
Beliebige Körper können stets auch vereinfacht modelliert werden, insbesondere als
IfcBoundingBox.
4.2.2 Formparameter
Siehe IfcProfileResource-Schema in [2] für geometrische Profil-Parameter.
Siehe Abschnitt 7.2 für statische Profil-Parameter.
4.3 Mengen, Materialqualität
4.3.1 IfcElementQuantity13
Definition der IAI: Eine Element-Quantität (Mengenangabe) definiert eine Gruppe
abgeleiteter Maße bezüglich physischer Elementeigenschaften. — Siehe [2] für die
vollständige Definition.
Diskussion
Eine für Stücklisten von Holz- und Stahl-Teilen relevante Eigenschaft fehlt in
IfcElementQuantity: Gehrungswinkel. Um Winkelmaße in einem Property Set für
Mengen angeben zu können, wäre eine neue Unterklasse von IfcPhysicalQuantity
erforderlich. Der vorliegende ST-5-Vorschlag enthält keine derartige neue Klasse.
13
definiert im IfcProductExtension-Schema; Teil der IFC-2x2-Plattform
21
Statt dessen sollen Daten der Gehrungswinkel unmittelbar aus dem Feature-Entity
IfcShapeAspectCutoutProperties entnommen werden.
4.3.2 Pset_TimberElementQuality14
Anwendbarkeit
zutreffende Klassen
zutreffende Typen
Definition
Projekt-Code
generelles Property Set
Unterklassen von IfcBuildingElement, IfcBuildingElementType, IfcBuildingElementPart oder IfcCovering
Definition der IAI: Material- und qualitätsbezogene
Eigenschaften verschiedenster Hölzer und Holzwerkstoffe,
insbesondere zur Verwendung in Stücklisten
ST5
Property-Definitionen
Name
Property-Typ Datentyp
Definition
Eigenschaften von zusammengesetzten Bauteilen
(z.B. Brettstapel oder Brettschalungen)
BoardDepth IfcProperty\
Dicke der Bretter und Bohlen, aus
IfcPositive\
SingleValue
LengthMeasure denen das Bauteil hergestellt wird
BoardWidth IfcProperty\
Breite der Bretter und Bohlen, aus
IfcPositive\
SingleValue
BoardLength IfcProperty\
Länge der Bretter und Bohlen, aus
IfcPositive\
SingleValue
Eigenschaften bezüglich der Vorfertigung
Surface\
Oberflächenqualität, z.B. ‘Rough’ =
IfcProperty\
IfcLabel
Quality
sägerau, ‘Planed’ = gehobelt,
SingleValue
‘Grinded’ = geschliffen
Lengthwise\ IfcProperty\
Ausführung der Längskanten, z.B.
IfcLabel
EdgeQuality SingleValue
‘Rough’ = sägerau, ‘Planed’ =
gehobelt, ‘Grinded’ = geschliffen,
‘Plain’ = stumpf, ‘Lap’ = mit Falz,
‘Groove’ = genutet, ‘Tongue and
Groove’ = mit Nut und Feder
Widthwise\
Ausführung der Querkanten, z.B.
IfcProperty\
IfcLabel
‘Rough’, ‘Planed’, ‘Grinded’,
‘Plain’, ‘Lap’, ‘Groove’,
‘Tongue and Groove’
Precamber
Vorkrümmung eines BSH-Trägers
IfcProperty\
IfcPositive\
SingleValue
LengthMeasure oder eines Fachwerkbinders, als
Absolutwert angegeben
Precamber\
Vorkrümmung eines BSH-Trägers
IfcProperty\
IfcPositive\
Ratio
SingleValue
RatioMeasure oder eines Fachwerkbinders, als
Stichverhältnis angegeben
14
vorgeschlagen für das neue IfcTimberConstructionDomain-Schema oder IfcStructuralElementsDomain-Schema (außerhalb der IFC-2x2-Plattform)
22
5 Bauelemente
5.1 Bauteile und Zurüstteile:
Occurrence Objects
5.1.1 IfcBeam, IfcColumn, IfcMember15
IfcBeam repräsentiert ein horizontales oder nahezu horizontales tragendes Bauteil.
IfcColumn repräsentiert ein vertikales oder nahezu vertikales Bauteil, welches Lasten
vom Kopf zum Fuß weiterleitet. Ein IfcMember ist ein Bauteil, das Lasten zwischen
Auflagern oder darüber hinaus trägt, oder auch ein nichttragendes Bauteil. — Siehe
[2] für die vollständigen Definitionen.
Diskussion
Das Structural Timber Model wird die Definitionen von IfcBeam, IfcColumn und
IfcMember nicht abändern. Mehrere Gesichtspunkte sind aber durch „View”Spezifikationen zu regeln:
• IfcMappedItem ist die vorzugsweise — oder auch einzige unterstützte —
Form der geometrischen Repräsentation für Holzbauteile.
• Typangabe erfolgt mittels IfcRelDefinesByType und eines zutreffenden
Untertyps von IfcBuildingElementType.
• Material wird dem definierenden Typobjekt zugewiesen, nicht direkt dem
eingefügten Objekt.
IfcMember kann stabförmige, aber auch plattenförmige und gekrümmte Bauteile
darstellen. Wenn ein Anwenderprogramm nicht sicher sein kann, ob ein Bauteil als
IfcBeam/ IfcColumn/ IfcMember abgebildet werden sollte, ist letzterem der Vorzug zu
geben.
5.1.2 Zurüstteile
Zurüstteile können durch IfcDiscreteAccessory oder, im Falle von TGA-Elementen,
durch Unterklassen von IfcDistributionElement repräsentiert werden. Siehe Abschnitt 6.4 ff. für Verbindungsmittel u.a. in Anschlüssen verwendete Bauteile.
Teile, die andere Elemente bekleiden — etwa Beplankung, Verkleidung, Schindeln
oder Dampfsperren — können als IfcCovering repräsentiert werden. Falls jedoch
detailliertere Geometrie- und Mengeninformation für die Fertigung benötigt wird,
z.B. einzelne Plattenkonturen einer Beplankung, sind entsprechend viele Instanzen
von IfcMember oder IfcPlate anstelle von IfcCovering zu verwenden.
15
definiert im IfcSharedBldgElements-Schema; Teil der IFC-2x2-Plattform
5 Bauelemente
23
5.2 Bauteile und Zurüstteile: Typ-Objekte
16
5.2.1 IfcBeamType, IfcColumnType, IfcBeamTypeEnum,
IfcColumnTypeEnum
Siehe [2] für Definitionen dieser Klassen und Aufzählungstypen.
Diskussion
In Holzkonstruktionen ist IfcBeamType anwendbar für Deckenbalken, Stürze und
Hauptträger, vor allem sichtbare Träger. IfcColumnType ist anwendbar für Hauptstützen, namentlich sichtbare Stützen. IfcMemberType ist anwendbar für alle anderen
stabförmigen Holzbauteile.
So gut wie alle Bauteile in Holzrahmen-Konstruktionen sind mit
IfcMemberType am besten zu beschreiben.
Die holzbauspezifische Anwendungs-Definition für IfcMemberType im nächsten
Abschnitt gilt auch für IfcBeamType und IfcColumnType, wird aber nicht explizit in
deren Dokumentation übernommen.
5.2.2 IfcMemberType
Siehe [2] für die Definition der IAI.
HISTORIE: Neue Klasse in IFC 2x2.
Zusätzliche Anwendungs-Definition für Holzbauteile vorgeschlagen von ST-5.
IFC2x2 ADDENDUM ÄNDERUNG: Die Klasse IfcMember wurde ergänzt,
um als eingefügtes Objekt mit IfcMemberType kombiniert zu werden.
Anwendungs-Definition für Stahlbauteile
Siehe [2].
Anwendungs-Definition für Bauteile in Holzkonstruktionen
IfcMember(Type) kann alle Arten von Bauteilen repräsentieren, einschließlich
Balken, Stielen, Platten, Bögen, Brettstapeln. Die selben Konventionen wie für
Stahlbauteile gelten hinsichtlich Materialzuweisung, Positionsnummer, nichtgeometrischer Eigenschaften und mengen-/ stücklisten-bezogener Eigenschaften.
Geometrische Repräsentation
Eine oder mehrere der folgenden Repräsentationen kann als Representation Map
angefügt werden: Maximal je eine Repräsentation des Namens ‘Body’, ‘Blank’,
‘Fiber’ und/oder ‘Layup’ kann pro Repräsentations-Kontext existieren. Mehr als eine
Repräsentation des Namens ‘Bending’, ‘Cutout’, ‘Hole’, ‘Signature’ und/ oder
‘Surface’ kann in einem Repräsentations-Kontext existieren.
reprs. identifier representation type
‘Body’
‘SweptSolid’, ‘Clipping’,
‘Brep’ oder ‘CSG’
16
Inhalt
Körper des Bauteils einschließlich alle
Form-Features
24
‘Blank’
‘SweptSolid’
Körper des Rohlings ohne FormFeatures, d.h vor Bearbeitung
eine IfcCurve oder
eine Linie, Kurve oder Richtung parallel
eine IfcDirection
bzw. konzentrisch zur Faser- oder Leimrichtung
eine IfcDirection
eine Richtung senkrecht zu den
Lamellen (zur Leimrichtung);
bei asymmetrischer Anordnung von
Lamellen unterschiedlicher Sortierklassen zeigt die Richtung von der Zugzur Druckseite
siehe IfcFeatureBendingProperties,
IfcFeatureCutoutProperties,
IfcFeatureHoleProperties,
IfcFeatureSignatureProperties,
IfcFeatureSurfaceProperties
‘Fiber’
‘Layup’
‘Bending’,
‘Cutout’,
‘Hole’,
‘Signature’,
‘Surface’
Die ‘SweptSolid’-Repräsentation wird folgendermaßen eingeschränkt:
• IfcRectangleProfileDef ist zu unterstützen. IfcIShapeProfileDef, IfcCircleProfileDef, IfcCompositeProfileDef und IfcArbitraryClosedProfileDef
sollten ebenfalls unterstützt werden.
• Die Extrusionsachse stehe senkrecht auf dem Profil, d.h.
IfcExtrudedAreaSolid.ExtrudedDirection.DirectionRatios = (0,0,1).
In den folgenden Illustrationen und Erläuterungen bezeichnen xP und yP das 2DKoordinatensystem der Profildefinition (im Falle einer IfcParameterizedProfileDef:
vor Transformation durch Position). zE ist die Extrusionsrichtung.
Im Falle gewöhnlicher Balken und Stiele stimmt IfcExtrudedAreaSolid.Depth mit der
Bruttolänge des Bauteils überein. Bei Holzwerkstoffplatten kann das Profil entweder
den Umriss oder einen Schnitt des Profils repräsentieren. D.h. die Extrusionslänge
entspricht entweder der Plattendicke oder einer Plattenlänge.
Abb. 5-1
Extruded Area Solids für einfache Balken und Platten
zE
Profil
Balken
Holzwerkstoffplatte
Platte (Alternative)
Gekrümmte Balken mit lediglich leichter Vorkrümmung zum teilweisen Ausgleich
von Verformungen unter Last sind als gerade Balken zu repräsentieren. Die Vorkrümmung kann in einem Property Set angegeben werden.
Material-Ausrichtung
Sofern nicht mittels ‘Fiber’- und/ oder ‘Layup’-Repräsentationen angegeben, werden
bei IfcExtrudedAreaSolid-Repräsentation folgende Annahmen zur Materialausrichtung getroffen:
5 Bauelemente
25
• Stabförmige Bauteile:
Die Holzfaser ist parallel zu zE gerichtet. BSH-Lamellen bzw. LVL-Furniere
sind in yP- oder xP-Richtung übereinandergelegt. D.h. Leimflächen liegen
koplanar zu xP zE oder yP zE.
Wenn xP die Breite und yP die Höhe des Balkens ist, so tritt Biegung um die
starke Achse infolge Last in der yP zE-Ebene auf. Längskraft wirkt parallel
zu zE.
• Bei asymmetrisch zusammengesetztem BSH liegt die Druckzone in globaler
z-Richtung oben, hängt also von der Platzierung des eingefügten IfcMember
oder IfcBeam ab.
• Holzwerkstoffplatten:
Die Schichtung ist orthogonal zur Dickenrichtung des geometrischen
Modells ausgerichtet. Scheibenbeanspruchung erfolgt somit in der durch
Länge × Breite aufgespannten Ebene. Plattenbeanspruchung erfolgt unter
Lasten, die parallel zur Dickenrichtung ausgerichtet sind. Hinsichtlich
Faserrichtung der Deckschichten oder Anordnung asymmetrischer
Schichtungen gibt es keine implizite Annahme beim IfcExtrudedAreaSolid.
Abb. 5-2
Bei IfcExtrudedAreaSolid implizierte Material-Ausrichtung
yP
yP
zE
zE
xP
ite
zE
xP
BFU
Lä
ng
e
xP
Bre
yP
Holz
BSH
LVL
Falls eine ‘Fiber’-Repräsentation vorhanden ist, so sind E-Modul und zulässige
Spannungen in der angezeigten Richtung am größten. D.h. der Biegewiderstand
orthotroper Materialien ist um die Achse senkrecht zu dieser Richtung am größten.
Beispiele für ‘Fiber’- und ‘Layup’-Repräsentationen
‘Body’Repräsentation
‘Body’Repräsentation
‘Fiber’Repräsentation
Zugseite
‘Layup’Repräsentation
F
de ase
r D rric
ec htu
ks n
ch g
ich
t
Abb. 5-3
‘Fiber’Repräsentation
Siehe [2] für EXPRESS-Spezifikation, Attribut-Definitionen und Vererbungsgraph
von IfcMemberType.
26
5.2.3 IfcMemberTypeEnum
Definition der IAI: Dieser Aufzählungstyp definiert verschiedene Typen stabförmiger
Bauteile, die ein IfcMemberType annehmen kann. — Siehe [2] für die Definition.
Diskussion
Die Bezeichner PLATE und STUD sollten nicht für geneigte Bauteile verwendet
werden, jedenfalls im Kontext der Holztafelbauweise. Geneigte Teile in Holztafelwänden sollten mit USERDEFINED belegt werden. Diese Einschränkung, soweit
sinnvoll, sollte jedoch in einer „View“-Definition statt auf Modell-Ebene festgelegt
werden.
Der Bezeichner PLATE bezieht sich übrigens nicht auf Platten, sondern auf Rähm
und Schwelle in Ständerwänden.
Weitere häufig benötigte Bauteil-Bezeichnungen sollten nicht in IfcMemberTypeEnum aufgenommen werden, da sich diese Aufzählung in der InteroperabilitätsSchicht (d.h. im nicht fachspezifischen Teil von IFC) und zudem in der IFC-Plattform
befindet (im entwicklungstechnisch stabilen Teil des IFC-Modells). Es steht das mit
Zeichenketten belegbare geerbte Attribut ElementType in IfcMemberType für freie
Typzuweisungen zur Verfügung.
5.3 Baugruppen
5.3.1 IfcElementAssembly, IfcWall, IfcSlab, IfcRoof 17
Siehe [2] für Definitionen. Baugruppen stehen üblicherweise mit Bauteilen wie
IfcMember über IfcRelAggregates in Beziehung.
Noch offen: Property-Sets für Transportplanung und Errichtung, z.B.
Transportgewicht, Ort des Zusammenbaus von IfcWall und IfcSlab...
Diskussion
It is often necessary to distinguish between aggregated (built-up) and “monolithic”
wall objects and other elements. Since it is not possible to introduce a new attribute
for this purpose without breaking IFC 2x platform compatibility, a distinction of such
elements can only be accomplished by means of existing inverse attributes which are
inherited from
Oft ist es erforderlich, zusammengesetzte von „monolithischen“ Wandobjekten u.a.
Elementen zu unterscheiden. Zu diesem Zweck ein neues Attribut einzuführen, wäre
nicht kompatibel zur IFC-2x-Plattform. Deshalb ist eine derartige Unterscheidung mit
Hilfe von IfcObject geerbter inverser Attribute durchzuführen:
• Zusammengesetzte Element können an der Größe von IsDecomposedBy
erkannt werden.
• Partielle Elemente können an der Größe von Decomposes erkannt werden.
17
IfcElementAssembly ist definiert im IfcProductExtension-Schema. IfcWall, IfcSlab, IfcRoof sind im
IfcSharedBldgElements-Schema definiert. Beide Schemas sind Teil der IFC-2x2-Plattform.
5 Bauelemente
27
• Beide dieser INVERSE SETs sind leer bei „atomaren“ Elementen.
5.3.2 IfcWallTypeEnum18
Definition der IAI: Dieser Aufzählungstyp definiert, welche unterschiedlichen Typen
ein IfcWallType-Objekt darstellen kann:
• STANDARD: Eine Standardwand, vertikal extrudiert und mit konstanter
Dicke entlang des Wandpfads.
• POLYGONAL: Eine polygonale Wand, vertikal extrudiert, mit wechselnder
Dicke entlang des Wandpfads.
• SHEAR: Wandscheibe(?) mit nicht-rechteckigem Querschnitt.
• FRAME: Eine Ständerwand, bestehend aus Ständern, Beplankung usw.,
sollte vertikal extrudiert sein und eine konstante Dicke entlang des
Wandpfads besitzen.
• USERDEFINED: Nutzerdefiniertes Wandelement.
• NOTDEFINED: Undefiniertes Wandelement
HISTORIE: Neuer Aufzählungstyp in IFC2x2.
Zusätzlicher Bezeichner FRAME vorgeschlagen von ST-5.
EXPRESS-Spezifikation:
TYPE IfcWallTypeEnum = ENUMERATION OF
(STANDARD,
POLYGONAL,
SHEAR,
FRAME,
USERDEFINED,
NOTDEFINED);
END_TYPE;
Discussion
Der Bezeichner FRAME kann für Holz- und Stahl-Ständerwände, Innen- und Außen-,
tragende und nichttragende Wände verwendet werden. Geometrische Eigenschaften
von STANDARD-Wänden treffen auch auf Ständerwände zu.
5.3.3 Schichten von Baugruppen (IfcBuildingElementPart)
Baugruppen in der Holzrahmenbauweise (Wand-, Decken-, Dachsegmente) bestehen
aus Schichten. Es ist für verschiedenste Zwecke wichtig, die Zugehörigkeit von Bauteilen zu Schichten zu kennzeichnen. Dies kann auf zwei Wegen erfolgen:
• IfcElementAssembly wird aus Instanzen von IfcBuildingElementPart19
zusammengesetzt, und diese aus den zugehörigen Bauteilen. Ein Vorteil
dieser Methode ist, dass Bearbeitungen dreistufig zugeordnet werden
können: Den Bauteilen, den Schichten, oder der gesamten Baugruppe, je
nach dem, wann und wie die Bearbeitung erfolgen soll.
18
19
definiert im IfcStructuralElementsDomain-Schema (außerhalb der IFC-2x2-Plattform)
28
• IfcElementAssembly wird unmittelbar aus den Bauteilen zusammengesetzt.
Parallel werden Bauteile der selben Schicht mittels IfcRelAssignsToGroup
und IfcGroup zu Gruppen zusammengefasst. Ein Vorteil dieser Methode ist,
dass diese Gruppen gleich über alle gleichartig geschichteten Baugruppen
des gesamten Bauwerks gelegt werden können. Damit können alle Bauteile,
die die gleiche Funktion erfüllen, effizient aufgefunden werden.
Beide Methoden haben einen Nachteil: Es gibt keine Möglichkeit direkter Synchronisation mit dem Schichtenmodell des Architekturmodells. Dieses Teilmodell verwendet IfcMaterialLayer/ ~Set/ ~SetUsage zur Schichtenangabe. Es bleibt nur der Weg,
dass Applikationen, welche beide Schichtenmodelle beherrschen, für den Abgleich
zwischen Schichten-Information zwischen Architektur- und Konstruktionsmodell
sorgen.
Wählt man die erste Methode über IfcBuildingElementPart, so können die im Architekturmodell verwendeten IfcMaterialLayer parallel auch den IfcBuildingElementPart-Instanzen zugewiesen werden. Dies allein stellt allerdings noch nicht die Synchronität der Teilmodelle sicher. — Wählt man die zweite Methode mit IfcGroup, so
kann der Gruppe als solcher kein Material zugewiesen werden. Es ist auch nicht
empfehlenswert, den Einzelbauteilen innerhalb einer Schicht zusätzlich zu ihrem
eigentlichen Material auch noch das IfcMaterialLayer der Schicht zuzuweisen, da
doppelte Materialzuweisungen zu Problemen in vielen Anwendungen führen dürften.
29
6.1 Bearbeitungen: Feature-Modellkonzept
Herangehensweise in ST-5 β1
In der ersten und zweiten Beta-Version des Structural Timber Model wurden zwei
Occurrence Objects vorgeschlagen, IfcProcessingFeature und IfcSurfaceTreatment.
IfcProcessingFeature erweiterte das IFC-2x2-Featurekonzept, das vom ST-3-Projekt
für den Stahlbeton-Fertigteilbau eingeführt wurde.
Der Vorteil von Features auf der Occurrence-Seite ist die Vielfalt an Beziehungen,
die diese Objekte eingehen können. Dazu gehören Dekompositionen, Realisierung
von Anschlüssen, Zuweisungen verschiedenster Art (z.B. zu weiteren Objekten außer
demjenigen Produkt, das das Feature besitzt, zu Prozessen oder zu Akteuren).
Abb. 6-1
Beziehungen zwischen Bauteilen und Features in ST-5 β1
occurrence objetcs
type objects
(ABS) IfcElementType
IfcRel...
S[1:?]
(ABS) IfcElement
IfcRel...
(ABS) IfcFeatureElementType
1
IfcCutoutFeatureType
IfcRel...
S[1:?]
IfcRel...
IfcProcessingFeature
S[1:?]
IfcSurfaceTreatment
IfcHoleFeatureType
IfcMiterFeatureType
IfcTimberFeatureType
Herangehensweise in ST-5 β3 20
Die dritte Beta-Version löschte die zwei Occurrence-Objekte und verlagerte die Feature-Information im Wesentlichen in die geometrische Repräsentation der
Bauelemente. Dies hat mehrere Vorteile:
• Sämtliche Features eines Elements können in dessen Typ-Objekt eingeordnet werden, siehe Abb. 6-2. Damit wird das Typ-Objekt eine echte
Repräsentation der „Fertigungs-Position“. Die kompletten FertigungsMerkmale identisch herzustellender Elemente wird in einer einzigen Instanz
des zugeordneten Typ-Objekts konsolidiert.
20
Im ST-5 Release Candidate 1 sind die selben Feature-Klassen und Beziehungen wie in ST-5 β3
enthalten. Es wurden nur die Klassennamen in IfcShapeAspect[…]Properties geändert, um sie von den
konzeptionell unterschiedlichen IFC-2x2-Feature-Klassen des ST-3-Projektes abzuheben.
30
Abb. 6-2
Beziehungen zwischen Bauteilen und Features in ST-5 β3
occurrence objetcs
type objects
IfcRel...
S[1:?]
(ABS) IfcElement
*L[1:?]
(ABS) IfcFeatureProperties
1
IfcFeatureBendingProperties
IfcFeatureCutoutProperties
IfcFeatureHoleProperties
IfcFeatureSignatureProperties
Abb. 6-3
Alternative Beziehungen in ST-5 β3 (für Baugruppen)
occurrence objetcs
(partial) type objects
(ABS) IfcElement
1
IfcRel...
S[1:?]
• Es ist darüber hinaus immer noch möglich, Features in Occurrence Objects
anzusprechen, siehe Abb. 6-3.
• Anwendungen außerhalb der Tragwerksplanung und Konstruktion sind
nicht auf das Feature-Konzept der β1 vorbereitet. Alle existierenden und die
meisten künftigen IFC-Implementierungen wären nicht in der Lage, die
geometrischen Repräsentationen des Elements und seiner Features zusammenzusetzen. Das Konzept der β3 integriert die geometrische Repräsentation der Features in die Repräsentation des Elements. Applikationen fremder
Disziplinen können nun die Zusatzstrukturen der Features ignorieren. Es
genügt, wenn sie wie üblich auf die nun vollständige ‘Body’-Repräsentation
zugreifen.
• Es ist nun problemlos möglich, sämtliche Klassen für Bearbeitungs-Features
aus der Interoperabilitätsschicht der IFC herauszuhalten. Der β3-Vorschlag
ordnet seine Feature-Klassen der Domänenschicht zu. Interoperation mit
Anwendungen anderer Disziplinen beschränkt sich hinsichtlich der Bearbeitungen auf Geometrieressourcen.
• Das β1-Konzept impliziert Boolsche Subtraktionen oder Additionen der
Feature-Formen, d.h. CSG (Constructive Solid Geometry). Das neue
31
Konzept erlaubt außer CSG auch B-Rep (Boundary Representation, aber
auch Oberflächen-Modelle allgemein). B-Rep ist im Holzbau-CAD/CAM
besser geeignet, da es sich um oberflächen-orientierte Anwendungen
handelt [mit direkter Ansprache der Schnittebenen].
• Ein weiterer Vorteil liegt in der einfacheren Migration von den Produktmodellen DtH [5] und PSS [6] nach IFC. Dies schließt auch das BiegeFeature ein, welches in β1-2 nicht realisiert werden konnte.
• Einer ersten Sichtung des CIS/2 LPM zufolge dürfte der β3-Vorschlag auch
einem Übergang zwischen CIMsteel und IFC entgegenkommen. LPM
enthält Features sowohl auf der Typ- als auch auf der Occurrence-Seite.
Mit dem Feature-Konzept der ST-5 β3 sind auch Nachteile verbunden:
• Die Möglichkeit, Feature-Objekte in diverse Beziehungen einzubringen,
geht verloren.
• Das seit IFC 2x2 existierende Feature-Konzept von ST-3 wird von ST-5
nicht mitbenutzt.
• Eine gewisse Plattform-Änderung an der existierenden Klassendefinition
IfcShapeAspect ist erforderlich.
Das mit ST-5 β3 vorgeschlagene Feature-Konzept ist durchaus nicht vollkommen neu
in IFC. Vielmehr lehnt es sich stark an die Modellierung der Rahmen und Flügel von
Fenstern und Türen an. Rahmen und Flügel können als Features aufgefasst werden,
die sowohl parametrisch als auch mit expliziter Geometrie modelliert werden können.
Bei expliziter Geometrie werden die Features als „Shape Aspects“ der Tür- bzw.
Fenster-Geometrie angesprochen. Dieses Konzept wurde mit IFC 2.0 eingeführt.
Der mit ST-5 β3 bzw. rc1 vorliegende Vorschlag dürfte für die jetzt absehbare künftige Praxis ein ausreichend leistungsfähiges Feature-Konzept für den Holzbau und
sicher auch für den Stahlbau bereitstellen. Besonders fortgeschrittene Anwendungen
werden jedoch eventuell die Fähigkeit von Feature-Objekten benötigen, Beziehungen
zu anderen Objekten außer dem direkt übergeordneten Bauteil-Objekt einzugehen.
Dies würde Feature-Occurrence-Objects erfordern. Beispiele:
• Fortgeschrittene Anwendungen des Stahlbetonbaus können erfordern,
Bewehrungen mit Features der Schalform, z.B. Konsolen oder Durchbrüchen, zu assoziieren.
• Fortgeschrittene Produktionsplanungssysteme können erfordern, Bearbeitungs-Features mit Fertigungsprozessen, Akteuren oder Kosten zu
assoziieren.
• Der Modellaufbau von CIS/2 LPM erlaubt potentiell, dass Feature-Objekte
auch mit „fremden“ Objekten Beziehungen eingehen. Fortgeschrittene
CIMsteel-IFC-Übersetzungssoftware könnte dieselbe Fähigkeit in IFC
erforderlich machen. Allerdings ist derzeit nicht geklärt, ob derartige
Beziehungen tatsächlich von LPM-Implementierungen verwendet werden.
Parametrische and explizite Feature-Modellierung
Sowohl das β1- als auch das β3-Konzept beinhaltet teils parametrische, teils explizite
geometrische Modellierung von Features. Die Kombination dieser Vorgehensweisen
war in β1 weniger klar gelöst. So enthielt das IfcTimberFeatureType der β1 (gesägte
32
und gefräste Bearbeitungen) eine spezielle Art von Oberflächenmodell, welches
explizite Knotendaten mit impliziter Topologie-Information vermischte. Dieses
Modell wurde durch IfcShapeAspectCutoutProperties in Verbindung mit dem
gewöhnlichen Oberflächenmodell der IFC-Geometriemodell-Ressource ersetzt.
Das parametrisch modellierte IfcMiterFeatureType von β1 (Gehrungen) wurde zugunsten des universelleren IfcShapeAspectCutoutProperties gelöscht. Dieses verwendet zunächst explizite Geometrie, kann aber zusätzlich oder alternativ durch Parameter gesteuert werden. Anforderungen verschiedener Anwendungsfälle — z.B.
konventioneller Zimmermannsbau auf der einen und Holztafelbau auf der anderen
Seite — werden somit auf Modellebene besser in Einklang gebracht.
6.2 Bearbeitungen: Property Sets
6.2.1 IfcShapeAspect21
Definition aus ISO/IS 10303-41:1994: Der Form-Aspekt (shape aspect) ist ein
identifizierbares Element der Form eines Produktes.
Definition der IAI: Der IfcShapeAspect gestattet es, geometrische Repräsentationselemente zu gruppieren, die Aspekte oder Komponenten der Form eines Produktes
darstellen. Somit stellen geometrische Repräsentationen einen bestimmten Teil des
Produkts dar, der explizit angesprochen werden kann.
Anmerkung: Die Definition dieser Klasse bezieht sich auf die STEP-Klasse
shape_aspect. Siehe ISO/IS 10303-41:1994 für die abschließende Definition
des formalen Standards.
HISTORIE: Neue Klasse in IFC 2.0. Attribut PartOfProductDefinitionShape geändert in ein OPTIONALes Attribut und informelle Vorschrift
hinzugefügt durch ST-5.
IFC2x2-Plattform-Änderung: Attribut PartOfProductDefinitionShape als
OPTIONAL deklariert unter Wahrung der Aufwärtskompatibilität von
Austausch-Dateien.
Informelle Vorschriften:
1. Falls ShapeRepresentations auf geometrische Repräsentationen zeigt, die zu
einer IfcProductDefinitionShape gehören, muss PartOfProductDefinitionShape auf diese Instanz von IfcProductDefinitionShape verweisen.
Anmerkung: PartOfProductDefinitionShape wird nur dann nicht gesetzt, wenn
die geometrischen Repräsentationen an eine IfcRepresenationMap angehängt
sind.
21
defined in IfcRepresentationResource schema; part of IFC 2x2 Platform.
Though while IfcShapeAspect itself is not a property set, it is included in this section since it is used by
the following property set definitions.
33
ENTITY IfcShapeAspect
ShapeRepresentations : LIST [1:?] OF IfcShapeRepresentation;
Name
: OPTIONAL IfcLabel;
Description
: OPTIONAL IfcText;
ProductDefinitional
: LOGICAL;
PartOfProductDefinitionShape : OPTIONAL
IfcProductDefinitionShape;
END_ENTITY;
Siehe [2] für Attribut-Definitionen und Vererbungsgraph.
Diskussion
Die oben vorgeschlagene Änderung ermöglicht es, IfcShapeAspect im Zusammenhang mit „representation maps“ zu verwenden. Dadurch gelingt es, auch Formen
anzusprechen, die zu einem Typ-Objekt wie IfcMemberType gehören.
6.2.2 IfcShapeAspectProperties22
Definition der IAI: Form-Aspekt-Eigenschaften (shape aspect properties) beinhalten
geometrische und nicht-geometrische Parameter von Form-Features und Bearbeitungs-Features. Zu Objekten, die durch solche Property Sets näher beschrieben
werden, gehören in erster Linie Unterklassen von IfcElementType oder (über IfcRelDefinesByProperties) Unterklassen von IfcElement.
HISTORIE: Neue Klasse, vorgeschlagen von ST-5.
ENTITY IfcShapeAspectProperties
ABSTRACT SUPERTYPE OF (ONEOF(
IfcShapeAspectBendingProperties,
IfcShapeAspectCutoutProperties,
IfcShapeAspectHoleProperties,
IfcShapeAspectSignatureProperties,
IfcShapeAspectSurfaceProperties))
SUBTYPE OF (IfcPropertySetDefinition);
FeatureType
Shape
: OPTIONAL IfcShapeAspect;
ExtendedProperties : OPTIONAL SET [1:?] OF IfcProperty;
END_ENTITY;
Attribut-Definitionen:
FeatureType:
die Art von Feature, die sich im Form-Aspekt manifestiert.
Standardwerte werden in Anwendungs-Definitionen der Unterklassen von IfcShapeAspectProperties vorgegeben.
Shape:
eine oder mehrere Repräsentationen der Form des Features,
angesprochen als Form-Aspekt. Die Repräsentation des Features ist Teil der Repräsentation des gesamten Produktes.
Anmerkung: IfcShapeAspectProperties.Shape.ShapeRepresentations zeige auf
IfcShapeRepresentation-Instanzen, die in „representation maps“ von
22
IfcShapeAspectProperties und seine Unterklassen werden für das IfcTimberConstructionDomainSchema oder IfcStructuralElementsDomain-Schema vorgeschlagen (außerhalb der IFC-2x2-Plattform).
34
IfcShapeAspectProperties.DefinesType.RepresentationMaps enthalten sind, oder die zu einer
IfcShapeAspectProperties.PropertyDefinitionOf.RelatedObjects.Representation gehören.
ExtendedProperties: typabhängige und anwendungsspezifische Eigenschaften des
Features, z.B. Formparameter oder Fertigungsinformation
6.2.3 IfcShapeAspectBendingProperties
Definition der IAI: Beinhaltet Eigenschaften von Krümmungen oder Kanten gebogener Elemente wie z.B. Blech, Stahlprofilen oder Sperrholz.
Geometrische Anwendungs-Definition
Durch direkte Attribute und unten beschriebene geometrische Repräsentationen
werden lediglich Biegungen mit konstantem Radius unterstützt. Biegungen mit veränderlichem Radius können durch komplexere geometrische Repräsentationen und/
oder anwendungsspezifische Parameter dargestellt werden, welche über das geerbte
Attribut ExtendedProperties angefügt werden können.
Der Name der vom geerbten Attribut Shape angesprochenen IfcShapeRepresentation(en) sei ‘Bending’. Die Repräsentation enthalte ein Objekt, das Unterklasse von
IfcCurve ist, und ein Objekt, das Unterklasse von IfcPoint ist.
Üblicherweise wird eine IfcPolyLine mit lediglich einem Liniensegment als „Kurve“
verwendet. Die Linie ist die Mittellinie der Krümmung. Ihr Anfangs- und Endpunkt
markieren bei Projektion auf das Werkstück Anfang und Ende des gekrümmten
Bereichs bzw. der Abkantung. Der Richtungssinn der Mittellinie ist bedeutsam für
den Richtungssinn des Biegewinkels. Die Biegung erfolgt in mathematisch positivem
Sinn um die Mittellinie, wenn des Angle-Attribut positiv ist. Derjenige Teil des
Werkstücks, der gebogen wird, wird vom IfcPoint angezeigt.
Falls das zu biegende Werkstück weitere Bearbeitungen besitzt, ist die Reihenfolge
der Bearbeitungen von Bedeutung. Die Abfolge der Arbeitsschritte kann durch die
Reihenfolge von Repräsentationen in der Liste IfcProductRepresentation.Representations bzw. durch die Reihenfolge der „representation maps“ in der Liste IfcTypeProduct.RepresentationMaps oder auch durch anwendungsspezifische erweiterte
Properties angegeben werden.
Abb. 6-4
Repräsentation eines Bauteils mit Abkantungen
st
1 ‘Bending’ –90°
2nd ‘Bending’ +90°
rd
z
y
z
y
x
‘Blank’
‘Body’
x
ENTITY IfcShapeAspectBendingProperties
SUBTYPE OF (IfcShapeAspectProperties);
Angle : OPTIONAL IfcPlaneAngleMeasure;
Radius : OPTIONAL IfcPositiveLengthMeasure;
END_ENTITY;
35
Angle:
vorzeichenbehaftetes Winkelmaß, um das das Werkstück gebogen wird
Radius:
Radius der inneren gekrümmten Oberfläche des Werkstücks [ = Radius der
Biegerolle]; 0 bei scharfer Abkantung
6.2.4 IfcShapeAspectCutoutProperties
Definition der IAI: Beinhaltet Eigenschaften für zerspanend hergestellte Vertiefungen, Löcher oder Schnitte. Das geerbte Attribut FeatureType bezeichnet die Art des
Ausschnitts durch folgende Standardwerte:
• ‘Cut’: eine einzelne Schnittebene oder mehrere unmittelbar zusammengehörige Schnitte am Stirnende eines Bauteils
• ‘Internal’: eine Bearbeitung, die einen Durchbruch erzeugt; ein Loch mit
komplexerer Form, als es mit IfcShapeAspectHoleProperties beschrieben
werden könnte
• ‘External’: eine äußerliche Bearbeitung, ein Rücksprung, eine Vertiefung
• ‘WeldPreparation’: Vorbereitung für eine Schweißnaht
Das geerbte Attribut Shape kann auf einen Form-Aspekt mit ein oder mehreren
IfcRepresentation(en) weisen, deren RepresentationIdentifier auf ‘Cutout’ gesetzt ist
und die die explizite Geometrie des Features beinhalten. Anwendungsspezifische
Formparameter und nicht-geometrische Parameter können über das geerbte Attribut
ExtendedProperties angefügt werden.
Die Produkt-Repräsentation eines Bauteils mit ein oder mehreren „Cutouts“ unter
anderem folgende Repräsentationen enthalten:
rep. identifier
‘Blank’
‘Cutout’
‘Body’
representation type
‘SweptSolid’
‘HalfSpace’ ‘SweptSolid’
‘Clipping’ ‘CSG’
Inhalt
Körper ohne Features
‘SurfaceModel’ cutout-Features
‘Brep’
Körper mit allen
Features
CSG: Das Volumen des Features wird vom Volumen des Rohbauteils abgezogen; d.h.
das IfcSweptAreaSolid des Features ist ein Fehlvolumen, kein Festkörper. Die
Instanzen der Repräsentationsobjekte im ‘Blank’ und ‘Cutout’ können zugleich auch
als Operanden für das Boolsche Konstrukt im ‘Body’ benutzt werden. Implementations-Vereinbarungen können weitere Einschränkungen der Geometrie vorschreiben.
36
Abb. 6-5
Repräsentation eines Bauteils mit Cutout mittels CSG
‘Blank’
‘Cutout’
y
x
y
–
z
x
extruded
area solid
Abb. 6-6
y
z
= x
z
extruded
area solid
constructive solid
geometry (CSG)
Repräsentation eines Bauteils mit Cutout mittels B-Rep
‘Blank’
‘Cutout’
y
x
‘Body’
‘Body’
y
x
z
extruded
area solid
y
z
surface model
(open B-Rep)
x
z
boundary representation (B-Rep)
B-Rep: Der Richtungssinn der Flächennormalen des Oberflächenmodells des Features
muss mit dem Sinn der Hüllennormalen der B-Rep des Körpers übereinstimmen. D.h.
die Flächennormalen zeigen von innen nach außen. Die IfcFace-Instanzen im
‘Cutout’ können zugleich auch in der B-Rep des ‘Body’ benutzt werden.
Anwendungs-Definition für Features von Stahlbauteilen23
U.a. folgende Standard-Untertypen existieren, angezeigt vom geerbten Attribut
Name:
• Name=‘Miter’ und FeatureType=‘Cut’: Ein oder zwei mit Gehrungen
versehene Enden eines stabförmigen Bauteils. Shape weist auf eine
IfcRepresentation deren RepresentationType auf ‘HalfSpace’ gesetzt ist und
die ein oder zwei IfcHalfSpaceSolid enthält.
• Name=‘Coping’ und FeatureType=‘External’: Eine Ausklinkung, also ein
Rücksprung an einem der Stirnenden des Bauteils.
Anwendungs-Definition für Features von Holzbauteilen
Bei Features mit FeatureType=‘Cut’ sollen folgende Standardwerte für das geerbte
Attribut Name verwendet werden:
• ‘DividingCut’: Trennschnitt; ein einzelner Schnitt, der einen Rohling in
zwei Stücke zerlegt
• ‘Miter’: Gehrung; ein oder zwei Schnitte, die schräge Stirnflächen erzeugen
23
Hier wird lediglich aufgezeigt, wie ein paralleles Feature-Konzept für den Stahlbau angelegt werden
könnte. Das tatsächliche künftige Feature-Konzept des Stahlbaus wird derzeit im IAI-Projekt ST4-2
„Stahlbau-Detaillierung“ erarbeitet.
37
• ‘EndCut’: ein oder mehrere Schnitte an Ende des Bauteils
• ‘EdgeCut’: ein oder mehrere Schnitte längs des Bauteils
• ‘Shoulder’: zwei oder mehr Schnitte am Ende des Bauteils, die zur
Vorbereitung einer Versatz-Verbindung dienen
Bei Features mit FeatureType=‘External’ sollen folgende Standardwerte als Name
verwendet werden:
• ‘BirdsMouth’: Kerve; zwei aufeinander senkrecht stehende Schnittflächen,
z.B. für das Auflager eines Sparrens auf einer Pfette
• ‘Lap’: Blatt; zwei Schnittflächen nahe dem Stirnende des Bauteils, z.B. zur
Herstellung einer Überblattung
• ‘Rabbet’: Falz; eine Vertiefung an einer Längskante, bestehend aus zwei
Schnittflächen (oder drei bei einseitig bzw. vier bei beidseitig begrenztem
Falz)
• ‘Notch’: Ausklinkung; eine Vertiefung mit einer Fläche im Grund (parallel
zu einer ursprünglichen Fläche des Rohlings) und zwei seitlichen Schnittflächen, z.B. zur Herstellung einer T-förmigen Überblattung
• ‘Groove’: Nut
• ‘Mortise’: Zapfenloch
• ‘Tenon’: Zapfen; ein Vorsprung mit zwei Wangen
• ‘StubTenon’: abgesetzter Zapfen; ein Vorsprung mit vier Wangen
• ‘Scarf’: Blatt für Längsstöße, insbesondere von Gelenkpfetten
• ‘Seating’: Versatzkerve
Ein Zapfenloch (‘Mortise’) kann auch vom FeatureType=‘Internal’ sein, wenn es das
gesamte Bauteil durchdringt.
ENTITY IfcShapeAspectCutoutProperties
EdgeRadius
: OPTIONAL IfcLengthMeasure;
MiterAngles
: OPTIONAL LIST [1:?] OF IfcPlaneAngleMeasure;
END_ENTITY;
EdgeRadius: Radius der Kanten zwischen Schnittflächen (d.h. nicht der Kanten
zwischen Feature und Originalflächen des Rohlings). Bei einem Wert
0 handelt es sich um scharfe Kanten. Bei einem Wert >0 sind die
Kanten mit einem Radius ≤ dem Wert zu fertigen. Bei einem Wert <0
werden die Kanten hinterschnitten; der Radius des Werkzeugs sei ≤
dem Absolutbetrag des Wertes.
MiterAngles: Falls es sich beim Feature um Gehrungen handelt, sollten in dieser
Liste die Gehrungswinkel angegeben werden. Reihenfolge und Vorzeichenregelung sind durch Implementoren zu vereinbaren. Der Hauptzweck dieses Attributs ist die einfache Übermittlung von Gehrungswinkeln an Stücklisten.
38
6.2.5 IfcShapeAspectHoleProperties
Definition der IAI: Beinhaltet Eigenschaften zylindrischer Löcher und Langlöcher.
Das geerbte Attribut FeatureType bezeichnet die Art der Löcher mittels folgender
Standardwerte:
• ‘Hole’: Loch; es führen gebohrte, gefräste oder gestanzte Löcher durch das
gesamte Bauteil hindurch.
• ‘BlindHole’: Sackloch; die Löcher sind mit begrenzter Tiefe gebohrt oder
gefräst.
• ‘Center’: Zentrierbohrung oder Körnung
• ‘Countersink’: Senkung
• ‘Thread’: Rechtsgewinde. Das Gewindeprofil kann durch Assoziation einer
Produktnorm angegeben werden.
• ‘LeftHandThread’: Linksgewinde
• ‘RingKeyway’: Ringkeilnut für Einlassdübel
Das geerbte Attribut Shape weise auf eine IfcRepresentation, deren RepresentationIdentifier auf ‘Hole’ gesetzt ist und die Anordnung der Löcher enthält. Anwendungsspezifische Formparameter und nicht-geometrische Parameter können über das
geerbte Attribut ExtendedProperties angefügt werden.
Standard-Repräsentation
Die vom Form-Aspekt referenzierte Repräsentation enthält eine IfcDirection-Instanz,
die parallel zu den Bohrachsen ausgerichtet ist. (Alle in einer IfcShapeAspectHoleProperties-Instanz enthaltenen Löcher liegen parallel zueinander.) Sie enthält des
Weiteren eine oder mehrere Instanzen von Unterklassen von IfcPoint, die die
Eintrittspunkte der Löcher angeben.
Repräsentation von Langlöchern
Die Repräsentation enthält eine IfcDirection als Ausrichtung der Bohrachsen. Sie
enthält außerdem eine oder mehrere Instanzen von Unterklassen von IfcCurve, die die
Pfade der Langlöcher angeben (d.h. die Mittellinien).
Abb. 6-7
Zylindrische Löcher und Langloch
entry points
direction
center line
direction
ENTITY IfcShapeAspectHoleProperties
Diameter : OPTIONAL IfcPositiveLengthMeasure;
Depth
: OPTIONAL IfcPositiveLengthMeasure;
Angle
: OPTIONAL IfcPositivePlaneAngleMeasure;
END_ENTITY;
39
Diameter: Nenndurchmesser
Depth:
Nennwert der Tiefe eines Sacklochs, einer Senkung oder eines Gewindes
Angle:
Senkwinkel oder Gewindeauslauf
6.2.6 IfcShapeAspectSignatureProperties
Definition der IAI: Beinhaltet Eigenschaften von Markierungen oder Signierungen.
Das geerbte Attribut FeatureType bezeichnet die Art der Signatur mittels folgender
Standardwerte:
• ‘Mark’: Markierung, eine graphische Signierung
• ‘Tag’: Etikett, Beschriftung
Das geerbte Attribut Shape weise auf eine IfcRepresentation, deren RepresentationIdentifier auf ‘Signature’ gesetzt ist und die Anordnung sowie, falls zutreffend, die
Geometrie der Signatur(en) enthält. Anwendungsspezifische Formparameter und
nicht-geometrische Parameter können über das geerbte Attribut ExtendedProperties
angefügt werden.
Repräsentation von Markierungen
Die vom Form-Aspekt referenzierte Repräsentation enthält eine oder mehrere
Instanzen von Unterklassen von IfcCurve.
Abb. 6-8
Eine Bauteilbeschriftung (Signatur)
placement
y
3x4
2
1
P
tag
z
Repräsentation von Beschriftungen
Die Repräsentation enthält ein oder mehrere IfcAxis2Placement3D, die die linken
unteren Ecken der Texte anzeigen. Der Text befindet sich in der lokalen xy-Ebene
dieser Platzierung. Der Inhalt des Textes wird entweder vom geerbten Attribut Name
angegeben oder, falls Name nicht besetzt ist, vom Attribut Tag des Bauteilobjektes,
an das die Signatur angefügt ist.
ENTITY IfcShapeAspectSignatureProperties
Height : OPTIONAL IfcPositiveLengthMeasure;
Width : OPTIONAL IfcPositiveLengthMeasure;
END_ENTITY;
40
Height:
im Falle einer Beschriftung (‘Tag’), Texthöhe
Width:
im Falle einer Beschriftung (‘Tag’), Textbreite
6.2.7 IfcShapeAspectSurfaceProperties
Definition der IAI: Beinhaltet Eigenschaften chemisch oder mechanisch behandelter
Oberflächen oder anderweitig besonderer Oberflächen.
Die in einer Behandlung oder Beschichtung verwendete Substanz kann durch
IfcMaterialSelect angegeben werden, welches mit dem behandelten Bauteil(typ) zu
assoziieren ist. In diesem Falle sind die geerbten Name-Attribute von IfcShapeAspectSurfaceProperties und der entsprechenden Instanz von IfcRelAssociatesMaterial
gleichlautend zu belegen.
Es gibt drei grundsätzliche Möglichkeiten, die Größe der zu behandelnden Oberfläche
anzugeben:
• Sämtliche Bauteiloberflächen werden behandelt. Das Attribut EntireBody ist
auf wahr gesetzt. Das geerbte Attribut Shape kann zusätzlich auf eine oder
mehrere Repräsentation mit Bezeichner ‘Body’ verweisen.
• Es sollen nur Teilflächen behandelt werden. Das Attribut EntireBody ist auf
falsch gesetzt. Es wird eine mengenmäßige Flächenangabe im Attribut Area
übermittelt, aber nicht die genaue Lage der Flächen.
• Es sollen nur Teilflächen behandelt werden. Das Attribut EntireBody ist auf
falsch gesetzt. Die Geometrie wird explizit übermittelt: Das geerbte Attribut
Shape verweist auf einen Form-Aspekt mit einer oder mehreren Repräsentationen, deren RepresentationIdentifier auf ‘Surface’ gesetzt ist und die Lage
und Form des Oberflächenfeatures enthalten.
Die referenzierten Repräsentationen sind üblicherweise vom Typ ‘SurfaceModel’,
außer bei ‘Body’-Repräsentationen.
Anwendungsspezifische Formparameter und nicht-geometrische Parameter können
über das geerbte Attribut ExtendedProperties angefügt werden.
Anwendungs-Definition für Features von Stahlbauteilen24
Folgende Standard-Untertypen existieren, bezeichnet durch das geerbte Attribut
FeatureType: ‘Painting’, ‘Spraying’, ‘Powder’, ‘GritBlasting’, ‘FlameDescaling’,
‘Etching’, ‘Galvanizing’, ‘MechanicalTreatment’.
24
Hier wird lediglich aufgezeigt, wie ein paralleles Feature-Konzept für den Stahlbau angelegt werden
könnte. Das tatsächliche künftige Feature-Konzept des Stahlbaus wird derzeit im IAI-Projekt ST4-2
„Stahlbau-Detaillierung“ erarbeitet.
Alternative oder zusätzliche Standardbezeichner können von CIS/2 LPM abgeleitet werden, z.B.
‘ChemicalWash’, ‘BlastClean’, ‘SprayedCoat’, ‘BrushedCoat’, ‘DippedCoat’, ‘ElectroplatedCoat’,
‘Grind’, ‘Thermal’.
41
Anwendungs-Definition für Features von Holzbauteilen
Folgende Standard-Untertypen existieren, bezeichnet durch das geerbte Attribut
FeatureType:
• ‘Painting’ (Anstrich), ‘Spraying’ (gespritzte Beschichtung), ‘Dipping’
(Behandlung durch Tauchen), ‘Tank’ (Trogtränken), ‘Pressure’ (Kesseldrucktränken), ‘AlternatingPressure’ (Wechseldruckverfahren), ‘Vacuum’
(Vakuumtränken), ‘Bandage’ (Bandagen), ‘Injection’ (Injektionsverfahren);
• ‘Visible’ (Sichtfläche), ‘Decor’ (Dekorfläche);
• ‘Planing’ (Hobeln), ‘RoughPlaning’ (Schroppen);
• ‘Lock’ (Sperrflächen, z.B. innerhalb derer Nagelreihen zu unterbrechen
sind).
ENTITY IfcShapeAspectSurfaceProperties
Purpose
: OPTIONAL SET [1:?] OF IfcLabel;
EntireBody : OPTIONAL IfcBoolean;
Area
: OPTIONAL IfcAreaMeasure;
Depth
END_ENTITY;
Purpose:
Funktion(en) der Behandlung, z.B. ‘Preparation’, ‘Primer’, ‘Finish’25,
‘CorrosionProtection’, ‘FireProtection’, ‘Aesthetic’26
EntireBody: wahr, falls die gesamte Bauteiloberfläche behandelt werden soll
Area:
Mengenangabe der zu behandelnden Flächen
Depth:
Dicke der Beschichtung, Eindringtiefe der Imprägnierung, bzw. Dicke
des abgetragenen Materials
6.3 Bearbeitungen: Erweiterte Properties
6.3.1 Unterklassen von IfcShapeAspectProperties
Folgende erweiterte Properties können über das Attribut ExtendedProperties bei
Instanzen von Unterklassen von IfcShapeAspectProperties angefügt werden:
Name
OrderOf\
Creation
Property-Typ
IfcProperty\
SingleValue
Datentyp
IfcLabel
25
Bezeichner basieren auf PSS
26
Bezeichner basieren auf CIS/2 LPM
Definition
Hinweis auf die Reihenfolge der Herstellung der Features, kann eine Ordinalzahl
oder ein Schlüsselwort sein. Zulässige
Werte sind in Implementierungsvereinbarungen festzulegen.
42
Place
IfcProperty\
SingleValue
IfcLabel
Machine
IfcProperty\
SingleValue
IfcLabel
Tool
IfcProperty\
SingleValue
IfcLabel
ToolMaterial IfcProperty\
SingleValue
ToolSpeed
IfcProperty\
SingleValue
IfcLabel
Tolerance27
Quality
bezeichnet den Ort der Herstellung des
Features: ‘supplier’ (beim Lieferant),
‘shop’ (im Werk) oder ‘site’ (auf der
Baustelle)
weist die zur Herstellung eines Features
nötigen Bearbeitungsprozesse einer
bestimmten Maschine zu
weist die zur Herstellung eines Features
nötigen Bearbeitungsprozesse einem
bestimmten Werkzeug zu
zu verwendende Werkzeugart
IfcLinear\
VelocityMe
asure
IfcProperty\
IfcLength\
BoundedValue Measure
IfcProperty\
SingleValue
IfcLabel
Vorschubrate des Werkzeugs oder
Werkstücks
Fertigungstoleranz; Differenzen
zwischen Nenn- und unterem bzw.
oberem Grenzmaß
Qualitätsanforderung an die Fertigung,
z.B. ‘visible’ für sichtbar bleibende
Bearbeitungen
Name
Method
Property-Typ
IfcProperty\
SingleValue
Datentyp
IfcLabel
Definition
Fertigungsverfahren, z.B. ‘cold’ (Kaltbiegen,
Abkanten), ‘hot’ (Warmbiegen)
Name
CutWidth
Property-Typ
IfcProperty\
SingleValue
Tool\
IfcProperty\
Alignment SingleValue
Datentyp
IfcLength\
Measure
IfcLabel
Face\
IfcProperty\
28
Integrity
SingleValue
IfcLabel
27
Definition
Breite des Sägeschnitts
Führung des Werkzeugs relativ zur
Schnittebene: ‘before’ = davor, ‘behind’ =
dahinter (das Werkstück wird um CutWidth
geschwächt), ‘centered’ = zentriert zur
Schnittebene (das Werkstück wird um ½
CutWidth geschwächt)
‘whole’ = die Flächen bleiben komplett
intakt; ‘inner’ = das Werkzeug kann an den
Rändern der Flächen einschneiden; ‘none’
= das Werkzeug kann an beliebiger Stelle
Teile der Schnittflächen verletzen
Toleranzen können in der Praxis auch auf das Bauteil oder auf einzelne Abmessungen bezogen sein.
Toleranzen und Zwangsmaße werden im derzeitigen IFC-Modell jedoch nicht unterstützt. Um tiefgreifende Änderungen des IFC-Modells und damit verbundene langwierige Test- und Integrationsphasen
zu vermeiden, wird vorerst die Zuordnung zu Feature-Objekten vorgeschlagen.
Method
IfcProperty\
SingleValue
43
IfcLabel
Verfahren zur Herstellung der Schnitte:
‘sawn’ (Sägen), ‘flame cut’ (Brennschneiden), ‘sheared’ (Abscheren), ‘punched’
(Stanzen), ‘drilled’ (Bohren), ‘milled’
(Fräsen), ‘laser’ (Laserschneiden),
‘abrasion’ (Trennschleifen)
Name
Entry
Exit
Fit
Method
Property-Typ
IfcProperty\
SingleValue
IfcProperty\
SingleValue
IfcProperty\
SingleValue
IfcProperty\
SingleValue
Number\ IfcProperty\
OfThreads SingleValue
Datentyp
IfcLabel
Definition
‘splinterfree’ = ausrissfreiher Eintritt
‘splinterfree’ = ausrissfreier Austritt, oder
‘manually’ = nicht maschinell durchbohren
sondern von Hand fertig stellen
IfcBoolean gibt an, ob es sich um eine Passbohrung
handelt (für Passbolzen oder Stabdübel)
Verfahren zur Herstellung der Löcher:
IfcLabel
‘drilled’ (Bohren), ‘milled’ (Fräsen),
‘punched’ (Stanzen), ‘laser’ (Laserbohren)
IfcInteger Anzahl der Gewindegänge
IfcLabel
Name
Color
Property-Typ
IfcProperty\
SingleValue
Datentyp
IfcLabel
Definition
Farbe einer gedruckten oder gestempelten
Signatur
Name
Irregula\
rity
Property-Typ
IfcProperty\
SingleValue
Duration
Time\
Spec
IfcProperty\
SingleValue
IfcProperty\
ListValue
Tempera\
tureSpec
IfcProperty\
ListValue
28
Datentyp
IfcPositive\
Length\
Measure
IfcTime\
Measure
IfcTime\
Measure
Definition
Unregelmäßigkeit (Rauhigkeit) der Oberfläche nach mechanischer Behandlung
Gesamtdauer des Behandlungsprozesses
bei thermischer Behandlung [im Stahlbau]:
Zeit von der Anfangs zur Maximaltemperatur, Dauer der Maximaltemperatur, Zeit von
Maximal- zu Endtemperatur
IfcThermo\ bei thermischer Behandlung [im Stahlbau]:
Anfangs-, Maximal- und Endtemperatur
dynamic\
Temperatu\
reMeasure
Diese Eigenschaft gilt für all Flächen eines Features. Feinere Vorgaben hinsichtlich der Führung des
Werkzeuges sind möglich, indem das Feature in mehrere IfcFeatureCutoutProperties aufgeteilt wird.
44
6.4 Anschlüsse: Occurrence Objects29
6.4.1 IfcFastener
Definition der IAI: Repräsentationen von Teilen, die zur Befestigung oder Verbindung von Elementen verwendet werden.
HISTORIE: Neue Klasse in IFC 2x2
Geänderte Anwendungs-Definition vorgeschlagen von ST-5
Generelle Verwendung
Die genaue Typ-Information zum IfcFastener wird mittels des geerbten Attributs
ObjectType oder durch ein angefügtes IfcFastenerType bzw. dessen Unterklassen
angegeben. Mechanische Verbindungsmittel werden durch die Unterklasse IfcMechanicalFastener repräsentiert.30
[Tabelle der Standardtyp-Bezeichner in IFC 2x2 löschen] 31
Geometrische Anwendungs-Definition:
Siehe [2] für relative lokale Koordinaten und Standard-Repräsentationsarten.
Geometrische Repräsentation von Gruppen von Verbindungsmitteln
Eine einzelne Instanz von IfcFastener kann eine ganze Gruppe mehrerer Verbindungsmittel repräsentieren, beispielsweise Bolzengruppen oder Nagelreihen. Das
Layout solcher Gruppen und die darin enthaltene Anzahl von Einzelteilen kann parametrisch mittels angefügter Property Sets modelliert werden, welche allerdings
separat durch Implementoren zu vereinbaren sind.
Bei Gruppen zylinderförmiger mechanischer Verbindungsmittel wird IfcRepresentation.RepresentationIdentifier auf ‘Group’ gesetzt. Die Repräsentation enthält ein oder
mehrere Untertypen von IfcPoint oder IfcCurve. Diese symbolisieren die Mittelpunkte der Köpfe der Verbindungsmittel. Die Verbindungsmittel sind an der lokalen
z-Achse der Repräsentation ausgerichtet.
Falls IfcCurve benutzt wird [i.d.R. als gerade Linien], sind Anzahl und/ oder Abstände der Verbindungsmittel mittels Property Set anzugeben. Mehrere Linien können
eine Matrix formen. Falls Punkt-Repräsentationen verwendet werden, ergeben sich
Anzahl und Abstände aus der Repräsentation ohne weitere Parameter-Properties.
Anmerkung: Abhängig von Implementations-Vereinbarungen können Gruppen
von Verbindungsmitteln auch mittels mehrerer Instanzen von IfcFastener und
je einer Instanz von IfcGroup und IfcRelAssignsToGroup modelliert werden.
Die IfcGroup kann zusätzlich mit Property Sets versehen werden.
Siehe [2] für EXPRESS-Spezifikation und Vererbungsgraph.
29
IfcFastener, IfcMechanicalFastener, IfcDiscreteAccessory sind im IfcSharedComponentElementsSchema definiert (außerhalb der IFC-2x2-Plattform).
30
IfcMechanicalFastener sollte gelöscht werden.
31
Typzuweisungen sollen bevorzugt mittels IfcFastenerType bzw. dessen Unterklassen erfolgen.
45
Diskussion
Die Darstellung von Gruppen von Verbindungsmitteln mittels IfcGroup ist ungeeignet im modernen Holzbau, namentlich für Nagel- und Klammer-Reihen. Diese
Methode wird deshalb von Holzbau-Anwendungen nicht benutzt werden.
Eine dritte denkbare Methode könnte statt mit IfcFastener mit einer neuen Unterklasse von IfcFastener arbeiten, z.B. IfcFastenerArray, die im IfcStructuralElementsDomain- oder IfcSharedComponentElements-Schema zu definieren wäre. Diese
Klasse könnte zusätzliche optionale Attribute erhalten, mit denen Anzahl und
Abstände von gruppierten Verbindungsmitteln angegeben werden.
DtH, PSS und offenbar auch CIMsteel LPM/5 repräsentieren Gruppen mechanischer
Verbindungsmittel stets als Liste von Layout-Punkten, wobei ein und dieselbe Klasse
für einzelne und für gruppierte Verbindungsmittel benutzt wird. Einzelne Verbindungsmittel stellen sozusagen nur einen Grenzfall einer Gruppe dar. In den genannten
Datenmodellen werden keine parametrische Informationen bezüglich der Gruppierung übermittelt.
Man bedenke, dass tragende mechanische Verbindungen im Stahlbau stets aus mehr
als einem Verbindungsmittel bestehen. Dies ist meistens (aber nicht immer) auch im
Holzbau der Fall.
6.4.2 IfcMechanicalFastener (entfällt)
Definition der IAI: Verbindungsmittel, die Bauteile mechanisch verbinden.
Löschung der Klasse vorgeschlagen von ST-5
Diskussion
IfcFastener soll IfcMechanicalFastener statt verwendet werden. Mechanische Verbindungsmittel werden dann durch Kombination von IfcFastener mit IfcMechanicalFastenerType dargestellt.
6.4.3 IfcDiscreteAccessory
Definition der IAI: Repräsentationen unterschiedlicher Arten von Zubehör, das in
Elemente eingebaut oder ihnen zugefügt wird. — Siehe [2] für die vollständige
Definition.
Diskussion
IfcDiscreteAccessory wird im Holzbau besonders für Zwischenbauteile in Anschlüssen verwendet, etwa Balkenschuhe, Rispenbänder oder Lochbleche.
46
6.5 Anschlüsse: Typ-Objekte32
6.5.1 IfcFastenerType
Definition der IAI: Dieser Elementtyp (IfcFastenerType) definiert eine Liste
gemeinsam benutzter Property-Set-Definitionen eines Verbindungsmittels und ein
oder mehrere optionale Produkt-Repräsentationen. Er wird für die Definition von
Verbindungsmitteln insbesondere in Tragwerken und technischer Gebäudeausrüstung
verwendet (d.h. für spezifische Typ-Information, die allen Occurrences = eingefügten
Objekten dieses Typs gemeinsam ist). — Siehe [2] für die vollständige Definition.
6.5.2 IfcMechanicalFastenerType
Definition der IAI: Dieser Elementtyp (IfcMechanicalFastenerType) definiert eine
Liste gemeinsam benutzter Property-Set-Definitionen eines Verbindungsmittels und
ein oder mehrere optionale Produkt-Repräsentationen. Er wird für die Definition
mechanischer Verbindungsmitteln insbesondere in Tragwerken und technischer
Gebäudeausrüstung verwendet (d.h. für spezifische Typ-Information, die allen
Occurrences = eingefügten Objekten dieses Typs gemeinsam ist).
Die Occurrences des IfcMechanicalFastenerType werden durch Instanzen von
IfcMechanicalFastener IfcFastener repräsentiert.
Erweiterte Anwendungs-Definition und zusätzliche Attribute vorgeschlagen
von ST-5
Generelle Verwendung33
Genauere Typinformation des IfcMechanicalFastenerType wird im geerbten Attribut
ElementType angegeben. Standard-Typbezeichner sind hier als Richtlinie angegeben.
Objekttyp
'Bolt'
'Nut'
'Washer'
'Set'
Beschreibung
Bolzen
Mutter
Unterlegscheibe
Garnitur aus einem Bolzen und ein oder mehreren Muttern und
Unterlegscheiben; die genaue Zusammenstellung kann im geerbten
Attribut Name oder mittels angefügten Property Sets angegeben werden.
Holzschraube u.ä. Schrauben
Nagel
Klammer
Stabdübel
Dübel besonderer Bauart (Einlass- oder Einpressdübel)
'Screw'
'Nail'
'Staple'
'Dowel'
'Shear
Connector'
'Nail Plate' Nagelplatte
32
IfcFastenerType, IfcMechanicalFastenerType, IfcDiscreteAccessoryType sind im IfcSharedComponentElements-Schema definiert (außerhalb der IFC-2x2-Plattform).
33
Die genaue Verwendung im Stahlbau wird derzeit im IAI-Projekt ST4-2 „Stahlbau-Detaillierung“
festgelegt.
47
'Rivet'
Niet
Die genauen Eigenschaften eines mechanischen Verbindungsmittels sollten mittels
Assoziation eines Dokumentes festgelegt werden (z.B. einer Produktnorm), oder
durch Assoziation eines Klassifikationssystems oder einer Bauteilbibliothek. Assoziationen werden durch IfcRelAssociates realisiert. Des Weiteren kann eine standardisierte Kurzbezeichnung im geerbten Attribut Name angegeben werden.
ENTITY IfcMechanicalFastenerType
SUBTYPE OF (IfcFastenerType);
NominalDiameter : OPTIONAL IfcPositiveLengthMeasure;
NominalLength
Strength
FinishOrGrade
END_ENTITY;
NominalDiameter: Nenndurchmesser eines zylindrischen Verbindungsmittels
NominalLength:
Nennlänge
Strength:
Festigkeitsklasse des Verbindungsmittels, bei Bolzen die sogenannte „property class“. Beispiele bei metrischen Stahlbolzen
sind ‘4.6’, ‘8.8’, ‘10.9’, bei nichtrostenden Stahlbolzen ‘70’.
FinishOrGrade:
Kurzbezeichnung der Oberflächen- oder Materialgüte des Verbindungsmittels. Beispiele bei Stahlbolzen sind ‘black’
(schwarz), ‘ZP’ (verzinkt), ‘ZY’ (verzinkt und gelb passiviert) .
Ein Beispiel für die Korrosionswiderstandsklasse eines nichtrostenden Stahlbolzens ist ‘A4’.
Diskussion
Die vier neu vorgeschlagenen Attribute wurden so gewählt, dass in Verbindung mit
einer referenzierten Produktnorm die exakte Konfiguration von Bolzen, Muttern, UScheiben und Holzschrauben angegeben werden kann. Dies schließt alle geometrischen Parameter wie Gewindelänge (in der Produktnorm angegeben) oder mechanische Parameter wie Schertragfähigkeit ein (angegeben in Bemessungsnormen, abgeleitet von Größe und Festigkeitsklasse des Verbindungsmittels).
Beispielsweise gibt eine Referenz auf ISO 7412:1984 „Sechskantschrauben mit
großer Schlüsselweite für hochfeste Stahlbauverschraubungen (kurze Gewindelängen); Produktklasse C; Festigkeitsklassen 8.8 und 10.9“ an.
Die Attribute Strength und FinishOrGrade wurden bewusst als Attribute der Verbindungsmittel, nicht als Eigenschaft eines assoziierten Materials definiert. Es können
z.B. unterschiedliche Materialien die gleiche Festigkeitsklasse erzielen. Das genaue
Material kann zusätzlich als IfcMaterial (z.B. amerikanisch ‘5140’, ‘316’ oder europäisch ‘41 Cr 4’, ‘1.4571’) über IfcRelAssociatesMaterial angegeben werden.
Ferner wurden diese Attribute bewusst als IfcLabel definiert. Zwar erscheinen die
Festigkeitsklassen wie Fließkommazahlen, sind aber tatsächlich keine direkten
Rechenwerte für Festigkeiten. Außerdem sollen beliebige Bezeichnungsweisen für
die Tragfähigkeitseinstufung alle Arten von Verbindungsmitteln mit diesem Attribut
wiederzugeben sein.
48
6.5.3 IfcDiscreteAccessoryType
Definition der IAI: Dieser Elementtyp (IfcDiscreteAccessoryType) definiert eine Liste
gemeinsam benutzter Property-Set-Definitionen eines diskreten Zubehörs und ein
oder mehrere optionale Produkt-Repräsentationen. Er wird für die Definition von
Zurüstteilen insbesondere in Tragwerken und technischer Gebäudeausrüstung
verwendet (d.h. für spezifische Typ-Information, die allen Occurrences = eingefügten
Objekten dieses Typs gemeinsam ist). — Siehe [2] für die vollständige Definition.
Diskussion
IfcDiscreteAccessoryType wird im Holzbau besonders für Zwischenbauteile in Anschlüssen verwendet, etwa Balkenschuhe, Rispenbänder oder Lochbleche.
6.6 Anschlüsse: Property Sets34
6.6.1 Pset_ElementComponentCommon
Anwendbarkeit
zutreffende Klassen
zutreffende Typen
Definition
Projekt-Code
generelles Property Set
Unterklassen von IfcElementComponent oder
IfcElementComponentType
Definition der IAI: auf verschiedene Typen von Verbindungsmitteln und Zubehörteilen zutreffende Eigenschaften
ST5
Name
Property-Typ
Mounting\ IfcProperty\
Place
SingleValue
Sunken
34
IfcProperty\
SingleValue
Datentyp
IfcLabel
Definition
bezeichnet, wo das Teil montiert wird:
‘Site’ = auf der Baustelle, ‘Shop’ = im
Werk, ‘Supplier’ = beim Zulieferer
IfcBoolean gibt versenkten Einbau vor
vorgeschlagen für das IfcSharedComponentElements-Schema (außerhalb der IFC-2x2-Plattform)
Das künftige Konzept für Stahlbauverbindungen wird derzeit im IAI-Projekt ST4-2 „StahlbauDetaillierung“ erarbeitet. Entsprechende Änderungen bei den hier aufgeführten Property Sets sind
möglich.
49
6.6.2 Pset_FastenerGlue
Anwendbarkeit
zutreffende Klassen
zutreffende Typen
Definition
Projekt-Code
klassen- und typspezifisches Property Set
IfcFastener, IfcFastenerType
SELF\IfcObject.ObjectType = 'Glue',
SELF\IfcElementType.ElementType = 'Glue'
Definition der IAI: Eigenschaften geklebter und geleimter
Verbindungen
ST5
Name
Property-Typ
Place
SingleValue
Datentyp
IfcLabel
CuringTime IfcProperty\
SingleValue
IfcTime\
Measure
Definition
bezeichnet, wo die Verbindung hergestellt
wird: ‘Site’ = auf der Baustelle, ‘Shop’ =
im Werk, ‘Supplier’ = beim Zulieferer
Presszeit
6.6.3 Pset_FastenerGroup
Anwendbarkeit
zutreffende Klassen
zutreffende Typen
Definition
Projekt-Code
klassenspezifisches Property Set
IfcFastener
Definition der IAI: Parameter für gruppierte Verbindungsmittel, beispielsweise Nagelreihen
ST5
Name
Property-Typ
Spacing
IfcProperty\
SingleValue
Quantity
IfcProperty\
SingleValue
Control\
IfcProperty\
Parameter
SingleValue
Mounting\
IfcProperty\
Place
SingleValue
Sunken
IfcProperty\
SingleValue
Datentyp
IfcPositive\
LengthMeasure
IfcInteger
IfcLabel
IfcLabel
IfcBoolean
Definition
größter Abstand zwischen zwei
benachbarten Verbindungsmitteln
Gesamtzahl an Verbindungsmitteln
im definierten Anschluss
maßgebender Parameter, entweder
‘Spacing’ oder ‘Quantity’
bezeichnet, wo die Gruppe eingebaut wird: ‘Site’ = auf der Baustelle,
‘Shop’ = im Werk, ‘Supplier’ =
beim Zulieferer
gibt versenkten Einbau vor
50
6.6.4 Pset_MechanicalFastenerBolt
Anwendbarkeit
zutreffende Klassen
zutreffende Typen
Definition
Projekt-Code
IfcMechanicalFastenerType
(SELF\IfcElementType.ElementType = 'Bolt') OR
(SELF\IfcElementType.ElementType = 'Nut') OR
(SELF\IfcElementType.ElementType = 'Washer') OR
(SELF\IfcElementType.ElementType = 'Set')
Definition der IAI: Eigenschaften bolzenartiger Verbindungsmittel. Eine komplette Garnitur mit Bolzen, Muttern und UScheiben kann definiert werden.
Üblicherweise ist es nicht erforderlich, diese Eigenschaften
bei Verwendung standardisierter Bolzen zu übermitteln.
ST5
Name
Property-Typ
Thread\
IfcProperty\
Length
SingleValue
HeadForm
IfcProperty\
SingleValue
KeyForm
IfcProperty\
SingleValue
KeySize
IfcProperty\
SingleValue
NutForm
IfcProperty\
SingleValue
WasherForm IfcProperty\
SingleValue
WasherSize IfcProperty\
SingleValue
PartsAtHead IfcProperty\
ListValue
PartsAtMid
IfcProperty\
ListValue
PartsAtEnd
IfcProperty\
ListValue
Fit
IfcProperty\
SingleValue
IfcProperty\
SingleValue
IfcProperty\
SingleValue
IfcProperty\
SingleValue
IfcProperty\
SingleValue
Friction
Preload
Friction\
Coefficient
StressArea
Datentyp
Definition
Gewindelänge
IfcPositive\
LengthMeasure
Kopfform, z.B. ‘Hexagon’,
IfcLabel
‘Countersunk’, ‘Cheese’
Ausführung des Schlüsselschlitzes,
IfcLabel
z.B. ‘Slot’, ‘Allen’
Nenngröße des Schlüssels
IfcLabel
IfcLabel
IfcLabel
Form der Mutter, z.B. ‘Hexagon’,
‘Cap’, ‘Castle’, ‘Wing’
Form der U-Scheibe, e.g.
‘Standard’, ‘Square’
Größe der U-Scheibe
IfcPositive\
LengthMeasure
Teile einer Garnitur auf der Seite
IfcLabel
des Bolzenkopfes; z.B. ‘Head’,
‘Washer’
Teile einer Garnitur, die zwischen
IfcLabel
verbundenen Bauteilen liegen; z.B.
‘Shim’ oder ‘Washer’
Teile einer Garnitur auf der Seite
IfcLabel
der Mutter; z.B. ‘Washer’, ‘Lock
Ring’, ‘Nut’, ‘Splint’
gibt eine Passbolzenverbindung vor
IfcBoolean
IfcBoolean
gibt eine gleitfeste vorgespannte
Verbindung vor
Vorspannkraft
IfcForce\
Measure
Gleitreibungszahl
IfcPositive\
RatioMeasure
IfcAreaMeasure Spannungsquerschnitt
51
6.6.5 Pset_MechanicalFastenerScrew
Anwendbarkeit
zutreffende Klassen
zutreffende Typen
Definition
Projekt-Code
SELF\IfcElementType.ElementType = 'Screw'
Definition der IAI: Eigenschaften von Holzschrauben und
ähnlichen Verbindungsmitteln. Eine komplette Garnitur mit
Schraube und U-Scheibe kann definiert werden.
bei Verwendung standardisierter Schrauben zu übermitteln.
ST5
Name
Property-Typ
Thread\
IfcProperty\
Length
SingleValue
HeadForm IfcProperty\
SingleValue
KeyForm
IfcProperty\
SingleValue
KeySize
IfcProperty\
SingleValue
SingleValue
Datentyp
Definition
Gewindelänge
IfcPositive\
LengthMeasure
Kopfform, z.B. ‘Hexagon’,
IfcLabel
‘Countersunk’, ‘Raised’
Ausführung des Schlüsselschlitzes,
IfcLabel
z.B. ‘Slot’, ‘Allen’, ‘Phillips’
Nenngröße des Schlüssels
IfcLabel
Größe der U-Scheibe, sofern
IfcPositive\
LengthMeasure erforderlich
6.6.6 Pset_MechanicalFastenerNail
Anwendbarkeit
zutreffende Klassen
zutreffende Typen
Definition
Projekt-Code
SELF\IfcElementType.ElementType = 'Nail'
Definition der IAI: Eigenschaften von Nägeln und ähnlichen
Verbindungsmitteln.
bei Verwendung standardisierter Nägel zu übermitteln.
ST5
Name
Property-Typ
Shank
IfcProperty\
SingleValue
Datentyp
IfcLabel
HeadForm
IfcLabel
Definition
Art des Schaftes, z.B. ‘Smooth’ für
glattschaftige Nägel, ‘Ring’ für Rillennägel, ‘Screw’ für Schraubnägel
Kopfform
IfcBoolean
gibt geharzten Schaft vor
IfcBoolean
Coated
Sunken
IfcProperty\
SingleValue
IfcProperty\
SingleValue
IfcProperty\
SingleValue
52
6.6.7 Pset_MechanicalFastenerStaple
Anwendbarkeit
zutreffende Klassen
zutreffende Typen
Definition
Projekt-Code
SELF\IfcElementType.ElementType = 'Staple'
Definition der IAI: Eigenschaften von Klammern und
ähnlichen Verbindungsmitteln.
bei Verwendung standardisierter Klammern zu übermitteln.
ST5
Name
Property-Typ
Width
IfcProperty\
SingleValue
Coated
IfcProperty\
SingleValue
Sunken
IfcProperty\
SingleValue
Datentyp
Definition
Breite des Klammerrückens
IfcPositive\
LengthMeasure
gibt geharzten Schaft vor
IfcBoolean
IfcBoolean
6.6.8 Pset_MechanicalFastenerNailPlate
Anwendbarkeit
zutreffende Klassen
zutreffende Typen
Definition
Projekt-Code
SELF\IfcElementType.ElementType = 'Nail Plate'
Definition der IAI: Eigenschaften von Nagelplatten
ST5
Name
Property-Typ
Gauge
IfcProperty\
SingleValue
Length
IfcProperty\
SingleValue
Width
IfcProperty\
SingleValue
Datentyp
IfcLabel
Definition
Blechdicke
Länge rechteckiger Platten
IfcPositive\
LengthMeasure
Breite rechteckiger Platten
IfcPositive\
LengthMeasure
53
6.7 Anschlüsse: Beziehungs-Objekte
Diskussion
Sämtliche Anschlüsse in Holzkonstruktionen erfordern vermittelnde Elemente
(tragende oder lagesichernde mechanische Verbindungsmittel oder Leim). Solche
vermittelten Verbindungen können mittels der IFC-2x2-Klasse modelliert IfcRelConnectsWithRealizingElements werden, sofern genau zwei Hauptelemente verbunden werden.
Es gibt allerdings Anschlüsse, bei denen mehr als zwei Hauptelemente zugleich verbunden werden. Beispiel 1: Eine Nagelreihe auf einem Wandsegment kann über
mehrere OSB-Platten laufen, wobei diese Nagelreihe auch mehrere Rippen abdecken
kann. Beispiel 2: In einem Fachwerkknoten eines Nagelplattenbinders können zwei
oder gar drei Diagonalen bzw. Pfosten und natürlich der Gurt zusammenlaufen, und
alle diese Stäbe werden von einer Nagelplatte pro Binderseite verbunden.
Es gibt mehrere Möglichkeiten, solche Verbindungen zu modellieren:
• Man verwende so viele Instanzen von IfcRelConnectsWithRealizingElements, wie unmittelbare Lastpfade existieren.
• Man aggregiere Bauteile so, dass zwei Hauptbauteile entstehen. Die zwei
Hauptbauteile werden mit einer Instanz von IfcRelConnectsWithRealizingElements verbunden. Der Charakter der Verbindung wird dann aber nur
unzulänglich wiedergegeben. Beispielsweise sind Lastpfade nicht mehr
ohne weiteres nachvollziehbar.
• Man ordne alle Bauteile und Verbindungsmittel einer Gruppe zu
(IfcRelAssignsToGroup). Die Bedeutung dieser Gruppe muss durch die
Anwendungen etabliert werden, da das Datenmodell zunächst noch keine
Semantik der Gruppe beinhaltet.
• Man verweise von den Bauteilen und Verbindungsmitteln auf Objekte der
statischen Berechnung (Instanzen von Unterklassen von IfcStructuralMember and IfcStructuralConnection). Die Verweise erfolgen durch
IfcRelAssignsToProduct. Die Semantik dieses Konstrukts wäre zumindest
Anwendungen der statischen Berechung zugänglich, sofern diese auch die
Art der zugewiesenen Produkte erkennt.
• Man aggregiere einfach alle Bauteile und Verbindungsmittel zu einer
Baugruppe (IfcRelAggregates, IfcElementAssembly). Eigenschaften der
Verbindung(en), insbesondere welche Bauteile unmittelbar aneinander
angeschlossen und welche Verbindungsmittel in welchen Lastpfaden
verwendet werden, werden von dieser Vorgehensweise jedoch nicht erfasst.
Die letzte Variante wird allerdings den üblichen Ansprüchen bereits genügen.
54
7.1 Materialien35
7.1.1 IfcMechanicalMaterialProperties
Definition der IAI: Dies ist eine Zusammenstellung mechanischer Materialeigenschaften, die normalerweise in statischen Berechnungen verwendet werden. Sie enthält auf verschiedenste Materialarten zutreffende Attribute.
Zusätzliche unmittelbare Unterklasse vorgeschlagen von ST-5.
Siehe [2] für die vollständige Definition.
7.1.2 IfcMechanicalTimberMaterialProperties
Definition der IAI: Dies ist eine Zusammenstellung mechanischer Materialeigenschaften von Vollholz [und vergleichbare Werkstoffe]. Anisotropie wird durch
unterschiedliche Eigenschaften hinsichtlich der Faserrichtung und Belastungsart
berücksichtigt.
Anwendungs-Definition
Spannungen können als charakteristische Werte (für das Bemessungskonzept der
Grenzzustände bzw. das amerikanische Äquivalent LRFD) oder als zulässige Werte
abgelegt werden (im Bemessungskonzept der zulässigen Spannungen). Charakteristische und zulässige Werte dürfen innerhalb einer Instanz von IfcMechanicalTimberMaterialProperties nicht gemischt werden. Das zutreffende Bemessungskonzept kann
mittels IfcExtendedMaterialProperties angegeben werden.
Alle Werte beziehen sich auf standardisierte Umgebungsbedingungen, Lasteinwirkungsdauern und Bezugs-Querschnittsgrößen gemäß Bemessungsnormen.
Anmerkung: Falls Materialeigenschaften für unterschiedliche Bauteilgrößen
[z.B. Balkenhöhen] abgestuft angegeben müssen, so sind separate Instanzen
von sowohl IfcMechanicalTimberMaterialProperties als auch IfcMaterial für
jede Abstufung zu verwenden. Mechanisch abweichende Varianten eines
Materials werden also als verschiedene Materialien modelliert. Dies wird durch
eine Einschränkung in IfcMechanicalMaterialProperties gefordert (eine
„uniqueness rule“).
35
Die folgenden Klassen sind im IfcMaterialPropertyResource-Schema definiert oder werden dafür
vorgeschlagen (außerhalb der IFC-2x2-Plattform).
55
Bezüge zur Orientierung der Faserrichtungen oder Laminierungen werden mittels
geometrischer bzw. topologischer Repräsentationen der Element-Objekte hergestellt.
Der Winkel zwischen Beanspruchung und Faserrichtung wird unten mit α bezeichnet.
Die geerbten Attribute haben folgende Bedeutung:
YoungModulus: Elastizitätsmodul, mittlerer Wert, α=0°
ShearModulus: Schubmodul, mittlerer Wert
Informelle Vorschriften:
1. Jedes besetzte Attribut des Typs IfcModulusOfElasticityMeasure habe einen
Wert größer als Null.
2. Jedes besetzte Attribut des Typs IfcPressureMeasure habe einen Wert größer
als Null.
ENTITY IfcMechanicalTimberMaterialProperties
SUBTYPE OF (IfcMechanicalMaterialProperties);
YoungModulusMin
: OPTIONAL IfcModulusOfElasticityMeasure;
YoungModulusPerp
YoungModulusPerpMin : OPTIONAL IfcModulusOfElasticityMeasure;
ShearModulusMin
BendingStrength
: OPTIONAL IfcPressureMeasure;
TensileStrength
TensileStrengthPerp
CompStrength
CompStrengthPerp
RaisedCompStrengthPerp : OPTIONAL IfcPressureMeasure;
ShearStrength
TorsionalStrength
END_ENTITY;
YoungModulusMin:
YoungModulusPerp:
YoungModulusPerpMin:
ShearModulusMin:
BendingStrength:
TensileStrength:
TensileStrengthPerp:
CompStrength:
CompStrengthPerp:
RaisedCompStrengthPerp:
ShearStrength:
TorsionalStrength:
Elastizitätsmodul, unterer Wert, α=0°
Elastizitätsmodul, mittlerer Wert, α=90°
Elastizitätsmodul, unterer Wert, α=90°
Schubmodul, unterer Wert
Biegetragfähigkeit
Zugtragfähigkeit, α=0°
Drucktragfähigkeit, α=0°
erhöhter Wert der Drucktragfähigkeit, α=90°, der unter
materialund norm-abhängigen Umständen anwendbar
ist (z.B. falls Deformationen in Kauf genommen werden
können)
Schubtragfähigkeit
Torsionsschubtragfähigkeit
56
7.1.3 IfcExtendedMaterialProperties
[siehe auch Abschnitt 4.1.3]
Definition der IAI: Eine Container-Klasse für nutzerdefinierte Materialeigenschaften.
Damit wird ein Mechanismus bereitgestellt, im IFC-Modell nicht vorgesehene Eigenschaften zuzuweisen. — Siehe [2] für die vollständige Definition.
Erweiterte Anwendungs-Definition vorgeschlagen von ST-5.
Anwendungs-Definition für mechanisch Eigenschaften von Holzwerkstoffen
Holzwerkstoffe in balkenartiger Anwendung
Dies ist eine Zusammenstellung mechanischer Eigenschaften, die auf Holzwerkstoffe
für stab- und bogenförmige Produkte zutreffen, besonders BSH und LVL.
Anisotropie wird durch unterschiedliche Eigenschaften hinsichtlich der Faserrichtung
und Belastungsart berücksichtigt.
Alle Werte beziehen sich auf standardisierte Umgebungsbedingungen, Lasteinwirkungsdauern und Bezugs-Querschnittsgrößen gemäß Bemessungsnormen.
Anmerkung: Falls Materialeigenschaften für unterschiedliche Bauteilgrößen
(z.B. Balkenhöhen) abgestuft angegeben müssen, so sind separate Instanzen
von sowohl IfcMechanicalTimberMaterialProperties als auch IfcMaterial für
jede Abstufung zu verwenden. Mechanisch abweichende Varianten eines
Materials werden also als verschiedene Materialien modelliert.
Bezüge zur Orientierung der Faserrichtungen oder Laminierungen werden mittels
geometrischer bzw. topologischer Repräsentationen der Element-Objekte bzw.
-Typen hergestellt, insbesondere IfcMemberType und IfcStructuralMember.
Name
Property-Typ
Applicable\
Structural\
Design\
Method
IfcProperty\
SingleValue
InPlane
IfcComplex\
Property
InPlane\
Negative
IfcComplex\
Property
OutOfPlane
IfcComplex\
Property
Datentyp bzw. An- Definition
wendgsbezeichng.
zutreffendes BemessungskonIfcLabel
zept: ‘ASD’ = zulässige
Spannungen, ‘LSD’ = Methode
der Grenzzustände, ‘LRFD’ =
load and resistance factor design
‘Mechanical’
mechanische Eigenschaften
bezüglich Belastung „in-plane“,
d.h. Biegung um starke Achse;
Zugzone asymmetrischer Querschnittsaufbauten gezogen
‘Mechanical’
d.h. Biegung um starke Achse;
Druckzone asymmetrischer
Querschnittsaufbauten gezogen
‘Mechanical’
bezüglich Belastung „out-ofplane“, d.h. Biegung um
schwache Achse
57
Jedes der mit ‘Mechanical’ bezeichneten komplexen Properties kann aus den
folgenden einfachen Properties zusammengesetzt sein. Properties der Typen IfcModulusOfElasticityMeasure und IfcPressureMeasure müssen Werte größer Null beinhalten. α bezeichnet den Winkel zwischen Beanspruchung und Faser.
Name
Young\
Modulus
Young\
Modulus\
Min
Young\
Modulus\
Perp
Young\
Modulus\
PerpMin
Shear\
Modulus
Shear\
Modulus\
Min
Bending\
Strength
Tensile\
Strength
Tensile\
StrengthPerp
Comp\
Strength
Comp\
StrengthPerp
RaisedComp\
StrengthPerp
Property-Typ
IfcProperty\
SingleValue
IfcProperty\
SingleValue
Datentyp
IfcModulusOf\
ElasticityMeasure
IfcModulusOf\
ElasticityMeasure
Definition
Elastizitätsmodul, mittlerer Wert,
α=0°
Elastizitätsmodul, unterer Wert,
α=0°
IfcProperty\
SingleValue
Elastizitätsmodul, mittlerer Wert,
IfcModulusOf\
ElasticityMeasure α=90°
IfcProperty\
SingleValue
Elastizitätsmodul, unterer Wert,
IfcModulusOf\
IfcProperty\
SingleValue
IfcProperty\
SingleValue
Schubmodul, mittlerer Wert
IfcModulusOf\
ElasticityMeasure
Schubmodul, unterer Wert
IfcModulusOf\
ElasticityMeasure
IfcProperty\
SingleValue
IfcProperty\
SingleValue
IfcProperty\
SingleValue
IfcProperty\
SingleValue
IfcProperty\
SingleValue
IfcProperty\
SingleValue
IfcPressure\
Measure
IfcPressure\
Measure
IfcPressure\
Measure
IfcPressure\
Measure
IfcPressure\
Measure
IfcPressure\
Measure
Shear\
Strength
Torsional\
Strength
Reference\
Depth
IfcProperty\
SingleValue
IfcProperty\
SingleValue
IfcProperty\
SingleValue
IfcPressure\
Measure
IfcPressure\
Measure
IfcPositive\
LengthMeasure
Biegetragfähigkeit
erhöhter Wert der Drucktragfähigkeit, α=90°, der unter materialund norm-abhängigen Umständen anwendbar ist (z.B. falls Deformationen in Kauf genommen
werden können oder gewisse
Endabstände eingehalten sind);
die Bedingungen sollten in
SELF\IfcProperty.Description
angegeben werden
Schubtragfähigkeit
Torsionsschubtragfähigkeit
Bezugs-Balkenhöhe, auf die die
mechanischen Eigenschaften
zutreffen; dient der Überprüfung
auf korrekte Materialzuweisung
58
Instability\
Factors
IfcProperty\
TableValue
definierend:
IfcPositiveRatio\
Measure
definiert:
IfcPositiveRatio\
Measure
definierend: Schlankheitsgrad;
definierend: ω- oder k-Zahlen für
Knicknachweise je nach
Bemessungsmethode (wenn >1
ω, wenn <1 k)
Holzwerkstoffe in plattenartiger Anwendung
Dies ist eine Zusammenstellung mechanischer Eigenschaften von Holzwerkstoffen
für platten- und scheibenartige Produkte, etwa Sperrholz oder OSB. Aussagen zu
balkenartigen Produkten in Bezug auf Anisotropie und auf Abstufung nach
Elementgröße (hier besonders Plattendicke) gelten analog.
Name
Property-Typ
Applicable\
Structural\
Design\
Method
IfcProperty\
SingleValue
InPlane
IfcComplex\
Property
OutOfPlane
IfcComplex\
Property
OutOf\
Plane\
Negative
IfcComplex\
Property
Datentyp bzw. An- Definition
wendgsbezeichng.
zutreffendes BemessungskonIfcLabel
zept: ‘ASD’ = zulässige
Spannungen, ‘LSD’ = Methode
der Grenzzustände, ‘LRFD’ =
load and resistance factor design
‘Mechanical’
d.h. Scheibenwirkung
‘Mechanical’
bezüglich Belastung „out-ofplane“, d.h. Plattenwirkung;
Zugzone asymmetrischer Querschnittsaufbauten gezogen
‘Mechanical’
bezüglich Belastung „out-ofplane“, d.h. Plattenwirkung;
Druckzone asymmetrischer
Querschnittsaufbauten gezogen
Jedes der mit ‘Mechanical’ bezeichneten komplexen Properties kann aus den
folgenden einfachen Properties zusammengesetzt sein. Properties der Typen IfcModulusOfElasticityMeasure und IfcPressureMeasure müssen Werte größer Null beinhalten. IfcPositivePlaneAngleMeasure müssen ≤ 90° sein. α bezeichnet den Winkel
zwischen Beanspruchung und Faser der äußeren Furniere bzw. „starker“ Materialrichtung.
Name
Young\
Modulus\
Bending
Young\
Modulus\
Tension
Young\
Modulus\
Comp
Property-Typ
IfcProperty\
TableValue
IfcProperty\
TableValue
IfcProperty\
SingleValue
Datentyp
definierend:
IfcPositivePlane\
AngleMeasure
definiert:
IfcModulusOf\
ElasticityMeasure
IfcModulusOf\
ElasticityMeasure
Definition
definierend: α; definiert: Elastizitätsmodul unter Biegung
definierend: α; definiert: Elastizitätsmodul unter Zug
Elastizitätsmodul unter Druck
59
Shear\
Modulus
Bending\
Strength
Comp\
Strength
Tensile\
Strength
Shear\
Strength
Bearing\
Strength
Raised\
Comp\
Strength
IfcProperty\
SingleValue
IfcProperty\
TableValue
IfcProperty\
TableValue
IfcProperty\
TableValue
IfcProperty\
TableValue
IfcProperty\
TableValue
IfcProperty\
SingleValue
IfcModulusOf\
ElasticityMeasure
definierend:
IfcPositivePlane\
AngleMeasure
definiert:
IfcPressure\
Measure
Reference\
Depth
IfcProperty\
SingleValue
IfcPositive\
LengthMeasure
Reference\
Thickness
IfcProperty\
SingleValue
IfcPositive\
LengthMeasure
IfcPressure\
Measure
Schubmodul
definierend: α; definiert:
Biegetragfähigkeit
Drucktragfähigkeit
Zugtragfähigkeit
Schubtragfähigkeit
Lochleibungstragfähigkeit
alternativer Wert der Drucktragfähigkeit, der unter materialund
norm-abhängigen Umständen
anwendbar ist (z.B. falls Deformationen in Kauf genommen
werden können oder gewisse
Endabstände eingehalten sind);
die Bedingungen sollten in
angegeben werden
Bezugs-Balkenhöhe, auf die die
Bezugs-Plattendicke, auf die die
7.2 Querschnitte
7.2.1 IfcStructuralProfileProperties36
Definition der IAI: Dies ist eine Zusammenstellung von statischen Eigenschaften
stabförmiger statischer Elemente mit Profildefinition. Weitere materialabhängige
Profileigenschaften werden in Unterklassen angegeben. — Siehe für die vollständige
Definition.
Diskussion
Eine zusätzliche Unterklasse für im Holzbau übliche Profile wird nicht benötigt, da
die in IfcStructuralProfileProperties selbst noch nicht enthaltenen Größen wie z.B.
36
definiert im IfcProfilePropertyResource-Schema (außerhalb der IFC-2x2-Plattform)
60
die Schubfläche bei holzbautypischen Profilen (Rechteck, Kreis, I) leicht aus den
Hauptgrößen errechnet werden können.
Manche Bemessungsverfahren für zusammengesetzte Querschnitte verwenden ideelle
Querschnittswerte. Auch diese können in IfcStructuralProfileProperties abgelegt
werden. Konsistenz mit den parallel zugewiesenen Materialkennwerten ist auf Anwendungsebene sicherzustellen.
7.3 Statische Elemente
7.3.1 IfcStructuralMember37
Definition der IAI: Die abstrakte Klasse IfcStructuralMember ist Basisklasse aller
statischen Elemente, die das Tragverhalten von Bauelementen wiedergeben. Statische
Elemente werden weiter in Stäbe und Flächenelemente unterschieden (siehe
IfcStructuralCurveMember and IfcStructuralFaceMember). […]
Zusätzliche Anwendungs-Definition für Holzbauteile und Holzwerkstoffplatten
vorgeschlagen von ST-5.
Anwendungs-Definition
Siehe [2] für Zuweisung von Material- und Profileigenschaften.
Orientierung anisotroper Materialien
Es werden vorläufig nur Holz und Holzwerkstoffe berücksichtigt. Die Ausrichtung
des Materials kann durch geometrische Repräsentationen erfolgen, wie es in den Anwendungsdefinitionen von IFCSHAREDBLDGELEMENTS.IfcMemberType geregelt
ist. Materialausrichtung kann auch anhand von Bauelementen ermittelt werden, die
mit IfcRelAssignsToProduct den statischen Elementen zugewiesen wurden.
Siehe [2] für EXPRESS-Spezifikation, Attribut-Definitionen und Vererbungsgraph.
7.4 Lasten, Systeme, Tragfähigkeitsnachweise
Alle zur Modellierung typischer Holztragsysteme und Lasten erforderlichen Datentypen sind bereits in IFC 2x2 als Ergebnis des Projektes ST-4 [4] enthalten. Diese
Datentypen sind vorwiegend im IfcStructuralAnalysisDomain-Schema definiert
(außerhalb der IFC-2x2-Plattform), siehe [2].
Ausnahmen:
• Es gibt keine Möglichkeit, Schnittkräfte zu speichern. Dies wäre für
separate Spannungsberechnungen u.a. Bemessungsaufgaben erforderlich.
Man kam zum Zeitpunkt der Modellformulierung zur Auffassung, dass
hierfür vorerst kein Bedarf besteht.
37
definiert im IfcStructuralAnalysisDomain-Schema (außerhalb der IFC-2x2-Plattform)
• Es gibt keinen Weg, die Tragfähigkeit von Verbindungsmitteln oder generell von Anschlüssen zu beschreiben. Statische Nachweise von HolzbauAnschlüssen hängen stark von der Anschlussart und geometrischen Parametern ab. Daher gibt es derzeit keinen universell gültigen Formalismus, der in
das IFC-Modell übernommen werden könnte.
• Umgebungsbedingungen, die die Bemessung von Bauteilen beeinflussen —
z.B. Luftfeuchte oder Bewitterung — mögen nicht all zu einfach aus dem
architektonischen Teilmodell (dem Koordinierungsmodell) abzuleiten sein.
Es könnte Bedarf für entsprechend Modellerweiterungen geben, nachdem
Erfahrung in der Anwendung des IFC 2x „Coordination View“ für die
Kopplung von Architekturentwurf und Statik gesammelt wurde.
61
62
8 Anhang
8.1 Literatur
[1]
[2]
Representation and Exchange. International Organization for Standardization,
TC184/SC4
International Alliance for Interoperability; 2003
[3]
Support Group; 2000
[4]
Christoph Hörenbaum, Peter Katranuschkov, Thomas Liebich, Matthias Weise,
et al: IAI ST-4 Released Drafts. iCSS project; 2001–2002
[5]
Universität Cottbus, Germany; 2000; ISSN 1615-3952
[6]
Standardbeschreibung Produktschnittstelle Stahlbau – Teil 2: Datenmodell.
Deutscher Stahlbau-Verband; Düsseldorf; 2002
Abb. 3-1
Erweiterungen, Änderungen und Schnittstellen im IFC-Modell...............16
Abb. 5-1
Extruded Area Solids für einfache Balken und Platten .............................24
Abb. 5-2
Bei IfcExtrudedAreaSolid implizierte Material-Ausrichtung ...................25
Abb. 5-3
Beispiele für ‘Fiber’- und ‘Layup’-Repräsentationen ...............................25
Abb. 6-1
Beziehungen zwischen Bauteilen und Features in ST-5 β1 ......................29
Abb. 6-2
Beziehungen zwischen Bauteilen und Features in ST-5 β3 ......................30
Abb. 6-3
Alternative Beziehungen in ST-5 β3 (für Baugruppen) ............................30
Abb. 6-4
Repräsentation eines Bauteils mit Abkantungen.......................................34
Abb. 6-5
Repräsentation eines Bauteils mit Cutout mittels CSG.............................36
Abb. 6-6
Repräsentation eines Bauteils mit Cutout mittels B-Rep ..........................36
Abb. 6-7 Zylindrische Löcher und Langloch ...........................................................38
Abb. 6-8
Eine Bauteilbeschriftung (Signatur) ..........................................................39
IAI-Projekt ST-5
Teil III
Implementierungshilfe
Deutsche Übertragung von „Part III: Implementation Guide“
Version: 1.β2
Status: Entwurf
14. Februar 2005
Danksagung
integrierte Planungsmethoden; Teilvorhaben 3: Produktmodell DtH“. Das DtHProjekt wurde an der Brandenburgischen Technischen Universität Cottbus, Lehrstuhl
Inhalt
3
Inhalt
1 Zusammenfassung
5
Gegenwärtiger Stand................................................................................................................5
Änderungen..............................................................................................................................6
Abkürzungen............................................................................................................................6
2 Allgemeine Betrachtungen
7
2.1 Implementierung von IFC-Schnittstellen.........................................................7
2.1.1
2.1.2
2.1.3
2.1.4
2.1.5
Arten der Verwendung von IFC ..................................................................................7
Typen von Programm-Schnittstellen zu IFC .............................................................10
Funktionelle Einheiten von IFC-Schnittstellen..........................................................12
Grundregeln für das Schreiben von IFC-Daten .........................................................14
Programm-Geschwindigkeit und Anwenderfreundlichkeit .......................................14
2.2 Grundlagen des IFC-Modells.........................................................................16
2.2.1
2.2.2
Die IFC-Modellarchitektur ........................................................................................16
Der Austausch-Kontext/ Projekt-Kontext..................................................................19
2.3 Das Geometrie-Modell...................................................................................21
2.3.1
2.3.2
2.3.3
2.3.4
2.3.5
2.3.6
2.3.7
Grundkonzepte ..........................................................................................................21
Extrusionskörper (extruded area solid)......................................................................21
Clippings und CSG....................................................................................................23
Facettierte B-Rep.......................................................................................................24
Facettiertes Oberflächenmodell (Face based surface model).....................................25
Hüllquader (Bounding Box) ......................................................................................26
Duplizierte Geometrieblöcke (Mapped Item)............................................................26
2.4 Systeme in Gebäuden (Teilmodelle)..............................................................28
2.4.1
2.4.2
2.4.3
2.4.4
2.4.5
2.4.6
2.4.7
Räumliche Gliederung (Spatial Structure).................................................................29
Allgemeine (gemeinsame) Bauelemente ...................................................................30
Das Architektur-Modell.............................................................................................30
Haustechnik-Systeme ................................................................................................31
Statische Berechnungsmodelle ..................................................................................31
Konstruktionsmodell .................................................................................................32
Weitere Systeme und Modelle...................................................................................33
2.5 Typ-Objekte und eingefügte Objekte (Occurrences) .....................................33
2.5.1
2.5.2
2.5.3
Was ist ein Typ? Was ist ein eingefügtes Objekt?.....................................................33
Exkurs über Typ-Objekte und eingefügte Objekte in IFC.........................................34
Typ-Objekte und eingefügte Objekte im Holzbau-Modell ........................................34
3 Beispiele
37
3.1 Ein einfaches Dachtragwerk ..........................................................................37
3.1.1
3.1.2
3.1.3
3.1.4
3.1.5
3.1.6
3.1.7
Objekte für die einzelnen Bauteile.............................................................................37
Beziehungs-Objekte, Verbindungen, Materialien......................................................38
Beziehungen zu anderen Teilmodellen......................................................................41
Platzierung und Formen der Bauteile ........................................................................42
Form des Typs für den Pfettenstiel ............................................................................44
Form des Typs für die Traufpfetten...........................................................................45
Form des Typs für die Firstpfette: CSG und Features ...............................................45
4
IAI-Projekt ST-5 — Structural Timber Model — Teil III: Implementierungshilfe
3.1.8
Form des Typs für die Sparren: B-Rep und Features ................................................51
3.2 Ein Dachbinder ..............................................................................................54
3.3 Eine Wandtafel...............................................................................................55
3.4 Besondere Anwendungen ..............................................................................56
3.4.1
3.4.2
Verfeinerte Modellierung im Ingenieurholzbau ........................................................56
Verwendung von IFC in Produktionssteuerungen.....................................................56
4 View-Definitionen
57
4.1 Zweck und Administration von View-Definitionen ......................................57
4.2 Relevante Views außerhalb der Holzbaudomäne ..........................................57
4.2.1
4.2.2
IFC 2x Coordination View ........................................................................................57
IFC 2x2 Structural Views ..........................................................................................58
4.3 Timber Construction View (Vorschlag) ........................................................59
4.3.1
4.3.2
4.3.3
4.3.4
Ziel-Szenarien............................................................................................................59
Unterstützte Klassen und Attribute............................................................................59
Unterstützte Repräsentationen ...................................................................................59
Weitere Vorgaben......................................................................................................59
4.4 Timber Frame View (Vorschlag)...................................................................60
4.4.1
4.4.2
4.4.3
4.4.4
Ziel-Szenarien............................................................................................................60
Unterstützte Klassen und Attribute............................................................................60
Unterstützte Repräsentationen ...................................................................................60
Weitere Vorgaben......................................................................................................61
4.5 Product Library View/ Parts Library View (Konzeption) .............................61
4.5.1
4.5.2
5 Anhang
Ziel-Szenarien............................................................................................................61
Unterstützte Klassen, Attribute, Repräsentationen ....................................................62
63
5.1 Literatur..........................................................................................................63
1 Zusammenfassung
5
1 Zusammenfassung
Die Motivation des Vorhabens, Anforderungen an das Datenmodell und die Wurzeln
des Modellvorschlags im DtH-Standard werden im vorangestellten Dokument “Structural Timber Model – Part I: Requirements” (Anforderungen) besprochen. Die für den
Holzbau eingereichten IFC-Modellerweiterungen werden in “Part II: Schema
Reference” (Klassen-Referenz) definiert.
Kapitel 2 dieses Dokuments geht auf allgemeine Fragen der Implementierung von
IFC und ihren Holzbauerweiterungen in CAD/CAE-Programme ein. Die Struktur des
Modells insgesamt und von Teilmodellen wird diskutiert. Es wird auf Beziehungen
zwischen Objekten und auf geometrische Modellierung eingegangen.
Kapitel 3 erklärt die Modellierung speziell von Holzkonstruktionen anhand einfacher
Beispiele.
Kapitel 4 schlägt minimale Anforderungen an Implementierungen des Structural
Timber Model für ausgewählte Anwendungsszenarien vor. Dieser Anforderungskatalog kann als Ausgangspunkt sogenannter View-Definitionen dienen. Views
begrenzen den Implementierungsaufwand und sichern zugleich die Interoperation
heterogener Implementierungen.
Gegenwärtiger Stand
Dieses Dokument gibt Implementierungs-Empfehlungen für Modellerweiterungen
an, die noch nicht durch die IAI Model Support Group in den offiziellen Standard
integriert wurden. Deshalb können sich alle Vorgaben noch ändern.
Das Dokument schlägt des Weiteren mögliche IFC-Views für den Holzbau vor.
Die tatsächliche Entwicklung der View-Definitionen wird Aufgabe der IAI Implementation Support Group und angeschlossener IAI-Arbeitsgruppen sein.
6
Änderungen
rev 1.β2
14. Februar 2005
Abschnitt 2.1.5 hinzugefügt;
Ergänzungen in Abschnitt 2.2.1;
Klärungen in Abschnitten 3.1.4 und 3.1.5;
kleinere Korrekturen
rev 1.β1
15. November 2004
Abschnitte 2.1.4, 3.1.4 – 3.3 hinzugefügt;
Abschnitt 2.5, 4.4 erweitert;
IfcRelAssociatesProfileProperties entfernt
22. Oktober 2004
Geometriemodell, Teilmodelle, Typen ↔ eingefügte Objekte erklärt,
Beispiele hinzugefügt
08. Oktober 2004
kleinere Änderungen
rev 1.α
08. September 2004
früher Entwurf
Abkürzungen
B-Rep
Boundary Representation, geometrisches Modell eines Körpers
(Volumenmodell) mittels Angabe seiner Hülle
CSG
Constructive Solid Geometry, geometrisches Modell eines Körpers
(Volumenmodell) mittels Boolescher Verknüpfung von Grundformen
GUID
Globally Unique Identifier, auch Universally Unique Identifier (UUID),
eine 128-bit-Zahl, die räumlich und zeitlich einmalig ist, kann mittels
geeigneter Algorithmen ohne Hilfe einer zentralen Registrierungsstelle
berechnet werden
SDAI
Standard Data Access Interface, ein API (Funktionsschnittstelle) für
Zugriffe auf Produktdaten [2]
SPF
STEP Physical File, das in [1] definierte Dateiformat
STEP
Standard for the Exchange of Product Data, die Normenreihe ISO 10303
für den Austausch von Produktdaten
7
2.1 Implementierung von IFC-Schnittstellen
2.1.1 Arten der Verwendung von IFC
Zusammenfassung
IFC können im Grunde auf zwei Arten verwendet werden: Wie herkömmliche Austauschdateien oder als zentrales Produktmodell (welches in Dateien oder auf einem
Modell-Server abgelegt sein kann). In beiden Fällen lesen und schreiben Programme
lediglich eine Untermenge des IFC-Modells. Die Untermenge muss einer IFC-ViewDefinition entsprechen, falls Zertifizierung der Konformität zu IFC angestrebt wird.
Verglichen mit traditionellen Import-/ Export-Filtern muss ein Programm weitergehende Anforderungen erfüllen, falls es mit einem zentralen Produktmodell arbeiten
soll. Beispielsweise müssen Objekt-IDs erhalten bleiben, und eine Änderungshistorie
muss mitgeführt werden. Wenn ein Modell modifiziert wird, müssen fachfremde
Daten intakt belassen werden. Ferner müssen anwendungsspezifische Daten, die noch
nicht durch IFC abgedeckt sind, mit dem IFC-Modell verknüpft werden.
Verwendung für Austauschdateien
Vorerst wird IFC überwiegend als Ersatz konventioneller Dateiformate eingesetzt,
insbesondere geometrie-orientierter Formate wie DWG und DXF. Typischerweise
erzeugt Akteur ‚A’ eine IFC-Austauschdatei mit Programm ‚X’ und sendet die Datei
an Akteur ‚B’, der die Datei in Anwenderprogramm ‚Y’ einliest.
Abb. 2-1
natives Format
Verwendung von IFC als Format von Austauschdateien
Anwendung
X
IFC
Anwendung
X
Y
natives Format
Y
DXF
Austauschdateien,
Dokumente
Akteur
A
Akteur
B
Der Aufbau von IFC-Dateien wird in ISO 10303-21 [1] vorgeschrieben. Eine Darstellung mittels XML ist ebenfalls möglich (siehe ifcXML-Dokumentation), aber
weniger relevant für den Einsatz als Dateiformat.
Der Inhalt einer IFC-Datei gibt nicht notwendigerweise die vollständige Information
wieder, die von ‚A’ in ‚X’ eingegeben wurde (während das native Dateiformat des
Programms ‚X’ die speziellen Anforderungen von ‚X’ abdeckt). Vom importierenden
Programm ‚Y’ wird wiederum nicht unbedingt gefordert, dass der komplette Inhalt
der IFC-Datei verstanden wird. Minimale Anforderungen an zertifizierte ex- und
importierende Programme. Wenn Akteur ‚B’ die importierten Daten im nativen
8
Format des Programms ‚Y’ abspeichert, werden alle nicht unterstützten IFC-Daten
verloren sein.
Die Verwendung von IFC als Austauschformat passt zur gegenwärtigen Kommunikationspraxis in der Bau- und Immobilienwirtschaft: Akteure tauschen Dokumente aus.
Die Dokumente geben jeweils nur ausgewählte Aspekte eines Projekts zu einem
bestimmten Zeitpunkt wieder.
Verwendung als zentrales Produktmodell
Ein Produktmodell wie IFC kann auch verwendet werden, um die Nachteile
dokumentbasierter Kommunikation zu beseitigen. Das Produktmodell wird zum
zentralen Ort für Speicherung und Abruf von Projekt-Informationen. Dokumente
spielen dann allenfalls eine untergeordnete Rolle in der Kommunikation. Sie dienen
lediglich als Eingabe in das Produktmodell sowie zur Wiedergabe von „Schnappschüssen“ des Modells.
Abb. 2-2
Verwendung von IFC als zentrales Produktmodell
IFCModell
Anwendung
X
natives Format
X
Anwendung
Anwendung
Y
Dokumente
Akteur
A
Z
natives Format
Y
Z
Dokumente
Akteur
Akteur
natives Format
C
B
Dateien nach ISO 10303-21 können auch verwendet werden, um ein zentrales
Modell-Datenarchiv vorzuhalten. Eine IFC-Datei wird allen teilnehmenden Akteuren/
Applikationen zum Lesezugriff zur Verfügung gestellt und wird schrittweise von den
Akteuren/ Applikationen aktualisiert. (Die Datei unternimmt einen „round trip“, eine
Rundreise.) Es ist ebenso möglich, das Modell-Archiv in mehrere separate IFCDateien aufzuteilen, vor allem wenn sich lose gekoppelte Teilmodelle identifizieren
lassen, beispielsweise Bauelemente unterschiedlicher Geschosse oder Elemente des
technischen Ausbaus aus unterschiedlichen Versorgungssystemen.
Leistungsfähiger dürfte allerdings der Einsatz eines Datenbank-Servers als zentrale
Ablage des Modells sein. Einige Modellserver-Produkte sind bereits verfügbar,
allerdings werden noch einige F&E-Anstrengungen, API-Entwicklungen und
Pilotprojekte erforderlich sein, bevor breiterer Einsatz solcher Server zu erwarten ist.
Ein mögliches, standardisiertes API für den Zugriff auf Modell-Archive bzw. -Server
stellt das SDAI dar [2]. ISO 10303-23, -24 und -27 definieren Anbindungen der
Sprachen C++, C und Java an SDAI. SDAI-Implementierungen sind frei oder
kommerziell als Bibliotheken bzw. Toolboxen erhältlich. Derzeit funktionieren diese
Toolboxen jeweils nur mit dem Modellserver-Produkt desselben Herstellers. D.h. ein
9
Client, der auf verschiedene Modellserver zugreifen können sollte, müsste
entsprechend an mehrere Toolboxen gelinkt werden.1
Der Inhalt eines zentralen Modells ist die Summe an Informationen, die die
verschiedenen Akteure beisteuern.2 Akteur ‚A’ generiert Input mit Programm ‚X’.
Alle Projektbeteiligten können diese Information lesen.3 Auch hier gilt, dass von
Anwenderprogrammen lediglich gefordert wird, eine Untermenge der im IFC-Modell
enthaltenen Information entsprechend einer View-Definition interpretieren zu
können. Andere Akteure tragen weiteren Input bei, und Akteur ‚A’ kann das
aktualisierte Modell zurück in seine Applikation übernehmen.
Damit ‚A’ seine Arbeit mit dem aktualisierten Modell fortsetzen kann — ohne zuvor
generierte Information zu verlieren — muss Programm ‚X’ nicht nur diejenigen
Informationen in IFC ablegen, die relevant für andere Akteure ist. Vielmehr sollte es
auch sämtliche Information, die allein für ‚A’ relevant ist, im Modell ablegen. Das
heißt, dass der komplette Informationsumfang des nativen Dateiformats von ‚X’
entweder direkt in IFC gespeichert oder auf andere Weise mit dem IFC-Datenbestand
synchron gehalten wird. Wie in Abb. 2-3 dargestellt, ist dies auf verschiedene Weise
möglich: Es können eigene Objekte mittels der IFC-Allzweck-Klassen (IfcProxy,
IfcBuildingElementProxy, IfcGroup) eingefügt werden. Vor allem können aber auch
an die üblichen IFC-Objekte eigene Attribute mittels sogenannter Property Sets
angehangen werden (IfcPropertySet). IFC-Objekte können auch mit externen
Dokumenten oder Bibliotheken assoziiert werden. Somit ist es möglich, global
verfügbare IFC-Daten mit lokal erforderlichen, anwendungsspezifischen Daten zu
verknüpfen.
Abb. 2-3
Ergänzen der IFC mittels Proxy-Objekten, Property Sets, Assoziationen
natives Objekt-Modell
natives Format
Assoziation
IFC-Objekt
Proxy-Objekt
X
IFC Property Set
Mapping zwischen X und IFC
eigenes Property Set
Bibliothek
tion
Assozia
Anwendung X
Dokument
IFC-Modell
Die Konstellation nach Abb. 2-2 ist deshalb flexibel genug in Hinsicht des Informationsumfangs des Datenmodells. Aber sie ist noch nicht ausreichend flexibel
hinsichtlich der dynamischen Bearbeitung des Modells. Üblicherweise arbeiten
mehrere Planer parallel, so dass lokale Informationsbestände divergieren. Es ist
zunächst sinnvoll, lokale Modell-Archive vorzuhalten, die mit dem globalen ProjektModell nur zu bestimmten, vereinbarten Zeitpunkten im Projektverlauf synchronisiert
1
Weiter unten wird noch kurz auf das SABLE-Projekt eingegangen, welches u.a. den Zugriff auf
Modellserver vereinheitlichen soll.
2
Genau genommen beinhaltet das Modell mehr als die Summe der Beiträge — es ist die Kombination
der enthaltenen Teilinformationen.
3
In künftigen Modellservern wird man auch feineingestellte Zugriffsrechte vergeben können.
10
werden (Abb. 2-4). Das globale Modell muss auf einem offenen Standard wie IFC
basieren. Für lokale Modelle kann ebenfalls IFC verwendet werden (um das Synchronisieren wesentlich zu erleichtern), es können dort aber auch proprietäre Datenmodelle eingesetzt werden.
Abb. 2-4
Verteiltes, konkurrierendes Planen mit separaten Modell-Repositorien
globales
Modell
lokales
Modell
Koor.
anw.
A
lokales
Modell
ProjektKoordinator
lokales
Modell
lokales
Modell
Anw.
Anw.
V
Anw.
Akteur
B
Z
Anw. Anw.
W
X
Y
Akteur
Akteur
C D
Akteur
E
F
Die lokalen Modelle können Teilmodelle (Domänen-Modelle) sein, die zurück in das
globale Modell (Basis-Modell) zusammengeführt werden (mapping, matching,
merging; Abb. 2-5, [8]).
Abb. 2-5
Zusammenführen parallel bearbeiteter Modelle
Basismodell, in Domänenmodellschema abgebildet
verändertes Domänenmodell
Domänenmodell, in Basismodellschema abgebildet
Basismodell
matching
merging
mapping
Planungsfortschritt
mapping
2.1.2 Typen von Programm-Schnittstellen zu IFC
Zusammenfassung
IFC-Implementierungen können in der Lage sein, IFC zu schreiben, zu lesen, oder
sowohl zu schreiben als auch zu lesen. Kombinierte Lese-/Schreib-Fähigkeit erfordert
weitergehende Überlegungen.
Anwenderprogramme mit Export-Schnittstelle
Export (write-only) ist die einfachste Variante. Der Implementierer muss eine EinWeg-Abbildung vom eigenen internen Objektmodell zum IFC-Modell erstellen. Ein
denkbares Beispiel für eine Export-Anwendung wäre ein Berechnungsprogramm für
Nagelplattenbinder, das die generierten Binderdaten in IFC ausgibt.
11
Anwenderprogramme mit Import-Schnittstelle
Dies ist ein anspruchsvollerer Typ der Implementierung. Das komplexe IFC-Modell
muss interpretiert und auf das interne Objektmodell des Anwenderprogramms
abgebildet werden. Gesonderte Vereinbarungen zwischen IFC-Implementoren
können hilfreich sein, die Modellkomplexität etwas einzuschränken, insbesondere
Vereinbarungen über bevorzugte Modellierungen, wenn die IFC-Spezifikation
verschiedene Wege der Modellierung zulässt. Ebenso schränken auch ViewDefinitionen die Komplexität des Modells ein.
Ein Beispiel für eine Anwendung mit lediglich Import-Fähigkeit wäre ein ModellViewer zur Kontrolle von IFC-Dateien. Ein weiteres denkbares Beispiel wäre eine
Ansteuerungs-Software einer NC-Maschine zur Fertigung von Bauteilen.
Abb. 2-6
Typen von Programm-Schnittstellen zu IFC
IFCModell
IFCModell
IFCIFCModell Modell
IFCModell
Anwendung
Anwendung
Anwendung
Anwendung
nur schreibende
Implementierung
nur lesende
Implementierung
lesende + schreibende
Implementierung
Schreib-LeseImplementierung
Mapping vom internen Objektmodell zum IFC-Modell
Mapping vom IFC-Modell zum internen Objekt-Modell
Anwenderprogramme mit separaten Import- und Export-Schnittstellen
Die oben angesprochenen Lese- und Schreib-Schnittstellen können natürlich
kombiniert werden. Die verschiedenen Abbildungen von IFC auf das interne Objektmodell und wieder zurück werden jedoch fast immer dazu führen, dass sich IFCDaten vor und nach dem Lesen und Schreiben erheblich voneinander unterscheiden
werden. Dass alle nicht unterstützten Klassen und Attribute verloren gehen werden,
ist nur eines der Probleme.
Ein Beispiel für eine Anwendung diesen Typs wäre ein CAD-Programm, das zwar
IFC-Dateien im- und exportieren kann, jedoch nicht für die Arbeit mit einem
zentralen Produktmodell gedacht ist. Jedoch könnte ein solches Programm indirekt
über ein koordinierendes Programm auf das zentrale Modell wie in Abb. 2-4 dargestellt zugreifen.
Anwenderprogramme mit kombinierter Lese-/Schreib-Schnittstelle
Für direkten Zugriff auf ein zentrales Produktmodell ist eine weitere funktionale
Ebene über den Schnittstellen für das Lesen und Schreiben erforderlich — eine
Ebene, die die Abbildung von IFC in interne Objekte und die Abbildung zurück in
IFC koordiniert. Im Grunde muss diese Ebene die Integrität des IFC-Modells nach
dem Zurückschreiben sicherstellen. Dazu ist zum Beispiel Zwischenspeicher für alle
nicht unterstützten IFC-Objekte erforderlich, außerdem eine Verwaltung der Verknüpfungen zwischen unterstützen und nicht unterstützten Objekten.
12
Beispiele für Anwendungen mit derart koordinierten Schnittstellen sind
• CAD-Programme für die verteilte Planung (sie empfangen einen AusgangsPlanungsstand und fügen weitere Planungsdetails hinzu);
• CAE-Programme für verteilten Entwurf und Berechnung von Tragwerken
oder Haustechnik (sie empfangen einen Gebäudeentwurf und/ oder BasisBerechnungsmodelle und fügen weitere Berechnungsmodelle oder Ergebnis
hinzu);
• Modell-Checker zur Korrektur oder Optimierung von Modellen;
• Plotprogramme, die Dokumente, z.B. Zeichnungen, vom Produktmodell
ableiten (und bestimmte Informationen in das Modell zurückschreiben,
welche ein späteres erneutes Generieren von Plänen unterstützen, wenn
Änderungen im Modell erfolgten);
• ein Interface zu einer Maschinensteuerung für die numerisch gesteuerte
Produktion von Bauelementen (es liest Bauteildaten ein und kann den
Statusinformation über den Produktionsfortschritt zurückschreiben).
2.1.3 Funktionelle Einheiten von IFC-Schnittstellen
Eine Leseschnittstelle
Es wird eine beispielhafte Leseschnittstelle für IFC-Dateien betrachtet. Folgender
Ebenen-Aufbau ist naheliegend:
Abb. 2-7
Mögliche Funktionsblöcke einer IFC-Importschnittstelle
EXPRESS-Schema
IFC
Datei im Format
STEP p21 (SPF)
Datei-Scanner
Datei-Parser
Mapping 1
} STEP-Toolbox
Mapping 2
Anwendungs-Programm
• Der Datei-Scanner bricht eine nach STEP Teil 21 formatierte Datei (SPF)
in Tokens auf (syntaktische Ebene). Jeder Datensatz in einer SPF enthält
eine Datensatz-Nummer, einen Klassennamen sowie eine Parameterliste.
Der Scanner kann des weiteren Zeichenketten-Tokens von der SPFKodierung in eine plattformabhängige Kodierung (von Umlauten usw.)
umwandeln.
• Der Datei-Parser erzeugt die Objekte. Aus jedem SPF-Datensatz werden
mit Hilfe der entsprechenden Klassendefinition der IFC-EXPRESSBeschreibung aus der Parameterliste die direkten Attributwerte ermittelt und
in entsprechende interne Datentypen gewandelt. Inverse und abgeleitete
Attribute werden generiert.
• Eine 1. Mapping-Ebene (Graphen-Verwaltungsebene) kann Funktionen
zur Reduktion der Komplexität der ursprünglichen IFC-Datenstrukturen
enthalten. Sie kann Bäume und andere Graphen von sog. RessourcenObjekten in wenigere, kompaktere Objekte umsetzen. Property Sets und
Geometrie-Modelle sind Kandidaten für solche Vereinfachungen.
13
Strukturen zur Speicherverwaltung wie Index-Tabellen und Referenzzähler
werden hier angelegt, um spätere Bearbeitung der Objekte vorzubereiten.
• Eine 2. Mapping-Ebene übersetzt vom IFC-Modell in das interne Modell
des Anwenderprogramms. Dies wird in der Regel der komplexeste Teil der
Schnittstelle sein.
Die ersten beiden Ebenen, Scanner und Parser, werden von STEP-Toolboxen zur
Verfügung gestellt. Die meisten Implementierungen werden eine solche Toolbox
zusammen mit einer vorkompilierten Repräsentation der IFC-EXPRESS-Definition
nutzen. Manche Toolboxen können EXPRESS-Schemen auch dynamisch einbinden.
Sofern Modellserver-Zugriff implementiert wird, steht anstelle von Scanner und
Parser eine Transaktions-Ebene. Die Schnittstelle zwischen Anwenderprogramm und
IFC-Modell kann dann darauf optimiert werden, immer nur relevante Teile des
Modells von der Modell-Datenbank zu laden.
Eine Schreibschnittstelle
Für eine Export-Schnittstelle werden ähnliche Ebenen wie für den Import benötigt.
Eine Mapping-Ebene übersetzt vom internen Modell zum IFC-Modell. Eine GraphenVerwaltung kann zusammengefasste Datenstrukturen entsprechend der feineren
Aufteilung in IFC aufteilen, d.h. unmittelbar in Datenstrukturen enthaltene Felder in
Baumstrukturen (z.B. in Property Sets) umwandeln. Diese Ebene kann auch globale
Optimierungen des Modells vornehmen.4
Danach werden Objekte auf ihre SPF-Repräsentation abgebildet, wobei inverse und
abgeleitete Attribute entfernt werden und die verbleibenden direkten Attribute in die
Reihenfolge gemäß EXPRESS-Schema gebracht werden. Alle Objekte werden seriell
als Datensätze nummeriert, Verweise auf andere Objekte durch deren DatensatzNummer ersetzt, Sonderzeichen in Zeichenketten gemäß [1] kodiert und die SPF
ausgeschrieben.
Auch hier werden Funktionalitäten unterhalb der Graphen-Verwaltung von STEPToolboxen angeboten.
Im Falle von Modellserver-Zugriff statt Dateiausgabe tritt anstelle der unteren Ebenen
eine Transaktionsmanagement-Ebene. Die Datenrepräsentation und das Protokoll
beim Serverzugriff sind üblicherweise hinter einem Serverzugriffs-API verborgen,
z.B. dem SDAI und seinen Sprachanbindungen.
Abstraktionen
Obschon ein Teil der benötigten Funktionalität in STEP-Toolboxen enthalten ist,
könnten noch wesentlich mehr IFC-spezifische Funktionen in anwendungs-unabhängiger Weise implementiert und als Bibliothek zur Verfügung gestellt werden.
Genau dies wird im SABLE-Projekt verfolgt. Die von SABLE vorgeschlagenen APIs
ersetzen Funktionalität bis einschließlich der Mapping-Ebene. Diese APIs sollen den
IFC-Zugriff vereinfachen, indem die Komplexität des IFC-Datenmodells durch mehr
4
Ein Beispiel solcher Optimierungen wäre das Löschen von Objekten aus dem IFC-Resource-Layer,
wenn diese nicht von Unterklassen von IfcRoot referenziert werden. (Dies ist mit wenigen Ausnahmen
möglich und wünschenswert.) Einige Ressourcen-Objekte können bzw. sollten als „shared Resources“
zusammengefasst werden. Dies wird im Folgenden unter “Die Rolle von Ressourcen-Objekten”
besprochen.
14
oder weniger einfache Programmier-Schnittstellen verborgen wird. Die SABLE-APIs
dienen zudem auch dazu, Modellserver-Zugriff zu vereinfachen und herstellerunabhängig zu vereinheitlichen.
2.1.4 Grundregeln für das Schreiben von IFC-Daten
Ihr IFC exportierendes Programm ist ein Modellierungs-Programm.
Lassen Sie Ihre Anwender wissen, dass sie ein Projekt-Modell erzeugen, nicht
einfach nur eine elektronische Zeichnung.
Teilen Sie die Bedeutung von Daten mit.
Beispiel: Falls der Anwender ein Dachtragwerk mit Hilfe eines Makros erzeugt hat,
exportieren Sie „Sparren“ und „Pfetten“ anstelle von einfachen „Balken“.
Lassen Sie Ihr Programm nicht raten.
Beispiel: Sofern der Anwender kein Material für ein Bauteil ausgewählt hat,
schreiben Sie keine willkürliche Material-Information in das IFC-Modell.
Vermeiden Sie Redundanz.
Schreiben sie keine Daten aus, die Empfänger-Programme aus anderen Projektdaten
ableiten können. Beispiel: Wenn Breite, Höhe und Länge eines Balkens als Parameter
schon im Geometriemodell eines Balkens enthalten sind, fügen Sie nicht noch
zusätzliche Attribute (Properties) bezüglich der Bauteilgröße an.
Achten Sie (nicht in übertriebenem Maße) auf Modellgröße und Dateigröße.
Das komplexe IFC-Modell führt bei einer gewissen Projektgröße zwangsläufig zu
umfangreichen Austauschdateien. Streben Sie an, das Verhältnis von Dateigröße zu
Modellgröße klein zu halten.5 Versuchen Sie jedoch nicht, mittels ModellierungsEntscheidungen Dateien zu komprimieren. Dateikompression sollte man tatsächlichen
Kompressionsprogrammen wie Zip überlassen.
2.1.5 Programm-Geschwindigkeit und Anwenderfreundlichkeit
Geschwindigkeits-Anforderungen an IFC-Schnittstellen
IFC ist ein Hilfsmittel für interdisziplinäre Kommunikation. Architekten, Ingenieure
und Bauunternehmer müssen häufig Projektinformationen austauschen. Kosten der
Kommunikation und ganz besonders ihr Zeitaufwand müssen minimiert werden, einschließlich der für Export, Import und Prüfung von Daten benötigten Zeit.
Damit der IFC-Standard im allgemeinen und IFC-Schnittstellen im besonderen
tatsächlich als Kommunikations-Werkzeug in der Bauindustrie geeignet sind — und
als solche akzeptiert werden —, müssen IFC-Export-/ Import-Schnittstellen hinreichend schnell sein. Falls Sie als Softwareanbieter in eine IFC-Implementierung
investiert haben und sich diese als sehr langsam herausstellt, wird sie für Ihre Nutzer
wenig brauchbar sein.
5
XML ist übrigens kaum für den datei-basierten Austausch von ganzen Gebäudemodellen oder
umfangreichen Teilmodellen geeignet; benutzen Sie dafür besser SPF.
15
Wie Geschwindigkeit optimiert werden kann
An dieser Stelle können nur sehr allgemeine Hinweise gegeben werden, da Themen
der Software-Entwurf, -Profiling und -Optimierung nicht in den Rahmen dieses
Dokuments gehören. Die Reihenfolge der nachstehenden Ideen soll keineswegs eine
Reihenfolge ihrer Effektivität bedeuten. Übrigens wurde im Abschnitt 2.1.3 der Punkt
Programmgeschwindigkeit außen vor gelassen.
Wie weiter oben angemerkt, ist Ihre IFC-fähige Anwendersoftware ein Modellierungs-Programm, und Ihre Nutzer sollten dies wissen. Es ist deshalb durchaus
gerechtfertigt, angemessene Hardware-Anforderungen vorzugeben, beispielsweise
vernünftige Ausstattung mit RAM.
Ihr Programm oder Ihre Toolbox sollte Leerlaufzeiten nutzen. Ein- und Ausgabe auf
Massenspeichern wie Festplatten oder auch interaktive Aufgaben lassen CPU-Zeit
übrig, die für Verwaltungen z.B. von Indextabellen oder Suchbäumen genutzt werden
kann. Solche zusätzlichen Datenstrukturen können Modellabfragen beschleunigen,
wie sie beim Einfügen oder Entfernen von Objekten oder allgemein bei der
Verfolgung aller Arten von Objekt-Beziehungen auftreten.
Hinterfragen Sie die Effektivität des darunterliegenden Betriebsystems oder der
Programmierumgebung, z.B. hinsichtlich Speicherverwaltung. Falls Sie eine STEPoder IFC-Toolbox eines Drittanbieters verwenden (und dies sollten Sie als Anwendungsprogrammierer generell tun), fordern Sie vom Anbieter der Toolbox deren
Optimierung.
Anforderungen an IFC-Schnittstellen hinsichtlich Anwenderfreundlichkeit
Obige Anmerkungen betreffs Geschwindigkeits-Anforderungen gelten übertragen
auch für Anwenderfreundlichkeit. Nutzer Ihres Programms wollen IFC-Export/
-Import in der Kommunikation mit Geschäftspartnern einsetzen. Ihre Kunden müssen
in der Lage sein, die Filter auch ohne Expertenwissen auf dem Gebiet IFC oder
Produktmodellierung einzusetzen.
Idealerweise funktioniert IFC-Import und -Export so einfach wie Laden und
Speichern des eigenen Dateiformats Ihres Programms. Natürlich sieht die Realität
interdisziplinären Informationsaustauschs nicht so einfach aus. Deshalb tendieren
IFC-Filter dazu, den Benutzer mit einer Anzahl von Optionen und Einstellungen zu
konfrontieren. Falls Sie solche Optionen anbieten, fragen Sie sich: Sind diese
Optionen notwendig? Verstehen die nutzer diese Optionen? Präsentieren Sie den IFCImport/ -Export auf gut erklärte Weise, oder besser noch auf selbst-erklärende Weise?
Import: Unterstützt Ihr Import-Filter die Nutzer dabei, die für sie relevanten
Informationen aus einem IFC-Modell so zügig wie möglich herauszusieben?
Rückmeldung in Echtzeit darüber, wie sich einzelne Import-Optionen auf die
eingelesenen Daten auswirken, wird hierzu oftmals wünschenswert sein. Das heißt,
anders als vom Import traditioneller Austauschdateien gewohnt, wird man den Import
eines Projektmodells wie IFC fast immer als interaktive Routine konzipieren müssen.
Export: Ihr Programm sollte den Anwender beim Modellieren bereits während der
Eingabe, d.h. während des Konstruierens unterstützen, nicht erst danach. Die Modellqualität der erstellten Daten sollte es ermöglichen, Export-Optionen minimal zu
halten.
16
2.2 Grundlagen des IFC-Modells
2.2.1 Die IFC-Modellarchitektur
Erforderliche Lektüre
Die wichtigste Dokumentation für IFC-Implementoren ist der „IFC Model Implementation Guide“ [4] in Zusammenhang mit der IFC-Modellreferenz [3].
Abstrakte Klassen
Diverse Datentypen sind in der EXPRESS-Definition von IFC als „abstrakte Überklassen“ gekennzeichnet. Solche Klassen können nicht instantiiert werden, d.h. sie
können nicht in Austauschdateien oder Modelldatenbanken auftauchen. Nur ihre nicht
abstrakt definierten Untertypen dürfen instantiiert werden.
Implementoren steht es frei, die genaue Vererbungshierarchie von IFC nachzuvollziehen oder „Abkürzungen“ über einige oder alle Überklassen hinweg zu nehmen,
vorausgesetzt, alle geerbten Attribute und Regeln werden beachtet.
IFC-Modellebenen
Die Modellebenen (Resource Layer, Core Layer, Interoperability Layer, Domain
Layer) — und in der Tat alle Schema-Grenzen — sind für Implementoren nicht
weiter von Bedeutung. Daher verwenden die meisten Toolboxen die sogenannte
„Langform“ der IFC-Express-Definition, die alle Datentypen in einem einzigen
EXPRESS-Schema zusammenfasst. Demgegenüber enthält die „Kurzform“ jedes
einzelne EXPRESS-Schema der IFC für sich, einschließlich der Interfaces zwischen
den Schemas.
Building
Controls
Domain
Domain
Layer
Interoperability
Layer
Core
Layer
Resource
Layer
Plumbing
FireProtection
Domain
Electrical
Domain
Architecture
Domain
Construction
Mgmt
Domain
Facilities
Mgmt
Domain
Shared
BldgService
Elements
Shared
Component
Elements
Shared
Bldg
Elements
Shared
Mgmt
Elements
Shared
Facilities
Elements
Control
Extension
Actor
Resource
Presentation
Appearance
Resource
Product Process
Kernel
non-platform part
Presentation
Dimensioning
Resource
Structural
Analysis
Domain
HVAC
Domain
IFC 2x2 platform
ISO/PAS 16739
Material
Property
Resource
Structural
Elements
Domain
DateTime
Resource
External
Reference
Resource
Geometric
Constraint
Resource
Geometric
Model
Resource
Geometry
Resource
Material
Resource
Profile
Resource
Property
Resource
Quantity
Resource
Representation
Resource
Topology
Resource
Utility
Resource
Presentation
Definition
Resource
Presentation
Organization
Resource
Presentation
Resource
Time
Series
Resource
Constraint
Resource
Approval
Resource
Measure
Resource
Cost
Resource
Structural
Load
Resource
Profile
Property
Resource
(GUID, Versionskennzeichnung)
Die Ebenen-Architektur von IFC (IFC 2x2 Kurzform-Distribution)
Vererbung von
IfcRoot
Abb. 2-8
spezifische konkrete
Konzepte
gemeinsame konkrete
Konzepte
gemeinsame abstrakte
Konzepte
Hilfs-Klassen:
gemeinsame Konzepte und
spezifische Konzepte
Allein die Grenze zwischen Ressourcen-Ebene und den übrigen Ebenen ist von
indirekter Bedeutung für Implementierungen:
• Alle Klassen im IFC Core Layer, Interoperability Layer und Domain Layer
sind Unterklassen von IfcRoot. Diese Klassen stellen alle Arten von
Produkten, Produkt-Spezifikationen, Prozessen, Gruppen und Akteuren dar.
Sämtliche Unterklassen von IfcRoot besitzen eine Objekt-Identität —
17
in Form einer GUID — und unterliegen einer Versionskennzeichnung. (Ein
Beispiel für Versionskennzeichnung wird in Abb. 3-3 auf Seite 38 gezeigt.
Weitere Informationen über die GUID und Versionskennzeichnung sind [5]
Abschnitt 2.1.1 und 2.1.3 sowie [4] Kapitel 5 zu entnehmen.)
• Demgegenüber ist keine einzige der Klassen in der IFC-Ressourcen-Ebene
eine Unterklasse von IfcRoot. Keine von ihnen besitzt eine GUID, so dass es
letztendlich nicht möglich ist, ihre Identität nach Modifikationen des
Modells wiederzuerkennen.
Die Rolle von Ressourcen-Objekten
Ressourcenobjekte dienen als Geometrie-Objekte (z.B. Punkte, Linien, B-Reps),
Querschnitte, Materialien, diverse Eigenschaftsobjekte (Properties), Objekten zur
grafischen Darstellung, einige der IFC-Beziehungsobjekte u.a.m.. Obwohl sie als
Klassen definiert sind, gelten sie eher als bloße Eigenschaften von „wahren“
Objekten, die von IfcRoot abstammen.
Dies hat mehrere Konsequenzen:
• Ressourcen-Objekte können gemeinsam genutzt werden (Sharing), d.h. von
mehreren anderen Objekten aus referenziert werden.6
• Jegliche Ressourcen-Objekte, auf die keine Verweise von anderen Objekten
aus existieren, sollten gelöscht werden.7
• Wenn Attribute eines Ressourcen-Objektes modifiziert werden, muss im
Allgemeinen die Versionsgeschichte desjenigen IfcRoot-Abkömmlings
aktualisiert werden, das direkt oder indirekt über andere RessourcenObjekte auf das geänderte Objekt verweist. Die Änderung des RessourcenObjektes bedeutet eine Änderung einer Eigenschaft des IfcRootAbkömmlings.
• Aus IFC-Ressourcenobjekten bestehende Graphen können von und nach
anders strukturierten programminternen Objekten transformiert werden.
(Beispiele solcher Graphen sind Property Sets, d.h. Bäume aus PropertyObjekten, oder z.B. ein B-Rep, dass ein komplexer Graph bestehend aus
Knoten, Kanten und Facetten ist.) Sofern solche Transformationen umkehrbar sind, bewirken sie keine Änderung desjenigen IfcRoot-Abkömmlings,
der auf diesen Graphen zeigt. Die Versionsgeschichte des IfcRoot-Abkömmlings braucht und darf bei einer solchen Operation nicht aktualisiert werden.
6
Es gibt eine einzige Ausnahme hinsichtlich des Sharings durch Abkömmlinge von IfcRoot: Die
globale Regel IFCKERNEL.IfcPlacementNotShared verbietet, dass Instanzen von IfcObjectPlacement
von mehr als einem IfcProduct verwendet werden.
Es gibt darüber hinaus einige Ausnahmen hinsichtlich des Sharings durch andere Ressourcen-Objekte.
Solche Ausnahmen werden durch die Kardinalität von inversen Attributen erzwungen. Ein Beispiel ist
das Attribut IfcMaterialLayer.ToMaterialLayerSet, welches verlangt, dass eine Materialschicht zu
genau einem Schichtaufbau gehört.
In Programmen, die ein Modell modifizieren, muss besonders auf korrekte Verwaltung gemeinsam
genutzter Ressourcen geachtet werden.
7
Ausnahmen: Materialeigenschaften und Beziehungsobjekte. Das sind Ressourcenobjekte, die nur
selbst auf Objekte verweisen, anstatt von anderen Objekten referenziert zu werden.
18
• Ein Ressourcen-Objekt, das von mehreren IfcRoot-Abkömmlingen
gemeinsam genutzt wird, kann durch Kopien ersetzt werden, die nur noch
von je einem IfcRoot-Abkömmling benutzt werden. Dies bedeutet ebenfalls
keine Veränderung der IfcRoot-Abkömmlinge, welche in deren Versionsgeschichte festzuhalten wäre.
• Wenn zwei IfcRoot-Abkömmlinge auf dieselbe Instanz eines RessourcenObjektes zeigen, haben sie nicht notwendigerweise eine identische Eigenschaft, lediglich eine gleiche Eigenschaft. In anderen Worten: Aus
Verweisen von IfcRoot-Abkömmlingen auf dasselbe Ressourcen-Objekt
kann nicht geschlossen werden, dass eine Beziehung zwischen den IfcRootAbkömmlingen bestünde.
Wenn sich zum Beispiel die geometrischen Repräsentationen zweier Bauteile in
einem Punkt treffen, so sind sie an diesem Punkt nicht notwendigerweise verbunden,
noch wird eine geometrische Beschränkung impliziert. Eine Modifikation des
Punktes des einen Bauteils muss nicht eine Modifikation des anderen Bauteils nach
sich ziehen. Tatsächliche Verbindungen von Bauteilen werden mit Hilfe von
Beziehungsobjekten modelliert, die Verweise zwischen den Bauteil-Objekten direkt
herstellen, nicht mittels Beziehungen zwischen ihren Repräsentations-Ressourcen.
Andererseits wird manchmal eine Beziehung impliziert, wenn zwei RessourcenObjekte auf dasselbe Ressourcen-Objekt verweisen. Dies ist der Fall, wenn all diese
Objekte Bestandteil einer komplexen Ressourcen-Datenstruktur sind. Verweisen
beispielsweise zwei Facetten einer B-Rep auf die gleiche Kante, so sind sie
miteinander über diese Kante verbunden.
Logischer Bereich der IFC, Geometrischer Bereich von IFC
Oben wurden die IFC-Ebenen-Architektur und die untergeordnete Rolle von
Ressourcenobjekten besprochen. Diese Punkte werden nun noch einmal aus einer
etwas anderen Perspektive betrachtet. Es ist möglich, zwischen einem „logischen“
und einem „geometrischen“ Bereich des IFC-Modells zu unterscheiden. Man könnte
sie auch „semantischen“ bzw. „Repräsentations-“Bereich nennen.
Der semantische Bereich beschreibt die Bedeutung von Dingen, dargestellt als IFCObjekte. Dieser Berech beschreibt auch Beziehungen der Dinge untereinander.
Solche Beziehungen werden in IFC fast immer mittels einer eigenen Gruppe von
Objekten modelliert (objectified relationships). Die Klassen aller dieser Objekte sind
in den oberen Modellebenen Core Layer, Interoperability Layer und Domain Layer
angesiedelt. Sie benutzen Klassen aus dem Resource Layer als Hilfsobjekte.
Abb. 2-9
Semantischer Modellbereich und Repräsentations-Modellbereich
process
actor
relationship
product
placement
representation
product
relationship
product
placement
representation
relationship
product
placement
representation
product
logischer Bereich
(Semantik)
geometrischer Bereich
(Repräsentation)
19
Der geometrische Bereich beschreibt nur Formen und räumliche Platzierung von
Dingen. Wie oben bereits erwähnt, gibt der geometrische Bereich keinerlei Beziehungen zwischen Dingen wieder, abgesehen von ihrer Anordnung im Raum. Weitergehende Informationen, z.B. ob der Körper eines Produkts Begrenzungen eines
anderen Produkts bewirkt, wird im logischen (semantischen) Modellbereich
abgebildet. Sämtliche Klassen des geometrischen (Repräsentations-)Bereichs sind im
Resource Layer angesiedelt.
2.2.2 Der Austausch-Kontext/ Projekt-Kontext
Jede IFC-Datei bzw. jedes IFC-Modellarchiv enthält Daten eines (oder keines)
Projektes.8 Die Klasse IfcProject etabliert im Projekt verwendete StandardMaßeinheiten und Repräsentations-Kontexte.
Einheiten
IFC schreiben keine feste Menge von Maßeinheiten vor. Stattdessen werden VorzugsEinheiten für ein Projekt gewählt; es können aber für eine Reihe von Klassen auch
eigene Einheiten vergeben werden. Metrische oder auch nichtmetrische Einheiten
stehen zur Auswahl. Für jede im Projekt verwendete Größe (Längen, Volumina,
Kräfte, Dichten, thermische Widerstände, Währungen usw.) wird eine entsprechende
Einheit als Eigenschaft des Projektes definiert. Siehe Beschreibung des IfcMeasureResource-Schema in [3].
Die meisten Klassen besitzen Attribute, denen nur ein zahlenmäßiger Wert gegeben
werden kann. Die Einheit zu diesem Wert ergibt sich dann aus der globalen
Zuweisung von Einheiten zum Projekt. Manche Klassen besitzen Wert-Attribute mit
zugeordneten Einheiten-Attributen. Die Einheiten solcher Attribute haben Vorrang
vor den projektweise globalen Einheiten. Lesende Anwenderprogramme müssen
diesen Vorrang berücksichtigen. Schreibende Applikationen sollten das Mischen von
Einheiten besser vermeiden.
Wenn ein Anwenderprogramm ein zuvor importiertes IFC-Modell wieder exportiert,
sollte es die ursprünglichen globalen Einheiten beibehalten. Andernfalls müsste es
sämtliche betroffenen Attributwerte umrechnen, wozu das Programm alle IFCSchemas unterstützen müsste.
Produkt-Repräsentation; Repräsentations-Kontexte
Produkte, die in einem Modell enthalten sind, können eine, keine oder mehrere
Repräsentationen besitzen. Das Konzept einer Repräsentation in IFC basiert auf
ähnlichen Konzepten der ISO 10303-41 und -43. Arten der Repräsentation in IFC
sind
• Repräsentation der Form (shape representation), d.h. ein mehr oder
weniger exaktes Modell der geometrischen Form des Produkts;
• Repräsentation der Topologie (topology representation), d.h. ein Modell,
das geometrische mit topologischer Information verknüpft (Beziehungen
zwischen Knoten, Kanten, Pfaden usw.) — diese Repräsentation wird in
IFC 2x2 vor allem in Modellen für statische Berechnung verwendet;
8
Dies wird von der globalen Regel IFCKERNEL.IfcSingleProjectInstance gefordert.
20
• stilisierte Repräsentation (styled representation), d.h. eine grafische
Darstellung, die nicht nur die Form, sondern auch nichtgeometrische
Information (z.B. betreffs Funktion oder Material) mittels von Anwendern
erkennbarer Symbole enthält (z.B. farbige Linien und Schraffuren).9
Ein Produkt kann unter anderem deswegen mehrere Repräsentationen erhalten, damit
verschiedene Aspekte des Produkts dargestellt werden können. Beispielsweise
können einem Fenster separate Repräsentationen der Flügel und des Rahmens
zugeordnet werden. Mehrere Repräsentationen eines Produkts können aber auch ein
und denselben Aspekt in unterschiedlichen Kontexten darstellen. Beispielsweise
könnte ein Produkt in einem rein geometrischen 3D-Kontext sowie in einem
stilisierten 2D-Kontext repräsentiert werden.
Abb. 2-10
Ein Produkt mit Repräsentationen in verschiedenen Kontexten
IfcProject
(ABS) IfcProduct
(ABS) IfcObjectPlacement
IfcGeometricRepresentationContext
ContextType=’Sketch’
CoordinateSpaceDimension=3
ContextType=’Detail’
ContextType=’Outline’
IfcProductDefinitionShape
IfcShapeRepresentation
IfcBoundingBox
IfcExtrudedAreaSolid
IfcStyledRepresentation
IfcStyledItem
IfcStyledItem
Repräsentations-Kontexte in einem Projekt und ihre Unter-Kontexte können sich in
folgenden Hinsichten unterscheiden:
• nach dem Detailgrad der im Kontext enthaltenen geometrischen Modelle
(z.B. voll detaillierte Form oder vereinfachte Form wie Bounding Boxes);
• nach Dimensionalität (3D oder 2D);
• nach Art der Projektion im Falle von 2D-Repräsentationen (Grundriss,
Schnitt, Ansicht...);
• nach dem Zielmaßstab, insbesondere von stilisierten Repräsentationen;
• nach numerischer Genauigkeit der Geometriemodelle, d.h. demjenigen
Durchmesser, innerhalb dessen zwei Punkte als identisch angesehen werden.
Jeder Repräsentations-Kontext etabliert ein „Weltkoordinatensystem“ und die NordRichtung. Alle Repräsentationskontexte innerhalb eines Projektes beziehen sich auf
dasselbe Weltkoordinatensystem und haben die xy-Ebene gemeinsam. Dies ist
9
Es gibt keine direkte Verbindung zwischen solchen Symbolen und den Produkteigenschaften, die sie
repräsentieren. Eine stilisierte Repräsentation dient also vorrangig der Visualisierung eines Produkts —
im Gegensatz zu einer Shape-Repräsentation, die der Definition des Produkts dient.
Ohne stilisierte Repräsentation müssten sämtliche Visualisierungen immer von der Shape-Repräsentation abgeleitet werden, und zwar jedes mal, nachdem ein Anwenderprogramm das Modell neu
eingelesen hat. Es ist nun möglich, das Ergebnis einer Visualisierung bzw. zeichnerischen Eingabe
gleich vom sendenden Programm per stilisierter Repräsentation im Modell abzulegen.
21
erforderlich, weil Produkte (Unterklassen von IfcProduct) lediglich eine einzige
räumliche Platzierung besitzen, die für alle Kontexte gilt.
2.3 Das Geometrie-Modell
Dieser Abschnitt diskutiert einige der in IFC zur Verfügung stehenden Mittel, Körper
und Flächen zu modellieren — soweit sie für die Modellierung von Holzbauteilen
interessant sind — sowie zwei besondere Konstrukte, die Bounding Box (Hüllquader)
und das Mapped Item (mehrfache Einfügung von Grafikblöcken).
Stilisierte Repräsentationen werden hier nicht betrachtet. Elemente der topologischen
Repräsentation werden nur erwähnt, soweit sie für Volumenmodellierung benötigt
werden.
2.3.1 Grundkonzepte
Eine Produkt-Repräsentation (IfcProductRepresentation oder IfcProductDefinitionShape) kann eine oder mehrere Repräsentationen (Untertypen von IfcRepresentation)
enthalten. Jede Repräsentation kann ein Modell der gesamten Form des Produkts oder
lediglich eines Teils der Form sein. Zum Beispiel kann ein Holzbalken mit Zapfen als
undetailliertes Modell der Ausgangsform, als vollständig detailliertes Modell der
tatsächlichen Form und zusätzlich als Modell der Zapfen-Oberflächen vorliegen. Jede
der Repräsentationen kann als sogenannter Form-Aspekt adressiert werden (IfcShapeAspect), beispielsweise zu dem Zweck, Produkteigenschaften direkt mit dem FormAspekt in Verbindung zu bringen.
Jede Repräsentation enthält ein oder mehrere Repräsentations-Elemente (representation items). Im Falle von Volumenmodellen ist dies in der Regel nur ein einziges
Element, welches dann aus weiteren Elementen aufgebaut ist.
2.3.2 Extrusionskörper (extruded area solid)
Ein IfcExtrudedAreaSolid beschreibt einen 3D-Körper durch Verziehen eines Profils
entlang einer geraden Achse. Beispiele:
• Ein einfacher Holzbalken kann mittels Rechteckprofil modelliert werden
(mit den Parametern Breite und Höhe), welches entlang der Balkenachse
verzogen wird (mit dem Parameter Länge).
• Eine OSB-Platte kann mittels Rechteckprofil modelliert werden, das die
Breite und Dicke der Platte enthält; das Profil wird in Längsrichtung der
Platte extrudiert. Alternativ kann die Platte als polygonales Profil modelliert
werden, das in Platten-Dickenrichtung extrudiert wird.
Folgende Restriktionen werden in der EXPRESS-Definition von IfcExtrudedAreaSolid und seiner Überklasse auferlegt: Das Profil muss eine Fläche sein (keine bloße
Kurve). Das Profil darf kein abgeleitetes Profil sein (ein durch Transformation eines
Grundprofiltyps entstandener Profiltyp). Die Extrusionsrichtung darf nicht in der
Profilebene liegen.
22
Abb. 2-11
Beispiele von Bauteilen, die als Extrusionskörper modelliert werden
Balken
in Längenrichtung
extrudierte Platte
in Dickenrichtung
extrudierte Platte
Extrusionsrichtung, Extrusionstiefe
Profil
Eine vierte Restriktion ist informell für Bauteile (IfcMemberType) in Holzbaukonstruktionen vereinbart, also vor allem Balken und Holzwerkstoffplatten: Die Extrusion verlaufe senkrecht zum Profil. Dies stellt sicher, dass die Profilparameter
identisch mit den tatsächlichen Querschnittsmaßen sind, wie sie beispielsweise in
Stücklisten erscheinen.
Abb. 2-12
Objektgraph eines als Extrusionskörper repräsentierten Produkts
(ABS) IfcProduct
IfcProject
IfcProfileDef
ProfileType=AREA
ProfileName=...
RepresentationType=’SweptSolid’
Depth=...
IfcDirection
IfcAxis2Placement3D
IfcCartesianPoint
IfcDirection
IfcDirection
Abb. 2-13
Objektgraphen von Profildefinitionen (Beispiele)
IfcRectangleProfileDef
IfcIShapeProfileDef
IfcArbitraryClosedProfileDef
XDim=...
YDim=...
OverallWidth=...
OverallDepth=...
WebThickness=...
FlangeThickness=...
FilletRadius=...
IfcPolyline (oder andere IfcCurve),
Kurve muss geschlossen sein
IfcAxis2Placement2D
IfcCartesianPoint
IfcDirection
IfcAxis2Placement2D
IfcCartesianPoint
IfcDirection
IfcCartesianPoint
IfcCartesianPoint
IfcCartesianPoint
IfcCartesianPoint
Die letztendliche Platzierung des Extrusionskörpers wird durch folgende kartesische
Transformationen beeinflusst, die durch die diversen Placement-Objekte in den
Abb. 2-12 und Abb. 2-13 definiert sind:
• 2D-Translation und Rotation der Profildefinition in ihrer Ebene, gegeben
durch IfcExtrudedAreaSolid.SweptArea.Position (nur im Fall parametrischer
Profile, nicht bei Freiform-Profilen);
• 3D-Translation und Rotation der Profildefinition — und zugleich der
Extrusionsrichtung — durch IfcExtrudedAreaSolid.Position;
23
• 3D-Translation und Rotation dieser Repräsentation und aller anderen
Repräsentationen des Produkts anhand IfcProduct.ObjectPlacement.
Es gibt weitere IFC-Extrusionstypen, die das Verziehen entlang einer Kurve oder
veränderliche Profile entlang der Achse oder Kurve gestatten.
2.3.3 Clippings und CSG
Wie erwähnt sollen Extrusionskörper in der Holzbaudomäne nur orthogonal erstellt
werden. Das lässt nur einfache Formen zu. Ein Balken mit Gehrungen muss deshalb
z.B. mittels Clipping modelliert werden (IfcBooleanClippingResult). Ein weiteres
Beispiel für die Anwendung von Clippings ist eine Giebelwand. Diese wird üblicherweise als Extrusionskörper modelliert, dessen Grundriss als Profil in Höhenrichtung
verzogen wird. Die in die Dachschrägen ragendenden Wandabschnitte werden mittels
Clipping entfernt.
Abb. 2-14
Objektgraph eines als Clipping repräsentierten Produkts
IfcProject
(ABS) IfcProduct
RepresentationType=’Clipping’
IfcBooleanClippingResult
(ABS) IfcSweptAreaSolid or
Operator=DIFFERENCE
IfcHalfSpaceSolid
(ABS) IfcSurface - e.g. IfcPlane
IfcAxis2Placement3D
IfcCartesianPoint
IfcDirection
IfcDirection
Das Resultat des Clippings kann erneut in einer weiteren Ebene geclippt werden.
Ferner können anstelle der einfachen Ebene IfcPlane auch komplexere Oberflächen
bzw. Halbräume zum Clippen verwendet werden.
Als Erweiterung des Konzepts des Clippings — welches ja nichts anderes als eine
Subtraktion eines Halbraums von einem Körper ist — unterstützt IFC auch die Subtraktion eines Körpers von einem anderen, die Vereinigung zweier Körper, sowie die
Schnittmenge zweier Körper. Dies wird mit IfcBooleanResult dargestellt (der Überklasse von IfcBooleanClippingResult). Als Operanden Boolscher Operationen werden
in IFC sämtliche Solid-Modelle zugelassen (derzeit: B-Rep, Extrusions- und Revolutionskörper, IfcCsgSolid10), Halbräume, sowie IfcBooleanResult. Wichtig: Derzeit
unterstützen die meisten IFC-Implementierungen kein volles CSG, jedoch wird
Clipping breit unterstützt.
Siehe auch [4] Abschnitt 3.5.1.4.3.
10
IfcCsgSolid ist einfach nur ein Container für ein IfcBooleanResult. Da aber IfcBooleanResult auch
unmittelbar als Operand auftreten darf, benötigt man IfcCsgSolid hier nicht weiter.
24
2.3.4 Facettierte B-Rep
Eine B-Rep repräsentiert einen Körper anhand seiner Hüllflächen. IFC unterstützt
derzeit nur facettierte B-Reps, d.h. Körper mit ebenen Oberflächen (und demzufolge
nur mit geraden Kanten). Wenn exakte Modellierung gekrümmter Kanten und
Flächen gewünscht wird, sollten Extrusionskörper oder CSG verwendet werden. Es
gibt zwei Typen von B-Reps in IFC: Ohne und mit Hohlvolumina11.
Eine B-Rep ist hierarchisch gegliedert. Auf unterster Ebene sind Vertices (Knoten
bzw. Ecken) mit kartesischen Koordinaten gegeben.12 Darüber hinaus wird nur topologische Information vorgehalten: Verbindungen der Knoten durch Kanten, und
Berandung von Flächen (Facetten) durch Kanten. Die Menge der Facetten ist die
Schale, die den Körper einhüllt.
Die Eckkoordinaten beziehen sich auf das IfcObjectPlacement des Produkts.
Abb. 2-15
Objektgraph einer B-Rep eines Produkts (Beispiel: Tetraeder)
(ABS) IfcProduct
IfcProject
Precision=...
1
IfcFacetedBrep
c
2
a
IfcClosedShell
a
b
IfcFace
I
4
3
RepresentationType=’Brep’
b
IfcFace
II
d
c
IfcFace
III
IfcCartesianPoint
IfcCartesianPoint
d
IV
1
1-2-3(-1)
1-3-4(-1)
1-4-2(-1)
2-4-3(-2)
IfcFaceOuterBound
IfcPolyLoop
2
IfcCartesianPoint
IfcFace
IfcFaceOuterBound I:
IfcFaceOuterBound II:
IfcFaceOuterBound III:
IfcFaceOuterBound IV:
3
IfcCartesianPoint
4
Kanten, die sich in einem Knoten treffen, sollten auch auf dieselbe Instanz von
IfcCartesianPoint zeigen.13 Anders als die IfcPolyline in Abb. 2-13 beinhaltet
IfcPolyLoop alle ihre Punkte nur einmal. Der erste Punkt wird zugleich auch als der
letzte Punkt der IfcPolyLoop aufgefasst. Man beachte, dass jede Facette orientiert ist.
Ihre Flächennormale zeigt vom Körper nach außen. Die Orientierung der Flächennormale hängt von der Reihenfolge der Knoten in der umrandenden IfcPolyLoop ab:
Schaut man von außerhalb des Körpers auf die Facette, so sind die Knoten gegen den
Uhrzeigersinn sortiert.
11
Hohlvolumina, die nicht mit dem Raum außerhalb des Körpers in Verbindung stehen (für Holzkonstruktionen kaum relevant)
12
Gemäß informeller Definition der IAI ist derzeit nur IfcPolyLoop als IfcFace(Outer)Bound gestattet.
Knoten einer IfcPolyLoop sind immer vom Typ IfcCartesianPoint.
13
Dies ist keine strikte Regel. Die Kanten könnten auch jeweils auf eigene Kopien der Cartesischen
Punkte zeigen, aber das ist nicht empfehlenswert.
25
Eine Facette kann außer der äußeren Umrandung auch noch innere Umrandungen
besitzen, welche Öffnungen in der Facette umschließen. Maximal eine von allen
Umrandungen einer Facette sei eine Instanz von IfcFaceOuterBound, die anderen
Instanzen seien vom Typ IfcFaceBound.
Ein sendendes Anwenderprogramm hat sicherzustellen, dass keine Umrandung sich
selbst oder andere Umrandungen kreuzt, dass keine Umrandung eine andere Umrandung der selben Facette berührt, und dass alle Knoten einer Facette in derselben
Ebene liegen. Ob ein Punkt in einer Ebene, einer Linie oder einem anderen Punkt
oder knapp außerhalb liegt, hängt von IfcGeometricRepresentationContext.Precision
ab. Siehe auch [4] Abschnitt 3.5.1.4, sowie [3].
2.3.5 Facettiertes Oberflächenmodell (Face based surface model)
Zwei Typen von Oberflächenmodellen existieren in IFC: IfcShellBasedSurfaceModel
und IfcFaceBasedSurfaceModel. Siehe [4] Abschnitt 3.5.1.3 für weitere Information.
Jedes facettierte Oberflächenmodell besteht aus einer Gruppe untereinander verbundener Facetten oder aus mehreren solcher Gruppen. Die Faccetten müssen eben und
von IfcPolyLoop umrandet sein, wie bei B-Rep. Aber anders als B-Rep kann jede
Grippe von Facetten eine IfcOpenShell oder IfcClosedShell sein.14 Ein Oberflächenmodell mit einer offenen Schale wird manchmal auch „offene B-Rep“ genannt. Auch
hier zeigt die Reihenfolge der Punkte in den IfcPolyLoops die Richtung der Flächennormalen an.
Alle Knotenkoordinaten werden im lokalen Koordinatensystem angegeben, dass vom
IfcObjectPlacement des jeweils repräsentierten Produkts aufgespannt wird.
Abb. 2-16
Beispiel eines als Oberflächenmodell repräsentierten Produkts
(ABS) IfcProduct
IfcProject
Precision=...
1
2
a
b
IfcShellBasedSurfaceModel
IfcOpenShell
4
a
3
IfcFace
I
IfcCartesianPoint
b
II
1
IfcCartesianPoint
IfcFace
IfcFaceOuterBound I: 1-2-3(-1)
IfcFaceOuterBound II: 1-3-4(-1)
IfcFaceOuterBound
IfcPolyLoop
2
IfcCartesianPoint
3
IfcCartesianPoint
14
RepresentationType=
’SurfaceModel’
4
Alternativ erlaubt IfcFaceBasedSurfaceModel auch noch Instanzen der Überklasse von offenen und
geschlossenen Schalen, IfcConnectedFaceSet. Im Gegensatz zu seinen Untertypen verzichtet IfcConnectedFaceSet auf die strikte Einhaltung mehrerer topologischer Regeln offener oder geschlossener
Schalen.
26
Offene Oberflächenmodelle werden in IFC z.B. verwendet, um das Grundstück darzustellen (sogenannte „facetation representation“ von IfcSite), oder um Bereiche der
Oberfläche eines Bauelements zu kennzeichnen (Oberflächen gesägter oder gefräster
Features von Holzbauteilen; beschichtete oder anderweitig behandelte Oberflächen
von Bauteilen).
2.3.6 Hüllquader (Bounding Box)
Eine Bounding Box kann zusätzlich oder anstelle eines detaillierteren geometrischen
Modells angegeben werden. Der Quader wird durch einen Eckpunkt in kartesischen
Koordinaten und drei Kantenlängen definiert; siehe Abb. 2-17. Seine Koordinaten
beziehen sich auf das IfcObjectPlacement des jeweiligen Produkts.
Abb. 2-17
Objektgraph eines mittels Bounding Box repräsentierten Produkts
IfcProject
(ABS) IfcProduct
RepresentationType=
’BoundingBox’
IfcBoundingBox
IfcCartesianPoint
XDim=... YDim=... ZDim=...
2.3.7 Duplizierte Geometrieblöcke (Mapped Item)
Gemeinsame Nutzung von Repräsentationen durch Mapping
Eine „mapped representation“ enthält keine geometrische oder topologische Information außer einem Verweis auf eine andere geometrische oder topologische Repräsentation, die sogenannte Quelle der Abbildung oder „representation map“ (IfcRepresentationMap). Dieser Mechanismus erlaubt, dass mehrere Instanzen von IfcProduct auf
explizite Weise identische Repräsentations-Daten verwenden.
Abb. 2-18
Mehrfach verwendete „mapped representation“
IfcRelDefinesByType
(ABS) IfcProduct
(ABS) IfcProduct
(ABS) IfcProduct
IfcMappedItem
IfcMappedItem
IfcMappedItem
(ABS) IfcTypeProduct
IfcRepresentationMap
27
Die IfcRepresentationMap ist üblicherweise einem Typ-Objekt zugewiesen, d.h. einer
Instanz einer Unterklasse von IfcTypeProduct. Dieses Objekt ist zugleich der Typ, der
alle IfcProduct-Instanzen definiert, welche die IfcRepresentationMap verwenden.15
Mapping-Transformation
Die IfcRepresentationMap enthält außer den Repräsentations-Elementen auch ein
IfcAxis2Placement (2D oder 3D; ein kartesischer Punkt relativ zu den Repräsentations-Elementen und optionale Richtungsangaben), die den TransformationsUrsprung definieren (mapping origin).
Das IfcMappedItem enthält die Referenz auf die Quelle und einen kartesischen Transformations-Operator (Transformations-Ziel, mapping target). Die Repräsentation
wird einer affinen Transformation unterworfen, wenn sie vom Ursprung auf das Ziel
abgebildet wird.
Abb. 2-19
Beispiel eines Produkts und seines Typs mit duplizierter Geometrie
IfcRelDefinesByType
IfcProject
(ABS) IfcProduct
RepresentationType=
’MappedRepresentation’
IfcMappedItem
IfcCartesianTransformationOperator
Mapping-Ziel
Mapping-Ursprung
IfcAxis2Placement
IfcCartesianPoint
Scale=...
IfcCartesianPoint
IfcDirection
IfcDirection
+ weitere Attribute bei 3D-Mapping
und ungleichförmiger Skalierung
IfcDirection + weitere
Richtung bei 3D-Mapping
RepresentationType=...
(ABS) IfcRepresentationItem
abzubildende Repräsentation
Der Transformations-Operator beinhaltet Attribute für alle Arten affiner Transformationen: Translation, Rotation, Spiegelung, windschiefe Verzerrung, gleichförmige
Skalierung und ungleichförmige Skalierung. Aus dem Transformations-Operator und
dem Transformationsursprung lassen sich folgende Parameter der Transformation
ableiten: Ein lokaler Ursprungsvektor A, eine Skalierungsmatrix S und eine Rotations- und Verzerrungsmatrix T.16 Punkte P werden wie folgt transformiert: P* =
S T P + A.
15
Es ist auch möglich, IfcRepresentationMap ohne zugehöriges IfcTypeProduct zu instantiieren.
Jedoch sollte man zumindest in der Holzbaudomäne immer mit IfcTypeProduct arbeiten.
16
Während die Berechnung von T in [3] dokumentiert ist, sind die Berechnung von S und ungleichförmige Skalierungen von Kurven und Flächen nicht weiter dokumentiert. S ist offenbar eine Diagonalmatrix, die mit den Attributwerten Scl, Scl2, Scl3 des Transformations-Operators besetzt ist. Im Falle
gleichförmiger Skalierung ist S lediglich ein skalarer Faktor (der Attributwert Scl).
28
Zusammengenommen durchlaufen die Repräsentations-Elemente von der MappingQuelle folgende Transformationen, in dieser Reihenfolge:
• affine Transformation wie eben beschrieben,
• Translation und Rotation gemäß IfcObjectPlacement desjenigen Produkts,
dessen Repräsentation das IfcMappedItem enthält.
Die einfachste Transformation erfolgt, wenn Ziel und Ursprung sich auf den gleichen
(oder selben) Punkt beziehen und die optionalen Richtungs- und Skalierungs-Attribute fortlassen. Dann erfolgen keine Translation und Rotation außer derjenigen, die
von IfcProduct.ObjectPlacement vorgesehen ist, auch keine Spiegelung, Verzerrung
oder Skalierung.
Abb. 2-20
Einfachster Fall einer kartesischen Transformation: Identität
RepresentationType=
IfcMappedItem
IfcCartesianTransformationOperator3D
Mapping-Ziel Scale=$
IfcAxis2Placement3D
Mapping-Ursprung
IfcCartesianPoint
Coordinates=(0.,0.,0.)
Hinweis: In den für den Holzbau vorgeschlagenen View-Definitionen wird in
„mapped representations“ immer nur die Identitäts-Transformation
verwendet.
Siehe auch [4] Abschnitte 3.5.2, 4.4 und 12.1.1, sowie die Dokumentation von
IfcGeometryResource-Schema [3] für weitere Information über „mapped representation“.
Die Rollen, die Typ-Objekte (Unterklassen von IfcTypeProduct) und eingefügte
Objekte („occurrences“, Unterklassen von IfcProduct) in der Holzbaudomäne spielen,
werden im folgenden Abschnitt 2.5.3 dieses Dokuments besprochen.
2.4 Systeme in Gebäuden (Teilmodelle)
Ein IFC-Modell kann mehr oder weniger vollständige und vielfältige Aspekte eines
Bauprojekts beinhalten. Abhängig von der Art des Projekts lassen sich Teilmodelle
identifizieren, welche im folgenden beschrieben werden. Diese Teilmodelle sind
allerdings nicht immer klar abgrenzbar. Teilmodelle bilden verschiedene Systeme in
Gebäuden ab, beispielsweise Tragsysteme oder Heizsysteme.
Zwischen den Untermodellen werden Beziehungen über Beziehungsobjekte hergestellt (Untertypen von IfcRelationship). Ein Vorteil dieser Beziehungsobjekte — im
Vergleich zu direkten Beziehungsattributen — ist die Möglichkeit, Teilmodelle aus
dem Gesamtmodell einfach herauszulösen, beispielsweise um das Teilmodell lokal
weiterzubearbeiten, auch konkurrierend zur Bearbeitung der anderen Teilmodelle.
Allein die Beziehungsobjekte, welche die Schnittstellen zwischen den Teilmodellen
29
bilden, müssen bei solchen Vorgängen an entfernte oder hinzugefügte Modellteile
angepasst werden.
2.4.1 Räumliche Gliederung (Spatial Structure)
Die räumliche Gliederung von Gebäuden wird mit folgenden Klassen modelliert:
wesentl. Klassen
IfcSite
IfcBuilding
IfcBuildingStorey
IfcSpace
IfcZone
Property Sets
interne Beziehungen
hierarchische
Dekomposition:
IfcRelAggregates
Zonierung:
IfcRelGroups
Definition:
IfcRelDefinesByProperties
externe Beziehungen
räumlicher Einschluss:
IfcRelContainedInSpatialStructure
Zuordnung versorgender Systeme:
IfcRelServicesBuildings
Raumabschluss:
IfcRelSpaceBoundary
Siehe [4] Kapitel 10 für weitere Information über die räumliche Gliederung.
Für das Holzbau-Modell sind IfcSite, IfcBuilding, IfcBuildingStorey, IfcRelAggregates die relevantesten Klassen der räumlichen Struktur, und IfcRelContainedInSpatialStructure ist deren wichtigste Beziehung zu anderen Teilmodellen.
Folgende Konventionen gelten für Platzierungen IfcObjectPlacement von Produkten
(d.h. von Elementen der Raumstruktur, von Bauelementen u.a.), d.h. für ihre lokalen
Koordinatensysteme:
• Wenn Produkt A ein Teil von Produkt B oder eine Öffnung, Füllung oder
Bedeckung (Verschalung) von B ist, so soll A relativ zur Platzierung von B
platziert werden. D.h. der Ort von A im Bauwerk wird in lokalen
Koordinaten von B angegeben.
• Wenn Produkt B räumlich im Raumstruktur-Element C enthalten ist, so soll
B relativ zur Platzierung von C platziert werden. D.h. der Ort von B wird in
lokalen Koordinaten von C angegeben.
Alternativ können Produkte relativ zu Schnittpunkten von Raster-Achsen platziert
werden. Raster bestehen aus Instanzen von IfcGrid, IfcGridAxis und zugehöriger
Ressourcen-Objekte.
30
2.4.2 Allgemeine (gemeinsame) Bauelemente
Neben anderen Klassen symbolisieren folgende Klassen den Rohbau oder ein Grobmodell der physischen Bauwerkselemente, d.h. die wesentlichen lastabtragenden und
raumabschließenden Elemente:
wesentliche Klassen
IfcRoof
IfcSlab
IfcWall
IfcWallStandardCase
IfcColumn
IfcBeam
interne Beziehungen
Materialzuweisung:
IfcRelAssociatesMaterial
IfcOpeningElement
Schaffung von Öffnungen:
IfcRelVoidsElement
IfcStair
IfcStairFlight
IfcRamp
Property Sets,
Materialien,
Materialschichten
externe Beziehungen
Element-Verbindungen:
Raumabschluss:
IfcRelConnectsElements
IfcRelConnectsPathElements IfcRelSpaceBoundary
Klassifikation:
IfcRelAssociatesClassification
Zuordnung zu Produkten
in anderen Kontexten
(z.B. Konstruktions- oder
Statik-Kontexten):
IfcRelAssignsToProduct
Definition:
Siehe [4] Kapitel 11 zur Implementierung der gemeinsam — d.h. interdisziplinär —
genutzten Bauelement-Klassen. Ein Beispiel zu Beziehungen zwischen Bauelementen
im Konstruktions-Kontext und dem „gemeinsamen“ Kontext ist in [5] Abschnitt 3.8
enthalten.
Die Vereinigungsmenge von räumlicher Struktur und den allgemeinen, interdisziplinär verwendeten Bauelementen nennt man auch „Koordinierungs-Modell“, da
Koordinierung von Planung und Bau vor allem an diesen Teilmodellen festgemacht
wird..
2.4.3 Das Architektur-Modell
ist eine Übermenge von räumlicher Gliederung und allgemeinen Bauelementen. Es
kommen zu den Klassen dieser Modelle noch die Klassen IfcDoor, IfcWindow,
IfcCovering, IfcCurtainWall (welche u.U. auch als gemeinsame Bauelemente
angesehen werden), IfcSpaceProgram, IfcVirtualElement, verschiedene Property Sets
und Beziehungsobjekte wie IfcRelFillsElement, IfcRelCoversBldgElements, IfcRelInteractionRequirements hinzu. Sie werden durch zahlreiche Klassen der RessourcenEbene zur Beschreibung von Nutzungen, Mengen, Brandabschnitten und Fluchtwegen, Erscheinung und Präsentation usw. ergänzt.
31
2.4.4 Haustechnik-Systeme
also elektrische Netzwerke, Heizung, Lüftung und sanitäre Systeme werden mittels
zahlreicher Unterklassen von IfcDistributionElement, IfcDistributionElementType
usw. modelliert:
wesentliche Klassen
Untertypen von
IfcDistributionElement(Type)
IfcDistributionPort
IfcTransportElement(Type)
IfcElementComponent(Type)
IfcPerformanceHistory
Property Sets
interne Beziehungen
IfcRelConnectsWithRealizingElements
IfcRelConnectsPortToElement
IfcRelConnectsPorts
Dekomposition, Gruppierung:
IfcRelAggregates
IfcRelNests
IfcRelAssignsToGroup
externe Beziehungen
Zuordnung zu versorgten Bereichen der
räumlichen Struktur:
Zuweisung von Leistungsdaten:
IfcRelAssignsToControl
Klassifikation:
Definition:
IfcRelDefinesByType
Siehe [4] Kapitel 12 zu Implementierungsfragen der Haustechnik-Teilmodelle.
2.4.5 Statische Berechnungsmodelle
Es existieren zwei Grundkonzepte für die Abbildung statische Berechnungsmodelle
in IFC:
• ausschließlicher Gebrauch von Klassen des IfcStructuralAnalysisDomainSchema und entsprechender Ressourcen-Schemata, oder
• gemischter Gebrauch von allgemeinen Bauelement-Klassen zusammen mit
Klassen aus der Statik-Domäne.
Ersteres ist der Weg, wie er von den Autoren der Statik-Erweiterungen zu IFC
vorgesehen wurde und in der folgenden Tabelle wiedergegeben wird. Letztere
Variante wird seit Beginn der Implementierungen in der Statik-Domäne als Alternative angesehen. Dieser Weg ist allerdings nur bei einfachen Modelleigenschaften
gangbar.
32
wesentliche Klassen
Untertypen von
IfcStructural~
~Member
~Connection
~Action
~Reaction
interne Beziehungen
Material- und Profil-Zuweisung:
IfcRelAssociatesProfileProperties
IfcStructural~
~AnalysisModel
~LoadGroup
~ResultGroup
Aufbringen von Einwirkungen:
IfcRelConnectsStructuralAction
Property Sets,
Materialien
Definition:
IfcRelConnectsStructuralMember
Gruppierung:
externe Beziehungen
(z.B. Koordinierungsoder KonstruktionsKontexten):
Zuordnung zu Bereichen
der räumlichen Struktur:
Siehe [6] für Implementierungsdetails statischer Berechnungsmodelle.
2.4.6 Konstruktionsmodell
Das Konstruktions- oder Detaillierungsmodell wird hier nur vom Standpunkt des
Holzbaus besprochen. Ähnliche Konzepte werden auch für die Modellierung von
Stahl- und Massivbauten angewandt.
Ähnlich zur Statik-Domäne wurden auch hier zwei etwas verschiedene Modellkonzepte von Teilnehmern des IAI-Projekts ST-5 vorgeschlagen:
• ausgiebige Weiterverwendung von Klassen des Teilmodells allgemeiner
Bauelemente — also IfcBeam, IfcColumn, IfcWall, IfcSlab, IfcCovering —
zusätzlich zu Klassen des Ingenieur- bzw. Konstruktionsbereichs, oder
• ausschließlicher Gebrauch von Klassen der Ingenieur- bzw. Konstruktionsbereichs wie z.B. IfcMember und IfcElementAssembly.
Ersterer Weg wurde auch von den Autoren der Massivbau-Domäne von IFC vorgesehen. Die unten stehende Tabelle ist daran ausgerichtet.
Der letztere Weg wurde mit der Absicht vorgeschlagen, Teilmodelle auf einfache
Weise unterscheiden zu können. IFC-Importschnittstellen sollten in der Lage sein, das
Koordinationsmodell oder das Detailkonstruktionsmodell selektiv zu lesen. Das ist
beispielsweise erforderlich für automatisierte Modellprüfung (z.B. bei Tests auf
überschneidende Bauteilvolumina), Mengenermittlung, Verfolgung von Planungsänderungen usw.. Allerdings wird dieses Modellkonzept nicht gut anwendbar sein,
wenn solche Teilmodell-Abgrenzungen nicht möglich oder nicht erwünscht sind.
Außerdem sind Teilmodelle eventuell auch mit anderen Mitteln unterscheidbar, z.B.
durch Abfrage des erzeugenden Akteurs von Objekten.
Ein weiterer Grund, IfcMember anstatt IfcBeam und IfcColumn zu verwenden, ist die
Schwierigkeit, in einem CAD-Programm mit grafischer Bauteileingabe festzustellen,
ob ein Bauteil stabförmig, plattenförmig o. dgl. ist.
Die Frage, ob IfcWall und IfcSlab oder statt dessen IfcElementAssembly verwendet
werden sollte, stellt sich nur bei der Planung vorgefertigter Elemente. Wände und
Decken, die traditionell auf der Baustelle gefertigt werden (also keine Baugruppen im
eigentlichen Sinne sind), werden als IfcWall und IfcSlab modelliert.
wesentliche Klassen
einzelne Bauteile:
IfcColumn
IfcBeam
IfcMember(Type)
interne Beziehungen
Material-Zuweisung:
Verbindungen:
IfcRelConnects(WithRealizing)Elements
IfcRelCoversBldgElements
(IfcRelAggregates)
Baugruppen:
IfcSlab
IfcWall(StandardCase)
IfcBuildingElementPart
hierarchische Dekomposition:
IfcCovering(Type)
IfcRelAggregates
IfcElementAssembly
Verbindungsmittel und Gruppierung:
Beschläge:
Ifc(Mechanical)Fastener(Type)
IfcDiscreteAccessory(Type)
Property Sets,
Materialien
Klassifikation:
IfcRelAssociatesDocument
33
externe Beziehungen
(z.B. Koordinierungsoder Statik-Kontexten):
Dekomposition von
Produkten im Koordinierungsmodell (in einfachen
Fällen in situ gefertigter
Konstruktionen):
IfcRelAggregates
Definition:
IfcRelDefinesByType
Siehe folgende Kapitel dieses Dokuments für weitere Information über Detaillierung
von Holzkonstruktionen. Ein Implementierungs-Handbuch für Stahlbauten existiert
im Moment noch nicht. Modellierung von Betonkonstruktionen wird in [5] beschrieben.
2.4.7 Weitere Systeme und Modelle
sind zum Beispiel Bauablaufpläne, Kostenmodelle und Modelle im Facilities Management.
2.5 Typ-Objekte und eingefügte Objekte
(Occurrences)
2.5.1 Was ist ein Typ? Was ist ein eingefügtes Objekt?
Kurze Erklärungen der Begriffe „type object“ und „occurrence object“ wurden schon
in „Teil II: Klassen-Referenz“ Abschnitt 2.2.3 gegeben. Hier ist eine alternative
Beschreibung:
• Ein Typ ist „wie ein Ding ist“, seine Erscheinung. Es ist seine Form, sein
Material, Gewicht, Farbe und so weiter.
• Ein eingefügtes Objekt ist „was ein Ding tut“. Ein Bauelement zum Beispiel
„tut“ folgendes: Es befindet sich irgendwo im Bauwerk, hält Verbindungen
mit anderen Elementen, trägt Lasten, begrenzt Räume.
34
2.5.2 Exkurs über Typ-Objekte und eingefügte Objekte in IFC
Das Konzept von Typ-Objekten wurde mit der IFC-Fassung 2x eingeführt. Es ist kein
ursprüngliches, jetzt aber fundamentales Konzept der IFC-Plattform. Eine noch
verbleibende Einschränkung in IFC ist, dass Typ-Objekte ebenso wie eingefügte
Objekte eigentlich immer nur für einen einzigen Zeitpunkt beschrieben werden
können. Für gewöhnlich bezieht sich ein IFC-Gebäudemodell auf den Zeitpunkt,
nachdem das Gebäude errichtet oder in Gebrauch genommen wurde. Das HolzbauModell lockert diese Begrenzung etwas. Es erlaubt bei Typ-Objekten die Angabe von
Bauteilformen zu unterschiedlichen Zeitpunkten, und zwar vor und nach Bearbeitung.
Typ-Klassen (Unterklassen von IfcTypeProduct) werden in IFC als Gegenstücke zu
fast allen Occurrence-Klassen von Produkten (Unterklassen von IfcProduct) definiert.
Information über ein Produkt kann somit auf Information, die im eingefügten Objekt
enthalten ist, und Information, die im Typ-Objekt enthalten ist, aufgeteilt werden.
Aus verschiedenen Gründen gibt es hierbei keine einheitliche Vorgehensweise in
IFC. Manchmal enthalten Occurrence-Objekte Information, die in Typ-Objekte verlagert werden könnte; oder manchmal werden Typ-Objekte in Widerspruch zu dem in
Abschnitt 2.5.1 aufgestellten Prinzip verwendet (z.B. zur Bezeichnung der Funktion
eines Bauteils). Übrigens werden im IFC 2x Coordination View (den gegenwärtig
gültigen Implementierungs- und Zertifizierungsregeln für den Austausch der
Teilmodelle räumliche Gliederung und allgemeine Bauelemente) keinerlei TypKlassen berücksichtigt. Ferner arbeitet die IfcStructuralAnalysisDomain von IFC 2x2
komplett ohne das Konzept der Typ-Objekte.
Die erste Domäne, die Typ-Objekte extensiv verwendet, ist die Haustechnik-Domäne.
Diese Domäne definiert sogar erheblich zahlreichere spezialisierte Typ-Klassen als
Occurrence-Klassen. Erläuterungen zum Gebrauch von Typen und eingefügten
Objekten in Haustechnik-Teilmodellen finden sich in [4] Kapitel 12. In der Massivbaudomäne spielen Typ-Objekte nur eine untergeordnete Rolle. Zum Beispiel wird
dort die Untergliederung einer Schalform mittels Feature-Elementen auf OccurrenceEbene realisiert [3], [5]. Solche Formfeatures sind deshalb in der Lage „etwas zu tun“
— im Gegensatz zu Formfeatures von Holzbauteilen, die lediglich Teil eines Typobjekts sind.
2.5.3 Typ-Objekte und eingefügte Objekte im Holzbau-Modell
Das Holzbaukonstruktions- und Detaillierungsmodell verwendet Typ-Objekte ausgiebig und systematisch. Die folgenden einfachen Regeln sind anwendbar:
• Alle zusammengesetzten Produkte wie z.B. Wandtafeln oder Dachbinder
verwenden nur eingefügte Objekte.
• Alle einteiligen Produkte wie z.B. Holzbalken, OSB-Platten, Beschläge
und Verbindungsmittel verwenden Typ-Objekte + eingefügte Objekte.
• Die Rollenaufteilung zwischen Typ-Objekten und eingefügten Objekten ist
in Abb. 2-21 beschrieben.
Kurzgefasst: Ein Typ-Objekt trägt die komplette Information bezüglich der Konfiguration eines Produkts, besonders Form und Material. Ein eingefügtes Objekt trägt nur
Information über Platzierung eines Produkts im Gebäude und alle weitere ortsabhängige Information, z.B. Verbindungen. Allein eingefügte Objekte gehen Beziehungen über Teilmodellgrenzen hinweg ein.
Abb. 2-21
Rollen von Typen und Occurrences im Holzbaumodell
Klassen
Aufgaben
Typen
komplette Konfiguration, insbesondere
IfcMemberType
IfcFastenerType
IfcDiscreteAccessoryType
• komplette Form und andere geometrische Daten
mittels angefügter Instanzen von IfcRepresentationMap
• Material-Zuweisung
mittels IfcRelAssociatesMaterial
• Fertigungs-Positionierung (Positionsnummer)
mittels Tag-Attribut
• Typ-Bezeichnung
mittels ElementType- oder PredefinedType-Attribut
• Typ-Klassifikation
mittels IfcRelAssociatesClassification
• Anfügen von Property Sets, welche für alle vom TypObjekt beschriebenen Occurrences gelten (z.B. Gewicht
pro Stück, Qualitätsanforderungen)
mittels HasPropertySets-Attribut
Occurrences
IfcMember
IfcBeam
IfcColumn
Ort und Verbindungen, insbesondere
• Ort (Platzierung)
mittels ObjectPlacement-Attribut
• physische Verbindungen
mittels IfcRelConnects(WithRealizing)Elements
IfcFastener
• logische Verbindungen, Dekomposition
mittels IfcRelAggregates
IfcDiscreteAccessory
• Gruppierung
mittels IfcRelAssignsToGroup
• ortsbezogene Klassifizierung
mittels IfcRelAssociatesClassification
• Anfügen von Property Sets, welche nur für ein einzelnes
eingefügtes Objekt gelten (d.h. ortsabhängige
Eigenschaften, z.B. Umweltklassen)
mittels IfcRelDefinesByProperties
externe Beziehungen zu anderen Teilmodellen, insbesondere
• räumlicher Einschluss
mittels IfcRelContainedInSpatialStructure
• Zuordnung zu Produkten in anderen Kontexten
(z.B. allgemeinen Bauelementen)
mittels IfcRelAssignsToProduct
• Zuweisung zu Prozessen, Akteuren, Verläufen
mittels IfcRelAssignsToProcess, ~Actor, ~Control
35
36
Es werden einige weitere Regeln bezüglich der in Abb. 2-21 genannten OccurrenceKlassen (eingefügte Objekte einteiliger Produkte) vorgeschlagen:
• Definition durch ein entsprechendes Typ-Objekt ist Pflicht.
• Als einziger Typ der geometrischen Repräsentation wird „mapped
representation“ zugelassen. Der kartesische Transformations-Operator der
IfcMappedItems ist auf Identität einzuschränken.
• Wenn ein Typ-Objekt mehrere Repräsentations-Quellen (representation
maps) für verschiedene Formaspekte mitbringt, so ist es meist ausreichend,
nur die ‚body’-Repräsentation per IfcMappedItem bei den eingefügten
Objekten wiederzugeben. Anwendungen in der Holzbaudomäne sollten
bereits aus der logischen Beziehung zwischen Typ und eingefügten
Objekten schlussfolgern, dass alle Formaspekte des Typs auch auf die
eingefügten Objekte zutreffen.
3 Beispiele
37
3 Beispiele
3.1 Ein einfaches Dachtragwerk
3.1.1 Objekte für die einzelnen Bauteile
Das folgende Beispiel zeigt Hauptbauteiles eines symmetrischen Satteldaches. Das
Tragwerk besteht aus 30 Sparren, 2 Traufpfetten, 1 Firstpfette und 1 Stiel. Die
Traufpfetten bestehen aus je drei Kanthölzern, die Traufpfette aus zwei Kanthölzern.
Die Firstpfette P1 liegt auf Stiel C1 auf.
Abb. 3-1
Beispiel eines Daches: Grundriss und Schnitt
P2 120x120
P2
R1 80x200
alle 800mm
P1 120x240
Gelenk
P2
C1
C1 120x120
P2 120x120
R1
P2
Alle diese Bauteile könnten als IfcMember + IfcMemberType modelliert werden,
jedoch werden hier die etwas aussagekräftigeren Klassen IfcBeam/ IfcColumn +
IfcMemberType gewählt. Es wird insgesamt 30 + 6 + 2 = 38 Instanzen von IfcBeam
und 1 Instanz von IfcColumn geben. Diese Objekte enthalten die genaue Platzierung
jedes Bauteils.
Form und Material der Bauteile werden mit Instanzen von IfcMemberType wiedergegeben, die mit den entsprechenden IfcBeam und IfcColumn über IfcRelDefinesByType
verknüpft werden. Es werden also 1 Instanz von IfcMemberType mit PredefinedType
= RAFTER benötigt (da alle Sparren dieselbe Form und dasselbe Material besitzen),
3 Instanzen von IfcMemberType mit PredefinedType = PURLIN (1 für die
Traufpfetten, 2 für die zwei unterschiedlich geformten Teile der Firstpfette), sowie 1
Instanz von IfcMemberType mit PredefinedType = POST. Die 5 Typen benötigen 5
Instanzen von of IfcRelDefinesByType.
38
Abb. 3-2
Eingefügte Bauteile und Typen im Modell des Daches17
IfcBeam
IfcBeam
IfcLocalPlcmt.
IfcBeam
IfcBeam
IfcLocalPlacement
IfcLocalPlcmt.
IfcLocalPlcmt.
IfcBeam
IfcLocalPlcmt.
...30 IfcBeam
insgesamt
IfcBeam
IfcRelDefinesByType
IfcLocalPlacement
IfcBeam
IfcMemberType
IfcLocalPlacement
PredefinedType=PURLIN
Tag=’P1a’
...6 IfcBeam
insgesamt
IfcColumn
...
...
IfcBeam
IfcLocalPlcmt.
IfcLocalPlcmt.
IfcRelDefinesByType
IfcRelDefinesByType
IfcRelDefinesByType
IfcRelDefinesByType
IfcMemberType
IfcMemberType
IfcMemberType
IfcMemberType
PredefinedType=RAFTER
Tag=’R1’
Tag=’P1b’
Tag=’P2’
PredefinedType=POST
Tag=’C1’
Sämtliche Objekte in der obigen Abbildung — außer IfcLocalPlacement — besitzen
Attribute GlobalID and OwnerHistory. GlobalID sind einmalig vergebene, in
Zeichenketten verpackte Nummern, während OwnerHistory auf Instanzen von
IfcOwnerHistory-Objekten zeigen. Falls alle Objekte zur selben Zeit erzeugt oder
modifiziert wurden, sollten sie sämtlich auf dieselbe IfcOwnerHistory verweisen.
Abb. 3-3
Versionskennzeichnung (owner history)18
IfcOwnerHistory
CreationDate=1098352702
IfcApplication
IfcOrganization
IfcPersonAndOrganization
IfcOrganization
IfcPerson
IfcBeam
IfcLocalPlacement
IfcBeam
IfcLocalPlacement
IfcRelDefinesByType
IfcMemberType
3.1.2 Beziehungs-Objekte, Verbindungen, Materialien
Die Klasse IfcRelDefinesByType wurde schon als Beziehung eingeführt, die eingefügte Objekte und Typ-Objekte verknüpft. Beziehungs-Objekte werden auch für das
Anfügen von Materialien und anderen Eigenschaften sowie zur Modellierung von
Verbindungen (Anschlüssen) benutzt.
Verbindungen
Ansatzweise Information über Verbindungen kann mittels IfcRelConnectsElements
übergeben werden. Jede Instanz dieser Klasse verbindet genau zwei Bauteil-Objekte.
Im vorliegenden Beispiel könnten
• 1 Verbindung zwischen Firstpfette und Pfosten,
17
18
Alternativ könnten IfcMember statt IfcBeam und IfcColumn verwendet werden.
Es sind nur Pflichtattribute von IfcOwnerHistory bezüglich Erzeugung der Objekte dargestellt.
Weitere optionale Attribute sind zu besetzen, wenn Versionskennzeichnungen geänderter Objekte
vorgenommen werden sollen.
3 Beispiele
39
• 1 Verbindung zwischen den beiden Teilen der Firstpfette (am GerberGelenk),
• 2 Verbindungen jedes Sparrens mit entsprechenden Pfetten, d.h. 60
derartiger Verbindungen
vorhanden sein. Enthielte das Modell zusätzlich Objekte für die Verbindungsmittel,
so würde die Klasse IfcRelConnectsWithRealizingElements anstelle von IfcRelConnectsElements verwendet werden. Dieses Beziehungsobjekt verweist zusätzlich
auf Hilfselemente, die zur physischen Realisierung der Verbindung erforderlich sind,
vor allem IfcFastener. Zu solchen eingefügten Verbinder-Objekten gehören wieder
eigene Verbinder-Typ-Objekte, vor allem IfcMechanicalFastenerType, die natürlich
mit IfcRelDefinesByType den eingefügten Objekten zugeordnet werden.
Abb. 3-4
Verbindungs-Beziehungen (optional)19
IfcBeam P1b
IfcBeam R1
IfcBeam R1
IfcBeam P1a
IfcFastener
IfcRelCon.El.
IfcRelDefinesByType
IfcBeam P2
IfcBeam P2
IfcColumn C1
Die hier beispielhaft vorgestellte Dachkonstruktion rechtfertigt kaum, die Verbindungen explizit zu modellieren. Diese Information tatsächlich im Modell niederzulegen, könnte eventuell in folgenden Situationen nützlich sein:
• Aus einem existierendem Konstruktionsmodell soll ein statisches
Berechnungsmodell abgeleitet werden.
• Verbindungen sollen numerisch gesteuert vorgefertigt werden.
Material-Zuweisung
Eine weitere, sehr häufig benötigte Beziehung ist IfcRelAssociatesMaterial. Sämtliche Bauteile des Beispiels sollen aus demselben Material bestehen, also werden
insgesamt auch nur eine Instanz von IfcMaterial und von IfcRelAssociatesMaterial
benötigt. Die Assoziations-Beziehung zeigt auf Instanzen von IfcMemberType.20
Die nächste Abbildung zeigt, wie weitere Eigenschaften an das Material-Objekt
angehangen werden können oder wie man alternativ das Material näher mittels
Klassifikation beschreibt. Man beachte, dass IFC zwar mehrere Property Sets pro
Material erlaubt, aber höchstens eine Klassifikation. Der einfachste Fall wäre
natürlich, dass nur ein Material mit seinem Namen angegeben wird. Dies ist allerdings problematisch, da in der Praxis je nach Situation verschiedene Materialbezeichnungen verwendet werden.
19
20
Es sind nur zwei zu den Positionen R1 und P2 gehörige IfcBeam dargestellt.
Anstatt zu Typ-Objekten könnte des Material auch mit den eingefügten Objekten IfcBeam und
IfcColumn assoziiert werden; und dies wird auch im IFC-Koordinations-Modell so gehandhabt. Getreu
der Konvention in Abschnitt 2.5.3 werden aber im Holzbau-Konstruktions-Modell Materialien immer
den Typen zugeordnet (ausgenommen zusammengesetzte Elemente.
40
Abb. 3-5
Material-Zuweisung
IfcMaterial
IfcExtendedMaterialProperties
Name=’quality’
IfcPropertySingleValue
Name=’Species’
NominalValue=IfcLabel(’spruce’)
Name=’StrengthGrade’
NominalValue=IfcLabel(’S 10’)
entweder
Name=’timber’
Material-Spezifikation durch
Angabe der Eigenschaften
IfcMaterialClassificationRelationship
IfcClassificationReference
ItemReference=
’BTK=03.VHKASR;HZA=FI;SKL=10’
IfcClassification
Source=’DGfH’
Name=’BTK’ Edition=’1.0’
oder
IfcMemberType
Tag=’R1’
IfcMemberType
Tag=’P1a’
IfcMemberType
Tag=’P1b’
IfcMemberType
Tag=’P2’
IfcMemberType
Tag=’C1’
Material-Spezifikation
durch Klassifikation
Anfügen weiterer Bauteil-Eigenschaften
Zuletzt soll hier eine weitere im gesamten IFC-Modell verwendete Beziehung gezeigt
werden: Definition über Property Sets. Während Property Sets direkt an Typ-Objekte
wie IfcMemberType als deren Attribut angehangen werden können, können sie auch
mit eingefügten Objekten wie IfcBeam per IfcRelDefinesByProperties in Beziehung
gebracht werden.
Abb. 3-6
Kennzeichnung eines Bauteils als tragend mittels Property Set
IfcPropertySet
...
Name=’LoadBearing’
NominalValue=IfcBoolean(.T.)
IfcBeam R1
IfcBeam P2
IfcColumn C1
IfcBeam R1
IfcBeam P2
IfcBeam P1a
IfcBeam R1
IfcBeam P2
IfcBeam P1b
...
...
Name=’Pset_MemberCommon’
Im obigen Beispiel wurde die Eigenschaft ‚LoadBearing’ an eingefügte Objekte —
und nicht an Typ-Objekte — vergeben. Dies hat zwei Gründe:
• Property Sets, die an ein Typ-Objekt angefügt werden, dürfen nicht zugleich
von einem weiteren Typ-Objekt verwendet werden. Würde man also die
Eigenschaft ‚LoadBearing’ an die Typ-Objekte vergeben, so bräuchte man
im vorliegenden Beispiel 4 Instanzen desselben Property Sets, um den
gleichen Effekt zu erreichen.
• Eingefügte Objekte ein und desselben Typs könnten sowohl lastabtragend
als auch nichttragend eingebaut werden, abhängig von ihrer Anordnung im
Bauwerk. Es handelt sich also um eine Eigenschaft der eingefügten Objekte,
nicht der Typen.21
Übrigens werden die Beziehungs-Objekte und Property Sets, da sie Untertypen von
IfcRoot sind, auch wieder mit GUIDs und Versionskennzeichnung versehen.
21
In vorliegenden Beispiel sind freilich alle Bauteile tragend.
3 Beispiele
41
3.1.3 Beziehungen zu anderen Teilmodellen
Einordnung in die räumliche Struktur, geometrische Platzierung
IfcProject
IfcRelAggregates
IfcBeam
IfcLocalPlacement
IfcRelAggregates
IfcBeam
IfcLocalPlacement
(Welt-Koordinaten)
IfcLocalPlacement
IfcBeam
IfcBuilding
IfcRelAggregates
IfcLocalPlacement
IfcLocalPlacement
...
Teilmodell: räumliche Struktur
IfcSite
IfcColumn
IfcBuildingStorey
IfcLocalPlacement
Name=’ground floor’
IfcBuildingStorey
Teilmodell: Konstruktion
Abb. 3-7
Name=’attic’
IfcLocalPlacement
Sofern die IFC-Daten ein Teilmodell der räumlichen Struktur enthalten, so treten
Element des Konstruktionsmodells per IfcRelContainedInSpatialStructure zu dieser
in Beziehung. Üblicherweise stellen Geschosse (IfcBuildingStorey) Container für
Bauelemente dar.
Die Platzierung jedes Elements bezieht sich auf diejenige seines räumlichen Containers.22 In anderen Worten, die Koordinaten eines Elements werden relativ zum
lokalen Koordinatensystem des jeweiligen räumlichen Struktur-Elements gebildet.
Auf lokale relative Platzierung wird auch im nächsten Abschnitt und [4] Abschnitt
3.2.1 eingegangen.
...
IfcBeam R1
IfcBeam R1
IfcBeam R1
IfcBeam P1b
IfcBeam P2
IfcBeam P2
IfcRoof
IfcRelAggregates
Teilmodell:
Konstruktion
Teilmodell:
allgem. Bauelemente
IfcRelCont.InSpatialStr.
IfcBeam R1
IfcBeam P1a
IfcColumn C1
...
IfcBuildingStorey
Name=’Dachgeschoss’
...
Beziehungen zwischen Konstruktion und Architektur (optional)
...
räumliche
Struktur
Abb. 3-8
Name=’View’
IfcSlab
Name=’View’
IfcSlab
Name=’View’
Zusätzlich können Beziehungen zum Teilmodell allgemeiner „gemeinsamer“ Bauelemente (dem Architektur- oder Koordinationsmodell, d.h. Wände, Decken, Dächer
usw.) hergestellt werden. Bei manchen Bauwerken kann dazu IfcRelAggregates
angebracht sein. Aber in den meisten Fällen ist IfcRelAssignsToProduct besser
geeignet. Siehe auch [5] Abschnitte 2.4.1 und 3.8.
22
Ausnahme von dieser Regel sind Bauteile, die Teil einer Baugruppe sind. Die Platzierung der Teile
beziehe sich auf diejenige der Baugruppe.
42
Beziehungen zwischen Bauteilen im Konstruktionsmodell und Elementen im
statischen Berechnungsmodell können durch IfcRelAssignsToProduct mit Name =
‚Context’ festgehalten werden. Siehe [6] Abschnitt 3.1.
3.1.4 Platzierung und Formen der Bauteile
Geometrische Repräsentationen eingefügter Objekte
Allen Balken und dem Stiel werden Repräsentationen ihrer Körper mitgegeben. Vereinbarungsgemäß beschränke man sich hierbei auf „mapped representation“ mit
einigen Einschränkungen, vgl. Abschnitt 2.3.7. Die eigentliche Repräsentation wird
vom „mapped item“ aus über einen Verweis auf eine „representation map“ erreicht.
Das tatsächliche geometrische Modell jedes Bauteils wird nämlich den Typ-Objekten
zugeordnet. Da im Beispiel 39 eingefügte Bauteile, aber nur 5 Typen enthalten sind,
hilft der Mapping-Mechanismus, redundante Geometrieobjekte zu vermeiden.
Die aus „mapped items“ bestehenden Repräsentationen der eingefügten Bauteile sind
für Holzbau-Programme eigentlich nicht von Bedeutung, denn es bestehen ja schon
die logischen Beziehungen zu den Typ-Objekten über IfcRelDefinesByType. HolzbauProgramme können auch über diese Beziehung die Bauteilform rekonstruieren. Die
„mapped items“ sind lediglich eine Hilfe für Programme aus anderen Fachbereichen,
die dadurch in die Lage versetzt werden, Bauteilformen ohne Zugriff auf Typ-Objekte
erfassen zu können.
Abb. 3-9
Geometrische Produktdefinition eingefügter Bauteilen (empfohlen)
IfcRelDefinesByType
IfcProject
IfcBeam, IfcColumn
IfcMemberType
IfcLocalPlacement
Rep.Type=’MappedRepresentation’
Rep.Identifier=’Body’
IfcMappedItem
IfcAxis2Placement3D
IfcCartesianPoint
Coordinates=(0,0,0)
... (geometric model)
Scale=$
Es ist auch erlaubt, Produkt-Instanzen mit Platzierung, jedoch ohne Repräsentation
der Form im Modell abzulegen23. Demzufolge ist die hier gezeigte „mapped representation“ in der Tat optional, aber zwecks fachübergreifender Interoperation stark zu
empfehlen.
Lokale Platzierungen eingefügter Bauteile
1.) Lokale Koordinaten von Bauteilen:
Wie später noch für die geometrischen Repräsentationen der verschiedenen Bauteiltypen erklärt wird, sollten geometrische Modelle stabförmiger Bauteile wie folgt
orientiert werden:
23
oder Produkt-Instanzen sowohl ohne Platzierung als auch ohne Repräsentation
3 Beispiele
43
• Die lokale xy-Ebene enthält den Querschnitt des Bauteils. Die lokale zAchse verläuft in Längsrichtung des Körpers.
• Die lokale z-Achse befindet sich zentrisch im Körper. z=0 liegt an einem
Ende und z=l am anderen Ende des Körpers. Dabei ist l die Brutto-Länge.
Wenn a die Breite und b die Querschnittshöhe ist, so ist der Körper in ( –a/2
≤ x ≤ +a/2, –b/2 ≤ y ≤ +b/2, 0 ≤ z ≤ +l ) enthalten.
Ein Beispiel wird in Abb. 3-11 gezeigt.
D.h.: Für einfache balkenartige Bauteile wird vereinbart, dass die z-Achse der
Bauteilkoordinaten der Bauteil-Längsachse entspricht.
2.) Weltkoordinaten:
Die globale xy-Ebene liegt im Grundriss. Die globale z-Achse weist aufwärts.
3.) Lokale Koordinaten der räumlichen Bauwerks-Struktur:
Einige oder alle der Klassen IfcSite, IfcBuilding, IfcBuildingStorey können in einem
Projektmodell enthalten sein. Falls vorhanden, wird IfcSite in den Weltkoordinaten
des Projekts platziert.24 Die Lokalen Koordinaten von IfcBuilding beziehen sich auf
IfcSite, sofern vorhanden, und können gegenüber diesen verschoben sein, sollten aber
nicht gedreht sein. Die lokalen Koordinaten von IfcBuildingStorey beziehen sich auf
diejenigen von IfcBuilding und sind gegenüber diesen in z-Richtung versetzt oder
identisch.
Somit befindet sich die lokale xy-Ebene jedes Elements der räumlichen Struktur im
Grundriss des Elements, und die lokale z-Achse weist aufwärts.
Abb. 3-10
Lokale relative Platzierungen: Beispiel üblicher Praxis
IfcAxis2Placement3D.Axis
= Orientierung der Bauteil-z-Achse
z
Geschoss-Koordinaten, relativ
y
zum Gebäude, in z verschoben
Gebäude-Koordinaten
relativ zum Grundstück
nicht verschoben
Grundstücks-Koordinaten
relativ zur “Welt”
nicht verschoben
“Welt”-Koordinaten
y
x
x
z
Bauteil-Koordinatensystem
relativ zum Geschoss
verschoben in x,y,z und gedreht
IfcAxis2Placement3D.RefDirection
= Orientierung der Bauteil-x-Achse
z
y
IfcAxis2Placement3D.Location
= Geschosskoordinaten des Bauteil-Ursprungs
x
Bauwerkskoordinaten des Geschoss-Ursprungs
4.) Lokale Platzierungen von Bauteilen:
Gemäß disziplin-übergreifender Vereinbarung in IFC wird der Bauteil-Koordinatenursprung auf den Koordinatenursprung desjenigen IfcSpatialStructureElement bezogen, der Behälter des Bauteils ist.25 Die Instanzen von IfcLocalPlacement beinhalten
• einen Verweis auf die Platzierung des räumlichen Containers und ein
IfcAxis2Placement3D mit
24
außer bei zusammengesetzten Grundstücken, wo die Teile relativ zum Ganzen platziert werden
25
außer bei zusammengesetzten Bauteilen, wo die Teile relativ zum Ganzen platziert werden
44
• einem IfcCartesianPoint, der die Verschiebung vom Ursprung des
Containers zum Ursprung des Bauteils angibt,
• ein IfcDirection-Attribut (IfcAxis2Placement3D.Axis), das die Ausrichtung
der Bauteil-z-Achse anzeigt,
• ein IfcDirection-Attribut (IfcAxis2Placement3D.RefDirection), das die
Ausrichtung der Bauteil-x-Achse anzeigt.
In vorliegenden Beispiel sehen die Platzierungen der Bauteile wie folgt aus:
• Das IfcLocalPlacement des Stiels (IfcColumn) besteht nur aus einer
Translation.
• Die IfcLocalPlacement-Instanzen der diversen Pfetten (IfcBeam) benötigen
eine zusätzliche Rotation um ±90°. Die lokalen z-Achsen der Pfetten zeigen
hier in die x-Richtung des räumlichen Containers:
IfcAxis2Placement3D.Axis = (±1., 0., 0.).
• Die Sparren (IfcBeam) müssen um ±60° gedreht werden:
IfcAxis2Placement3D.Axis = (0., ±1., 0.57735).
Das optionale Attribut IfcAxis2Placement3D.RefDirection wird für zusätzliche
Rotation des Bauteilkörpers um seine z-Achse verwendet, soweit nötig.
3.1.5 Form des Typs für den Pfettenstiel
Der Körper des Stiels ist einfach nur ein Quader mit den Abmessungen 120mm ×
120mm × 3470mm. Wir verwenden einen Extrusionskörper als geometrisches
Modell. Dieser wird aus einem Profil erzeugt (welches zugleich der Querschnitt des
Stiels ist: 120mm im Quadrat), welches um eine bestimmte Länge extrudiert wird (die
zugleich die Länge bzw. Höhe des Stiels ist: 3470mm). Somit erlaubt das geometrische Modell nicht nur, den Stiel grafisch darzustellen, sondern auch direkt die für
Stücklisten benötigten Maße abzulesen.
Wie im folgenden Bild gezeigt, enthält das geometrische Modell einheitenlose Maße.
Die Einheit jeder Länge muss von der LENGTHUNIT abgefragt werden, die dem
IfcProject zugeordnet ist. Im Beispiel wurde als projektweite Längeneinheit mm
gewählt. Ein Holzbauprogramm, das ein bereits existierendes Projekt importiert,
sollte natürlich die darin vorgegebene LENGTHUNIT beibehalten.
Das Bild zeigt weiterhin, dass das geometrische Modell in einer IfcShapeRepresentation namens ‚Body’ enthalten ist.26 Die Repräsentation ist in einer IfcRepresentationMap enthalten, die vom IfcMappedItem in der Repräsentation des eingefügten
Objekts IfcColumn referenziert wird. Die IfcRepresentationMap enthält eine Platzierung, die der Ursprung der mit dem Mapping verbundenen kartesischen Transformation ist. Wir verwenden hier die einfachstmögliche Transformation (Identität),
lassen die beiden Richtungs-Attribute aus und setzen den Ursprung auf (0.,0.,0.).
Siehe auch Abschnitt 2.3.7.
26
Weitere Repräsentationen zu anderen Zwecken neben der ‚Body’-Repräsentation werden noch im
folgenden besprochen.
3 Beispiele
Geometriemodell des Stiel-Typs C1
IfcProject
IfcGeom.Rep.Context
IfcSIUnit
Tag=’C1’ PredefinedType=POST
IfcAxis2Placement3D
UnitType=LENGTHUNIT
Prefix=MILLI
Name=METRE
IfcUnit
RefDirection=$ Axis=$
RepresentationIdentifier=’Body’
IfcCartesianPoint
Länge
...
IfcUnit
Ursprung für
identische Abbildung
(Pflicht bei Holzbaukonstruktionen)
ProfileType=AREA
XDim=120.
Querschnitt YDim=120.
IfcAxis2Placement2D
RefDirection=$
IfcCartesianPoint
IfcDirection
Direc.Ratios=(0.,0.,1.)
IfcAxis2Placement3D
IfcCartesianPoint
identische Platzierung des
Profilkoordinatensystems
(sehr empfohlen)
Depth=3470.
orthogonale
Extrusion
(Pflicht bei Holzbaukonstruktionen)
Depth=3470
IfcUnitAssignment
IfcMemberType
X
= Dim
12
0
Abb. 3-11
45
identische Platzierung des Positionskoordinatensystems
x
des Bauteils (empfohlen)
z
Y
=1 Dim
20
y
Darüber hinaus enthält IfcExtrudedAreaSolid diverse weitere Richtungen und Koordinaten. Sie werden für schiefe Extrusion und gegenüber ihren Einfügekoordinaten
verschobene und gedrehte Körper benötigt. Auch hier beschränken wir uns auf das
Einfachste:
• Das IfcAxis2Placement2D in IfcRectangleProfileDef.Position soll keine
Rotation oder Translation des Profils bewirken. Das Profil verbleibt in
lokalen x/y-Richtungen orientiert und zentriert.
• Die IfcDirection in IfcExtrudedAreaSolid.ExtrudedDirection zeigt in lokale
z-Richtung. Dies stellt sicher, dass das Profil identisch mit dem Querschnitt
ist.
• Das IfcAxis2Placement3D in IfcExtrudedAreaSolid.Position soll den Körper
nicht drehen oder verschieben. Der Körper verbleibt in der lokalen zRichtung ausgerichtet und zur z-Achse zentriert.
Das Ergebnis ist also ein Quader mit einem lokalen Koordinatensystem, das sich wie
abgebildet im Mittelpunkt seiner unteren Stirnfläche befindet.
3.1.6 Form des Typs für die Traufpfetten
In unserem Beispiel sind die Traufpfetten P2 aus Balken des Querschnitts 120mm ×
120mm und der Länge 3780mm zusammengesetzt. Der Bauteiltyp wird geometrisch
genau wie der Stiel C1 modelliert, abgesehen vom Attribut IfcExtrudedAreaSolid.Depth = 3780. Da dies einen „aufwärts“ gerichteten Stab erzeugt (aus Sicht des Bauteilkoordinatensystems), werden die eingefügten Bauteil-Objekte der Pfetten P2
mittels IfcLocalPlacement in horizontale Richtung gedreht, wie zuvor erklärt.
3.1.7 Form des Typs für die Firstpfette: CSG und Features
Die Firstpfette ist in zwei Teile gestückelt, die über ein schräges Blatt als Gelenk
verbunden sind. Die außenliegenden Enden sind gefast. Die Form des Teils P1b
gleicht dem Teil P1a, außer das er kürzer ist und die Sägeschnitte für das Blatt
umgekehrt orientiert sind.
46
Abb. 3-12
Mögliche geometrische Modelle der Firstpfette P1a
y
Modellierungsvariante:
CSG
Minuend: quaderförmiges IfcExtrudedAreaSolid 140x240x6830
Subtrahend:
z
Subtrahend: IfcExtrudedAreaSolid
y
Clipping
Minuend: quaderförmiges IfcExtrudedAreaSolid 140x240x6830
z
Subtrahend: IfcPolygonalBoundedHalfSpace
y (±70,120,0)
Facette b
(±70,80,0)
Facette e
Facette a (Facette c)
z
B-Rep
(±70,-80,320)
Facette f
Facette g
(±70,-120,320)
Facette d
Subtrahend:
IfcHalfSpaceSolid
oder
IfcBoxedHalfSpace
(±70,120,6830)
Facette i
(±70,0,6830)
Facette h
(±70,-120,6710)
Mögliche geometrische Modelle
Verschiedene Möglichkeiten stehen offen:
• CSG: Die Rohform ist ein quaderförmiges IfcExtrudedAreaSolid. Zwei
weitere IfcExtrudedAreaSolids mit IfcArbitraryClosedProfileDef werden
davon abgezogen. Das Ergebnis ist ein IfcBooleanResult.
• Clipping: Die Rohform ist ein quaderförmiges IfcExtrudedAreaSolid. Zwei
IfcHalfspaceSolids werden davon abgezogen. Dabei muss für das Blatt ein
polygonal begrenzter Halbraum verwendet werden. Der Halbraum für die
Fase kann unbegrenzt oder durch eine Box begrenzt sein. Das Ergebnis ist
ein IfcBooleanClippingResult. Dies ist eine Sonderform der CSG.
• B-Rep: Die Endform wird als facettiertes Schalenmodell (IfcFacetedBrep)
abgelegt. Zusätzlich können Features als Flächenmodell (IfcShellBasedSurfaceModel) und der Rohkörper als IfcExtrudedAreaSolid hinterlegt
werden.
• Seitwärts-Extrusion als IfcArbitaryProfileDef.
Seitwärts-Extrusion wird hier nicht besprochen. B-Rep wird in Abschnitt 3.1.8
erläutert. Ein Beispiel für begrenztes Clipping ist in [4] Abschnitt 11.2.1.3 aufgeführt.
Wir wählen an dieser Stelle CSG.
Hinweis: Erlaubte bzw. vorzuziehende Varianten geometrischer Modellierung
werden in View-Definitionen oder Vereinbarungen der Implementoren
geregelt.
3 Beispiele
Abb. 3-13
47
Geometriemodell des Pfetten-Typs P1a unter Verwendung von CSG
IfcProject
IfcUnitAssignment
IfcSIUnit
UnitType=LENGTHUNIT
Prefix=MILLI
Name=METRE
IfcMemberType
IfcGeom.Rep.Context
IfcAxis2Placement3D
IfcCartesianPoint
RepresentationType=’CSG’
IfcUnit
Tag=’P1a’ PredefinedType=PURLIN
IfcBooleanResult
Seco
ndO
pera
nd
Operator=DIFFERENCE
per
...
and
IfcUnit
Firs
tO
Depth=150.
IfcDirection
Dir.Ratios=(0.,0.,1.)
IfcPolyline
IfcAxis2Placement3D
IfcDirection
IfcCartesianPoint
Axis
Dir.Ratios=(1.,0,.0.)
Coordinates=(0.,0.)
IfcDirection
IfcCartesianPoint
RefDir.
Coordinates=(0.,130.)
IfcCartesianPoint
IfcCartesianPoint
Coord.s=(-75.,-125.,6705.)
IfcBooleanResult
Seco
ndO
pera
nd
y
x
ProfilKoordinaten
FirstOpe
rand
Operator=DIFFERENCE
untere linke Ecke
Koordinaten der
des Abzugs-Körpers
z
y
ProfileType=AREA
XDim=140.
YDim=240.
IfcAxis2Placement2D
RefDirection=$
IfcCartesianPoint
IfcDirection
IfcPolyline
Depth=6830.
IfcDirection
Depth=150.
IfcAxis2Placement3D
IfcDirection
IfcCartesianPoint
Axis
Coordinates=(0.,0.)
IfcAxis2Placement3D IfcCartesianPoint
IfcCartesianPoint
Profil- und Extrusions-Koordinaten sind identisch
mit den Koordinaten der IfcShapeRepresentation
IfcDirection
RefDir.
IfcCartesianPoint
IfcCartesianPoint
Coord.s=(-75.,-125.,-5.)
IfcCartesianPoint
Coordinates=(207.5,0.)
y
x
ProfilKoordinaten
untere linke Ecke
des Abzugs-Körpers
Koordinaten der
z
y
CSG-Modell des Typ-Objekts für die Firstpfette
Die CSG erfolgt in zwei Operationen — Subtraktion des Blattes, die ein IfcBooleanResult zum Zwischenergebnis hat, und Subtraktion der Fase zum letztendlichen
IfcBooleanResult. Folgende Körper tauchen in der Repräsentation auf:
• Ein IfcExtrudedAreaSolid des Rohkörpers. Das Profil ist ein Rechteck von
140mm × 240mm, das orthogonal um 6830mm extrudiert wird. Keine
Translation oder Rotation erfolgt. Dies stellt sicher, dass (a) die Geometrieparameter direkt in Stücklisten genutzt werden können und (b) die lokale zAchse des IfcExtrudedAreaSolid zugleich die Stablängsachse ist.
• Ein IfcExtrudedAreaSolid des Blattes. Es besteht aus einer IfcArbitraryClosedProfileDef, die orthogonal extrudiert ist. Anders als die bisher
48
besprochenen Extrusionskörper muss dieser Körper verschoben und rotiert
werden, um in die richtige Position bezüglich des Rohkörpers zu gelangen.
• Ein IfcBooleanResult mit den beiden vorangegangenen Körpern als
Operanden und DIFFERENCE als Operator.
• Ein IfcExtrudedAreaSolid der Fase. Dieser Körper wird wieder aus einer
IfcArbitraryClosedProfileDef gebildet und lokal verschoben und gedreht.
• Zuletzt ein IfcBooleanResult mit dem vorangegangenem IfcBooleanResult
und dem Extrusionskörper der Fase als Operanden und DIFFERENCE als
Operator.
Es ist empfehlenswert, die Abzugskörper etwas größer als das tatsächlich zu entfernende Volumen auszubilden. So vermeidet man in grafischen Darstellungen Artefakte
infolge von Rundungsfehlern. Aber wichtigere Gründe sind, dass NC-Frontends für
Holzbearbeitungsmaschinen zweifelsfrei erkennen können sollen, welche Flächen des
Abzugskörpers tatsächlich Schnittflächen sind, und dass die Bauteile rückstandsfrei
bearbeitet werden.
Eine Maschinensteuerung könnte das Modell in folgenden Schritten interpretieren:
• Suche nach einer Repräsentation mit der Identifizierung ‚Blank’. (Diese is
in Abschnitt 3.1.8 erläutert.) Falls nicht vorhanden, suche nach einer
Repräsentation mit der Identifizierung ‚Body’.
• Falls die Repräsentation vom Typ ‚SweptSolid’ ist, entnehme die Bauteilmaße den enthaltenen geometrischen Elementen. Säge einen geraden
Balken.
• Falls die Repräsentation vom Typ ‚CSG’ ist, durchlaufe den Baum Boolescher Ausdrücke bis zum ersten Minuend. (Minuenden sind natürlich im
Attribut IfcBooleanResult.FirstOperand enthalten.) Entnehme die Rohmaße
dem Extrusionskörper.
• Durchlaufe den Baum Boolescher Ausdrücke aufwärts und frage alle Subtrahenden ab (IfcBooleanResult.SecondOperand).
• Fräse oder säge die Formfeatures (die durch die Subtrahenden beschrieben
werden) und säge die Stirnflächen (deren Lage dem ersten Minuend entnommen wurden).
Hinzufügen technologischer Daten
Es kann erforderlich werden, weitere Information bezüglich der Herstellung anzugeben: Soll ein Feature gesägt oder gefräst werden? Soll ein spezielles effizientes
NC-Makro verwendet werden? Soll mit besonderer Qualität, z.B. ausrissfrei, gefertigt
werden? Soll über- oder unterschnitten werden?27 Solche Information kann nicht in
das geometrische Modell verpackt werden. Statt dessen müssen fertigungs-bezogene
Property Sets an den IfcMemberType angefügt werden.
Die für diesen Zweck verwendeten Property Sets sind Untertypen von IfcShapeAspectProperties. „Shape aspect“ ist gleichbedeutend mit dem Begriff „Formfeature“.
Die Pfette P1a besitzt zwei Formfeatures — Blatt und Fase — denen jeweils eine
Instanz von IfcShapeAspectCutoutProperties beigegeben werden kann.
27
D.h. soll das Werkzeug über die Ränder der Schnittfläche hinaus geführt werden, oder sollen die
Nachbarflächen intakt, die Kanten dabei aber ausgerundet bleiben?
3 Beispiele
49
Bevor aber so ein Property Sets mit einem Formfeature in Verbindung gebracht
werden kann, muss das geometrische Modell des Features aus dem Gesamtmodell in
eine eigene IfcShapeRepresentation herausgestellt werden: Zusätzlich zur ‚Body’Repräsentation werden in diesem Fall zwei Repräsentationen namens ‚Cutout’ an den
IfcMemberType angefügt. Diese Repräsentationen teilen sich geometrische Objekte
mit dem CSG-Baum der ‚Body’-Repräsentation.28
Pfetten-Typ P1a mit Feature-Information29
IfcShapeAspect
ProductDefinitional=FALSE
Repres.Identifier=’Body’
Repres.Type=’SweptSolid’
Repres.Identifier=’Cutout’
IfcBooleanResult
Operator=DIFFERENCE
IfcBooleanResult
Operator=DIFFERENCE
IfcShapeAspect
IfcShapeAspectCutoutProperties
FeatureType=’Cut’
Name=’EndCut’
(ABS) IfcProperty
(ABS) IfcProperty
...
IfcMemberType
FeatureType=’External’
Name=’Scarf’
EdgeRadius=0
(ABS) IfcProperty
(ABS) IfcProperty
...
Abb. 3-14
Die beiden Instanzen von IfcRepresentationMap, die im obigen Bild auf die Formfeatures zeigen, können auch fortgelassen werden. Das eingefügte Objekt der Pfette
(IfcBeam) wird gewiss nur auf die ‚Body’-Repräsentation per Mapping zugreifen.
Das oben gezeigte Rezept für eine Maschinensteuerung wäre nun im 4. Schritt
anzupassen:
• Prüfe auf Vorhandensein von IfcShapeAspectCutoutProperties in IfcMemberType.HasPropertySets. Arbeite deren Geometriemodelle und nichtgeometrischen Parameter ab. Falls keine solchen Property Sets vorhanden
sind, ziehe die Subtrahenden des Baumes Boolescher Ausdrücke heran.
Eine letzte Anmerkung: Nicht nur CAM profitiert von Feature-Information. Sie ist
auch bedeutsam für Plot-Programme (Anwendungen, die aus dem Modell weitgehend
automatisiert Zeichnungen ableiten sollen) und für Berechnungsprogramme für
Festigkeitsnachweise.
28
Statt gemeinsamer Nutzung der Geometrieobjekte könnten diese auch dupliziert werden. Die Objektgraphen der drei Repräsentationen wären dann nicht untereinander vernetzt. Der Vorteil einfacherer
Objektgraphen würde natürlich mit Redundanz und Modellgröße erkauft.
29
Untergeordnete geometrische Objekte, Mapping-Ursprung und Projekt-Kontext wurden hier nicht
dargestellt. Sie entsprechen der vorigen Abbildung.
50
Ein Bohrloch
Das Gerbergelenk soll mit einem Bolzen komplettiert werden, der von einem gebohrten oder gefrästen Loch aufgenommen wird. Das Bohrloch-Feature könnte ähnlich
wie die beiden zuvor besprochenen Features als Abzugskörper modelliert werden
(IfcExtrudedAreaSolid mit Kreisquerschnitt). Es gibt aber eine leichtergewichtige
Methode, um zylindrische Löcher und eventuell auch Langlöcher zu definieren: Es
wird nur der Eintrittspunkt der Bohrung und ihre Richtung im geometrischen Modell
abgelegt. Alle anderen nicht-geometrischen und geometrischen Parameter, namentlich der Lochdurchmesser, werden über IfcShapeAspectHoleProperties angefügt.
Abb. 3-15
Loch durch das Gerbergelenk
Eintrittspunkt
y
z
Richtung
Mehrere Löcher desselben Durchmessers und in derselben Richtung können unter
einer einzigen Instanz dieses Property Sets vereinigt sein. Dazu werden einfach so
viele Eintrittspunkte in die geometrische Repräsentation gelegt, wie Bohrlöcher hergestellt werden sollen. Ein an ein Typ-Objekt angefügtes Loch-Feature resultiert in
folgenden Objekten:
Typ-Objekt der Pfette P1a mit Loch-Feature (Standardmethode)
IfcMemberType
IfcShapeAspect
...
...
IfcShapeAspectHoleProperties
RepresentationType=’userdefined’
RepresentationIdentifier=’Hole’
IfcDirection
IfcBooleanResult
FeatureType=’Hole’
Diameter=13.
(ABS) IfcProperty
...
Abb. 3-16
DirectionRatios=(0.,-1.,0.)
IfcCartesianPoint
Manchmal muss aber ein Feature an ein eingefügtes Objekt wie IfcBeam, IfcElementAssembly oder IfcWall angehangen werden (wenn es sich um eine Eigenschaft
einzelner eingefügter Bauteile handelt oder schlicht wie bei IfcElementAssembly kein
Typ-Objekt vorhanden ist). Beispiel mit IfcBeam:
Abb. 3-17
Eingefügtes Objekt mit Loch-Feature (alternative Methode)
IfcBeam
IfcShapeAspect
...
RepresentationType=’MappedRepresentation’
IfcMappedItem
IfcDirection
Diameter=13.
(ABS) IfcProperty
...
IfcLocalPlacement
IfcCartesianPoint
3 Beispiele
51
3.1.8 Form des Typs für die Sparren: B-Rep und Features
Der Sparrentyp im Beispiel besitzt vier Formfeatures: Eine Gehrung am First, Kerven
an den zwei Pfettenauflagern und einen Schrägschnitt am Traufende. Wie bei der
Firstpfette stehen zur Modellierung dieser Form CSG, (begrenztes) Clipping sowie BRep zur Verfügung. An dieser Stelle wird nur B-Rep besprochen.
Abb. 3-18
Rohform und bearbeitete Form des Sparren-Typs R1
y
‘Blank’-Repräsentation: parametrisch
z
y
1,2
‘Body’-Repräsentation: B-Rep
Fac. e
1...20 = Eckpunkte
z
3,4
Facette f
quaderförmiges IfcExtrudedAreaSolid
5,6
Facette b
9,10
7,8
Facette g
19,20
Facette a (Facette c)
11,12
Facette h
Facette i
15,16
13,14
Facette d
Fac. j
17,18
Facette l
Facette k
‚Body’- und ‚Blank’-Repräsentation
Wäre die Form allein als B-Rep angegeben, so wäre es schwierig, die Rohform
daraus zu rekonstruieren, also Information über das zur Herstellung benötigte Kantholz. Deshalb wird noch eine zweite Repräsentation an den IfcMemberType angefügt.
Diese wird ‚Blank’ (Rohling) genannt und enthält ein IfcExtrudedAreaSolid.
Abb. 3-19
Objektgraph der ‚Body’-B-Rep und ‚Blank’-Extrusion des Sparrens30
IfcMemberType
Tag=’R1’ PredefinedType=RAFTER
IfcProject
Precision=...
IfcFacetedBrep
Repres.Identifier=’Blank’
IfcClosedShell
IfcFace
a
IfcFaceOuterBound
IfcPolyLoop
IfcFace
b
IfcPolyLoop
...
IfcCartesianPoint
2
IfcCartesianPoint
3
IfcCartesianPoint
4
IfcCartesianPoint
20
IfcCartesianPoint
...
IfcFaceOuterBound
IfcFace
1
l
...
IfcFaceOuterBound
IfcPolyLoop
Warum soll der Rohkörper als eine komplette geometrische Repräsentation anstelle
lediglich eines Property Sets mit den Rohmaßen angegeben werden? Weil diverse
30
Einige untergeordnete Objekte sind nicht dargestellt, z.B. Mapping-Ursprünge.
52
empfangende Applikationen noch weitere Informationen über die reinen Abmessungen hinaus benötigen:
• Anwendungen wie Berechnungsprogramme benötigen die räumliche
Orientierung von Bauteilachse und Profil.
• Maschinensteuerungen benötigen die räumliche Lage der unbearbeiteten
Form relativ zu den Bearbeitungen.
• Wären die Bauteile Bestandteile einer automatisiert montierten Konstruktion, so benötigt das Steuerprogramm Information über Bauteilachsen und
-umrisse relativ zur räumlichen Lage der Baugruppe.
• Anwendungen, die B-Reps nicht darstellen können, könnten die einfacheren
Extrusionskörper verwenden.
• Automatisierte Plot-Routinen einschließlich automatisierter Vermaßung und
Beschriftung benötigen ebenfalls die räumliche Information zur Rohform.
Eine sendende Applikation im Konstruktions-Bereich muss natürlich sicherstellen,
dass die lokalen Koordinatensysteme von ‚Blank’ und ‚Body’ zusammenpassen.
‚Blank’ und ‚Body’ sind also räumlich überlagert. Es wird empfohlen, dass empfangende Applikationen im Konstruktions- bzw. Fertigungs-Bereich folgende IntegritätsPrüfungen implementieren:31
• Die z-Koordinaten aller Eckpunkte im ‚Body’ erfüllen 0 S z S Depth.
Depth wird dem IfcExtrudedAreaSolid des ‚Blank’ entnommen.
• Es sollte mindestens ein Punkt mit z ≈ 0 und mindestens ein Punkt mit
z ≈ Depth vorhanden sein.
• Die x- und y-Koordinaten aller Punkte des ‚Body’ befinden sich innerhalb
des Profils des IfcExtrudedAreaSolid des ‚Blank’.
Wie präzise die Punktkoordinaten der B-Rep mit den Begrenzungen des Extrusionskörpers übereinstimmen, wird mit dem Attribut Precision des IfcGeometricRepresentationContext festgelegt.
Hinzufügen technologischer Daten
Wie bereits erläutert, benötigen CAM-Applikationen, Plotprogramme, CAE- und
andere Applikationen oft feature-bezogene Information über das rein geometrische
Modell der Repräsentation hinaus. Dies wird wieder mit zusätzlichen Repräsentationen, „shape aspects“ und entsprechenden Property Sets realisiert.
Die folgende Abbildung zeigt, wie vier IfcShapeAspectCutoutProperties und entsprechende ‚Cutout’-Repräsentationen an das Typ-Objekt angefügt werden. Dazu werden
in diesem Beispiel Flächenmodelle gewählt, welche sich Instanzen von IfcFace mit
der B-Rep der ‚Body’-Repräsentation teilen.
Es ist nicht erforderlich, für die Features eigene Instanzen von IfcRepresentationMap
einzusetzen, denn die eingefügtren Objekte der Sparren (IfcBeam) werden sinnvollerweise lediglich die ‚Body’-Repräsentation zum Mapping heranziehen.
31
Wir setzen hier wieder voraus, dass die IfcExtrudedAreaSolid.Position in der ‚Blank’-Repräsentation
keine Translation oder Rotation enthält. Vergleiche die Erläuterungen zur Modellierung von Stiel C1.
3 Beispiele
Sparren-Typ R1 mit Feature-Information32
IfcMemberType
IfcShapeAspect
ProductDefinitional=TRUE
Repres.Type=’SurfaceModel’
Name=’EndCut’
(ABS) IfcProperty
IfcFacetedBrep
IfcShapeAspect
IfcClosedShell
IfcFace
a
IfcFace
b
IfcFace
c
IfcFace
d
IfcFace
e
IfcFace
f
IfcFace
g
IfcFace
h
IfcFace
i
IfcFace
j
IfcFace
k
IfcFace
l
Name=’BirdsMouth’
EdgeRadius=-5.
(ABS) IfcProperty
...
IfcOpenShell
IfcOpenShell
IfcShapeAspect
IfcOpenShell
IfcShapeAspect
IfcOpenShell
Einige untergeordnete Objekte sind nicht dargestellt.
EdgeRadius=-5.
(ABS) IfcProperty
...
IfcShapeRep.tation
32
...
Name=’Miter’
MiterAngles=(0.5236)
(ABS) IfcProperty
...
Abb. 3-20
53
54
3.2 Ein Dachbinder
Relevante Klassen
Siehe [7] für Objekte und ihre Beziehungen im Modell eines Binders. Hier ist eine
Übersicht:
Element
Binder
Klasse
IfcElementAssembly
Holzbauteile
IfcMember + IfcMemberType
Verbinder
(Nagelplatten, Nägel, Dübel…)
IfcFastener33 + IfcMechanicalFastenerType
Beschläge
(Lochplatten, Knotenbleche…)
IfcDiscreteAccessory + IfcDiscreteAcc.Type
Beziehungen innerhalb des
Konstruktions-Modells
IfcRelAggregates
IfcRelDefinesByType
Beziehungen zur räumlichen Struktur
Beziehungen zum Statikmodell
IfcRelAssignsToProduct (Name = ‘Context’)
Geometrisches Modell
Im Unterschied zu den Beispielen in Abschnitt 3.1 sind die Bauteile recht einfach
geformt. Sie können in der Regel als Extrusionskörper mit Clippings (durch unbegrenzte Halbräume) modelliert werden. Allerdings benötigen Füllstäbe eines Binders
teilweise zwei Clippings pro Stabende, also bis zu vier Boolesche Operationen pro
Repräsentation. Trotzdem erscheint dies noch effektiver als der Rückgriff auf B-Reps.
Platzierungen der Bauteile und Verbindungsmittel eines Binders sind immer lokale
relative Platzierungen mit Bezug auf die Platzierung des Binders. D.h. die Teile
werden einem lokalen Koordinatensystem des Binders angegeben.
33
IFC 2x2 enthält noch die Klasse IfcMechanicalFastener, die den ST-5-Vorschlägen zufolge gelöscht
werden soll.
3 Beispiele
55
3.3 Eine Wandtafel
Relevante Klassen
Siehe [7] für Objekte und ihre Beziehungen im Modell einer Holzständer-Wandtafel.
Hier ist einer Übersicht:
Element
Wand
Klasse
IfcWall34 oder IfcWallStandardCase,
eventuell kombiniert mit IfcWallType
Wandschichten
Holzbauteile
IfcBeam, IfcColumn, IfcMember +
IfcMemberType
Beplankung (Holzwerkstoffplatten)
(oder IfcPlate + IfcPlateType)
Verschalung, besonders in situ hergestellte IfcCovering + IfcCoveringType
Dämmung
Verbindungsmittel
(Nagel- oder Klammer-Reihen …)
IfcFastener35 +
Beschläge
(Windrispenbänder, Zuganker…)
IfcDiscreteAccessory +
IfcDiscreteAcc.Type
haustechnische Installationen
siehe Abschnitt 2.4.4
Beziehungen innerhalb des Konstruktions- IfcRelAggregates
Modells
IfcRelDefinesByType
Beziehungen zur räumlichen Struktur
Beziehungen zu Wandobjekten des
Architekturmodells
IfcRelAssignsToProduct (Name =
‘View’)
Geometrisches Modell
Die Bauteile werden fast immer als Extrusionskörper modelliert, manchmal mit
Clippings (durch unbegrenzte Halbräume). Platzierungen der Bauteile und Verbinder
sollen sich auf lokale Koordinaten der Wand beziehen, besonders bei vorgefertigten
Wandtafeln. Bei traditionell in situ hergestellten Wänden können die Teile auch
relativ zum Geschoss-Koordinatensystem platziert werden.
34
Vorgefertigte Wandtafeln können auch als IfcElementAssembly modelliert werden, wenn eine Unterscheidung von den Wandobjekten des Architekturmodells anhand der Klassen gewünscht ist.
35
IFC 2x2 enthält noch die Klasse IfcMechanicalFastener, die den ST-5-Vorschlägen zufolge gelöscht
werden soll.
56
3.4 Besondere Anwendungen
3.4.1 Verfeinerte Modellierung im Ingenieurholzbau
noch nicht bearbeitet
3.4.2 Verwendung von IFC in Produktionssteuerungen
noch nicht bearbeitet
4 View-Definitionen
57
4 View-Definitionen
4.1 Zweck und Administration von ViewDefinitionen
Ein View (eine Sicht; Begriff aus dem Bereich der Datenbanken) schreibt eine
Untermenge von IFC-Klassen, Attributen und geometrischen Modellen vor, deren
Unterstützung durch Import-/ Export-Filter gefordert wird. Views werden auf spezielle Anwendungsfälle zugeschnitten. Views vereinfachen die Implementierung von
IFC da sie Umfang und Komplexität des Datenmodells verringern. Vor allem aber
sind sie der Maßstab für Konformitätsprüfungen. Zertifizierung erfolgt nicht anhand
des gesamten IFC-Modells, sondern bezüglich eines vom Implementierer gewählten
Views.
View-Definitionen werden in Arbeitsgruppen entwickelt, die der IAI Implementation
Support Group (ISG) zugeordnet sind. Die ISG gibt letztendlich die View-Definitionen heraus, dient als Forum für Rückmeldungen von den Implementoren und für
Implementierungs-Vereinbarungen, und führt Konformitätstests und Zertifizierungen
durch.
Hinweis: Die Vorschläge in den Abschnitten 4.3…4.5 dienen lediglich als Startpunkte für die eigentlichen, bei oder mit der ISG zu entwickelnden ViewDefinitionen, nachdem die Modellerweiterungen des Projekts ST-5 von der
IAI integriert und offiziell herausgegeben wurden. Diese Vorschläge sind
keineswegs bindend.
4.2 Relevante Views außerhalb der Holzbaudomäne
4.2.1 IFC 2x Coordination View
Diese auf IFC 2x basierende View ist der wichtigste für Planungs-Koordinierung. Er
ist für den Holzbau ebenso bedeutsam wie für das Bauwesen allgemein. Dieser View
liegt vollständig definiert vor und ist der Mittelpunkt der überwiegenden Aktivitäten
von IFC-Implementoren. Zahlreiche Implementierungen sind bereits auf dem Markt.
Der Coordination View zielt auf folgende Szenarien ab:
Einfache Kollisionsprüfung
Sie dient der räumlichen Koordinierung verschiedener Planungsdisziplinen. Dabei
geht es vorrangig um geometrische Bauwerks-Modellierung. Übertragen werden die
räumliche Gliederung (wie Geschosse) und diverse Elemente (wie Wände, Leitungen
u.a.). Es wird mit expliziter Geometrie gearbeitet, vor allem B-Rep, Schalenmodelle
und Mappings. Beziehungen zwischen Bauelementen und deren Öffnungen sowie
58
Öffnungen und deren Verschlüssen, außerdem Verbindungs-Beziehungen, sind mit zu
übertragen.
Funktionale Koordinierung
Zusätzlich zum vorgenannten Szenario geht es auch um den Austausch weiterer
Eigenschaften und teilweise parametrisierter Geometrie. Eine Auswahl logischer
Bauteilinformation wird gesendet und empfangen.
4.2.2 IFC 2x2 Structural Views
Diese View-Definitionen werden gegenwärtig vom IAI-Arbeitskreis Tragwerksplanung vorbereitet. Es gibt deshalb noch keine endgültigen Implementierungen. Diese
Views werden nicht nur Anforderungen der Tragwerksplanung allgemein (insbesondere der Planungskoordinierung) abdecken, sondern auch einen Großteil derer der
Tragwerksplanung im Holzbau. Im Moment sind folgende Unter-Views geplant:
Von der Architektur zum Tragwerksmodell,
d.h. Übernahme des Architekturmodells in Programme zur statischen Modellierung,
um damit die Erzeugung von Berechnungsmodellen zu unterstützen.
Der Import in Tragwerksmodellierer basiert auf dem Coordination View. Der Export,
welcher der Rückkopplung zur Architektenplanung bzw. Planungs-Koordinierung
dient, besteht aus einem ergänzten Architekturmodell, das ebenfalls auf dem
Coordination View basiert.
Vom Tragwerksmodell zur Berechnung,
d.h. gemeinsame Nutzung eines Berechnungsmodells (das in einem Tragwerksmodellierer erzeugt wurde) mit verschiedenen Berechnungsprogrammen (FEM u.a.).
Der Import und Export enthält Objekte der IFC 2x2 Structural Analysis Domain und
zugehöriger Ressourcen-Schemata. Das Modell enthält 1. die Ebene des mechanischen Systems (Querschnitte, Materialien, stabförmige und flächenhafte statische Elemente, Verbindungen, Auflager) und 2. die Ebene der Einwirkungen (Lasten, Lastgruppen, Lastfälle, aber auch resultierende Auflagerreaktionen).
Von der Berechnung zur Bemessung und Konstruktion,
d.h. Übernahme des Tragwerksmodells mit Berechnungsergebnissen zwecks Dimensionierung der Bauteile.
Der Import vom Tragwerksmodellierer oder von Berechnungsprogrammen in Bemessungssoftware beinhaltet Raster sowie stabförmige und flächenhafte Tragelemente
mit Querschnitten und Materialien. Einige Berechnungsergebnisse können ebenfalls
übermittelt werden.
Der Export von der Bemessung und Konstruktion zum Modellierer bzw. allgemeinen
Berechnungssoftware enthält Bauelemente wie Wände, Balken und Fundamente
einschließlich Material, Profilen, Gewicht usw., Anschlüsse, Exzentrizitäten, Formfeatures, eventuell Bewehrungen.
Konstruktion zu Konstruktion,
d.h. der Austausch zwischen verschiedenen Entwurfs- und Konstruktionspaketen,
z.B. für Planung von Mischkonstruktionen und verteiltes Planen (CAD zu CAD). Es
4 View-Definitionen
59
ist derzeit unklar, inwiefern dieser Unter-View mit spezialisierten Views des Stahlbeton- und Fertigteilbaus, Stahlbaus und Holzbaus in Beziehung steht.
4.3 Timber Construction View (Vorschlag)
4.3.1 Ziel-Szenarien
Der anvisierte Markt ist der allgemeine Holzbau, besonders Zimmermannsbau und zu
einem gewissen Grade der Massivholz-Systembau und Holzleimbau. Anwendungsfälle sind
• schrittweise und verteilte Planung von Holzkonstruktionen (Ingenieurbzw. Werkplanung), die horizontalen Informationsaustausch erfordert,
• Arbeitsvorbereitung: Informationsaustausch von Werkplanung zu
Fertigungsplanung, Materialeinkauf und Abrechnung,
• Fertigung: Informationsaustausch von Werkplanung zu numerisch
gesteuerter Fertigung.
Relevante Implementierungen sind beispielsweise:
exportierende Programme
importierende Programme
• Holzbau-CAD
• Holzbau-CAD
• Holzbau-CAE zur
Bauteil- und Anschlussbemessung
• Verwaltung von Stücklisten, Bestellung,
Lagerhaltung, Lieferung
• Viewer, Plot-Programme
• CAM-Schnittstellen, d.h. NC-Frontends
für Holzbearbeitung, v.a. Abbund
4.3.2 Unterstützte Klassen und Attribute
Noch nicht festgelegt.
4.3.3 Unterstützte Repräsentationen
(Bauteile: Extrusionskörper sowie B-Rep und/oder CSG mit zusätzlichen FeatureRepräsentationen)
4.3.4 Weitere Vorgaben
60
4.4 Timber Frame View (Vorschlag)
Der anvisierte Markt ist der Holztafel- oder Holzrahmenbau, d.h. Werkplanung und
Fertigung von Holzständerwänden, Holzbalkendecken und -dächern sowie von
Nagelplattenbindern. Anwendungsfälle sind
• Arbeitsvorbereitung: Informationsaustausch von Werkplanung des
Holztafelbaus zu Fertigungsplanung, Materialeinkauf und Abrechnung,
• Fertigung: Informationsaustausch von Werkplanung des Holztafelbaus zu
numerisch gesteuerter Fertigung.
Relevante Implementierungen sind beispielsweise:
exportierende Programme36
• Holzbau-CAD,
besonders im Holztafel-/
-rahmenbau
• Verwaltung von Stücklisten, Bestellung,
Lagerhaltung, Lieferung
• CAD/CAE für die
Konstruktion und
Bemessung von
Nagelplattenbindern
• CAM-Schnittstellen, d.h. NC-Frontends
für Kappsägen und Nagelbrücken bis
hin zu ganzen Fertigungslinien
• Viewer, Plot-Programme
4.4.2 Unterstützte Klassen und Attribute
4.4.3 Unterstützte Repräsentationen
Geometrie von Typ-Objekten der Bauteile
IfcExtrudedAreaSolid wird als ‚Body’-Repräsentation unterstützt. Einschränkungen:
• Extrusion erfolgt orthogonal zum Profil,
• IfcExtrudedAreaSolid.Position ist die Identität,
• als Profile sind IfcRectangleProfileDef und IfcIShapeProfileDef möglich.37
Es wird auch IfcBooleanClippingResult als ‚Body’ unterstützt. Einschränkungen:
• Bis zu zwei aufeinanderfolgende Clippings können in einer Repräsentation
vorkommen (bei Stäben in Bindern bis zu vier),
• Subtrahenden sind IfcHalfSpaceSolid (unbegrenzte Halbräume),
• Der erste Minuend ist ein IfcExtrudedAreaSolid mit o.g. Einschränkungen.
36
Exportierende Programme sollten auch in die Lage versetzt werden, Daten im Rahmen des Timber
Frame View zu importieren. Dies dient der schrittweisen und verteilten Planung als zusätzlichem
Anwendungsfall dieses Views.
37
Bei Bindern wird nur IfcRectangleProfileDef unterstützt.
4 View-Definitionen
61
Geometrie und Platzierung von eingefügten Objekten der Bauteile
Als‚Body’-Repräsentation wird ein IfcMappedItem unterstützt. Nur Identitäts-Transformation ist zulässig (siehe Abschnitt 2.3.7). Bauteile werden lokal relativ zu den
Platzierungen der Wände, Deckentafeln oder Bindern platziert.
Geometrie und Platzierung von eingefügten Objekten der Verbindungsmittel
Anwendungsprogramme, die Planung und Herstellung von Nagel- oder KlammerReihen abdecken, sollen die in „Teil II: Klassenreferenz“ Abschnitt 6.4.1 beschriebene symbolische Repräsentation unterstützen. Eine solche Repräsentation kann mehrere Linien vom Typ IfcPolyline enthalten. Jede dieser IfcPolyline soll nur zwei
Punkte enthalten.
Unterstützung einer ‚Body’-Repräsentation von Nägeln oder Klammern ist nicht
erforderlich. Noch nicht festgelegt: Repräsentation von Nagelplatten.
Verbindungsmittel sind lokal relativ zu den entsprechenden Wänden, Deckensegmenten bzw. Bindern zu platzieren.
4.4.4 Weitere Vorgaben
4.5 Product Library View/ Parts Library View
(Konzeption)
Der anvisierte Markt ist die Übergabe von Produktinformation von Zulieferern bzw.
der Baustoff- und Komponenten-Industrie an Planer und Ausführende. Anwendungsfälle sind
• Machbarkeits- und Kosten-Untersuchung in Grundlagenermittlung,
Vorentwurf und Entwurf, d.h. Untersuchung von Bausystemen auf
technische Eignung, Ausführbarkeit, Kosten usw.,
• Planung: Gewinnung von Bauelementdaten aus Bibliotheken,
• Berechnung: Gewinnung von Eingangsdaten wie Gewicht, thermische/
feuchtetechnische/ schalltechnische Daten aus Bibliotheken.
Siehe auch „Structural Timber Model – Teil I: Anforderungen“ Abschnitt 3.4.4 für
betroffene Projektphasen, Akteure und Informationsumfang. Relevante Implementierungen sind zum Beispiel:
62
exportierende Programme
• Produktbibliotheken
• Anwendungen in Grundlagenermittlung
und Vorentwurf
• allgemeine Entwurfs-Anwendungen
(CAD)
• LCC, LCA, SLP
• thermische, akustische, statische
Berechnung
• Detailplanung: Massivbau-/ Stahlbau-/
Holzbau- CAD
• Viewer
Dieser View hat Bezüge zu den Projekten IAI XM-7: Harmonisierung von ISO 12006
Teil 3 mit IFC/ BARBi (laufende Projekte) und IAI P-7: Elektronische Kataloge (vorgeschlagenes Projekt).
4.5.2 Unterstützte Klassen, Attribute, Repräsentationen
5 Anhang
63
5 Anhang
5.1 Literatur
[1]
[2]
[3]
ISO 10303-21: Industrial automation systems and integration – Product data
representation and exchange – Part 21: Implementation methods: Clear text
encoding of the exchange structure. International Organization for Standardization, TC184/SC4, http://www.tc184-sc4.org/
representation and exchange – Part 22: Implementation methods: Standard data
access interface. International Organization for Standardization, TC184/SC4,
http://www.tc184-sc4.org/
International Alliance for Interoperability, 2004,
http://www.iai-international.org/iai_international/Technical_Documents/R2x2_
add1/
[4]
Thomas Liebich: IFC 2x Edition 2 Model Implementation Guide. IAI Modeling
Support Group, 18. März 2004,
http://www.iai-international.org/iai_international/Technical_Documents/files/20
040318_Ifc2x_ModelImplGuide_V1-7.pdf
[5]
Kari Karstila, Kalle Serén: Implementation Guidelines for IFC 2x2 Concrete
Domain. Confederation of Finnish Construction Industries, 2. Februar 2004
[6]
Matthias Weise: IAI Project ST-4 — Implementation Guide for Structural
Analysis Domain. Technische Universität Dresden, 4. November 2003
[7]
Jeffrey Wix: ST-5 — Timber Structures. A white paper on IFC model requirements to support the design of timber frame structures. 26. Oktober 2004
[8]
Raimar J. Scherer, Ulf Wagner: Ein Kooperationsmodell für die Kontrolle
divergierender Planungszustände — Identifikationsverfahren von Planungsdifferenzen. Technische Universität Dresden, 2002
64
Abb. 2-1
Verwendung von IFC als Format von Austauschdateien ............................7
Abb. 2-2
Verwendung von IFC als zentrales Produktmodell.....................................8
Abb. 2-3
Ergänzen der IFC mittels Proxy-Objekten, Property Sets, Assoziationen ..9
Abb. 2-4
Verteiltes, konkurrierendes Planen mit separaten Modell-Repositorien...10
Abb. 2-5 Zusammenführen parallel bearbeiteter Modelle........................................10
Abb. 2-6 Typen von Programm-Schnittstellen zu IFC.............................................11
Abb. 2-7
Mögliche Funktionsblöcke einer IFC-Importschnittstelle.........................12
Abb. 2-8 Die Ebenen-Architektur von IFC (IFC 2x2 Kurzform-Distribution) .......16
Abb. 2-9 Semantischer Modellbereich und Repräsentations-Modellbereich ...........18
Abb. 2-10 Ein Produkt mit Repräsentationen in verschiedenen Kontexten .............20
Abb. 2-11 Beispiele von Bauteilen, die als Extrusionskörper modelliert werden....22
Abb. 2-12
Objektgraph eines als Extrusionskörper repräsentierten Produkts..........22
Abb. 2-13
Objektgraphen von Profildefinitionen (Beispiele) ..................................22
Abb. 2-14
Objektgraph eines als Clipping repräsentierten Produkts .......................23
Abb. 2-15 Objektgraph einer B-Rep eines Produkts (Beispiel: Tetraeder) ..............24
Abb. 2-16
Beispiel eines als Oberflächenmodell repräsentierten Produkts .............25
Abb. 2-17
Objektgraph eines mittels Bounding Box repräsentierten Produkts .......26
Abb. 2-18
Mehrfach verwendete „mapped representation“ .....................................26
Abb. 2-19 Beispiel eines Produkts und seines Typs mit duplizierter Geometrie .....27
Abb. 2-20 Einfachster Fall einer kartesischen Transformation: Identität.................28
Abb. 2-21 Rollen von Typen und Occurrences im Holzbaumodell .........................35
Abb. 3-1
Beispiel eines Daches: Grundriss und Schnitt...........................................37
Abb. 3-2 Eingefügte Bauteile und Typen im Modell des Daches ............................38
Abb. 3-3 Versionskennzeichnung (owner history)...................................................38
Abb. 3-4
Verbindungs-Beziehungen (optional) .......................................................39
Abb. 3-5
Material-Zuweisung ..................................................................................40
Abb. 3-6
Kennzeichnung eines Bauteils als tragend mittels Property Set ...............40
Abb. 3-7 Einordnung in die räumliche Struktur, geometrische Platzierung.............41
Abb. 3-8 Beziehungen zwischen Konstruktion und Architektur (optional) .............41
5 Anhang
65
Abb. 3-9
Geometrische Produktdefinition eingefügter Bauteilen (empfohlen) .......42
Abb. 3-10
Lokale relative Platzierungen: Beispiel üblicher Praxis..........................43
Abb. 3-11
Geometriemodell des Stiel-Typs C1 .......................................................45
Abb. 3-12
Mögliche geometrische Modelle der Firstpfette P1a...............................46
Abb. 3-13
Geometriemodell des Pfetten-Typs P1a unter Verwendung von CSG ...47
Abb. 3-14
Pfetten-Typ P1a mit Feature-Information ...............................................49
Abb. 3-15 Loch durch das Gerbergelenk..................................................................50
Abb. 3-16 Typ-Objekt der Pfette P1a mit Loch-Feature (Standardmethode) ..........50
Abb. 3-17 Eingefügtes Objekt mit Loch-Feature (alternative Methode) .................50
Abb. 3-18
Rohform und bearbeitete Form des Sparren-Typs R1.............................51
Abb. 3-19
Objektgraph der ‚Body’-B-Rep und ‚Blank’-Extrusion des Sparrens ....51
Abb. 3-20
Sparren-Typ R1 mit Feature-Information ...............................................53
IAI Project ST-5
Part I
Requirements
by
Chair for Structural Analysis
Brandenburg Technical University Cottbus, Germany
document rev.: 1.final
document status: proposal
31 Dec 2004
Acknowledgement
This document is based on the work of the IAI project group ST-5 and of the research
project “Innovative timber building systems through optimized fabrication and
integrated planning methods; partial project 3: Product model DtH”. The DtH project
is carried out by the Brandenburg Technical University Cottbus, Germany, Chair for
Structural Analysis under guidance of the German Association for Wood Research
(Deutsche Gesellschaft für Holzforschung, DGfH) with funding by the German
Federal Ministry of Education and Research between July 2003 and December 2004
under project number 0330424.
Table of Contents
3
Table of Contents
1 Abstract
5
Document history.....................................................................................................................5
Abbreviations...........................................................................................................................6
2 Introduction
7
2.1 Motivation for product modeling.....................................................................7
2.2 Existing product models ..................................................................................8
2.2.1
2.2.2
2.2.3
2.2.4
2.2.5
STEP............................................................................................................................8
IFC...............................................................................................................................9
DtH ..............................................................................................................................9
Product model developments in neighboring industries ............................................10
Data models for manufacturing of structural timber components .............................12
2.3 Integration of DtH into IFC ...........................................................................13
2.4 The concept of partial models........................................................................15
3 Information Requirements
17
3.1 Scope of the Structural Timber Model...........................................................17
3.1.1
3.1.2
3.1.3
Scope by AEC sectors ...............................................................................................17
Scope by actors, disciplines.......................................................................................17
Scope by project stages..............................................................................................18
3.2 Vertical and horizontal information sharing, model evolution ......................18
3.3 Information requirements by actors, disciplines ............................................19
3.3.1
3.3.2
3.3.3
3.3.4
3.3.5
3.3.6
3.3.7
3.3.8
3.3.9
Architect ....................................................................................................................19
Structural engineer.....................................................................................................20
Design engineer, draftsman .......................................................................................21
Building services engineer (HVAC, electric equipment, plumbing) .........................22
Contractor, manufacturer...........................................................................................22
Building materials industry, supplier.........................................................................23
Project manager .........................................................................................................23
Client (building owner) .............................................................................................23
Building authorities ...................................................................................................24
3.4 Information requirements by project stages...................................................24
3.4.1
3.4.2
3.4.3
3.4.4
3.4.5
3.4.6
3.4.7
3.4.8
3.4.9
Building construction process framework .................................................................24
Data exchange use case: From requirements management to design ........................25
Data exchange use case: Between designs.................................................................26
Data exchange use case: Manufacturers/ suppliers product information to design ...27
Data exchange use case: From design to construction planning................................28
Data exchange use case: Between project management, construction and deliveries29
Data exchange use case: General project management .............................................30
Data exchange use case: From design and construction to use and maintenance......31
Data exchange use case: Between use and maintenance ...........................................32
4 DtH 2.0 Walkthrough
33
4.1 Basics .............................................................................................................33
4
IAI Project ST-5 — Structural Timber Model — Part I: Requirements
4.1.1
4.1.2
4.1.3
4.1.4
4.1.5
File format .................................................................................................................33
Parameter tokens, units..............................................................................................33
Coordinate systems....................................................................................................34
Version control ..........................................................................................................34
External references and component catalogs.............................................................34
4.2 General project data .......................................................................................35
4.2.1
4.2.2
Standard ISO 10303–21 headers ...............................................................................35
DtH headers ...............................................................................................................35
4.3 Common classes.............................................................................................36
4.3.1
4.3.2
4.3.3
4.3.4
4.3.5
Generic classes ..........................................................................................................36
Groupings ..................................................................................................................36
Geometry ...................................................................................................................37
Grids ..........................................................................................................................37
Other defined data types ............................................................................................38
4.4 Architectural model .......................................................................................39
4.4.1
4.4.2
4.4.3
4.4.4
4.4.5
4.4.6
Building sections, floors ............................................................................................39
Building parts ............................................................................................................39
Openings....................................................................................................................40
Stairs..........................................................................................................................41
Foundations ...............................................................................................................41
Comparison to IFC ....................................................................................................42
4.5 Structural analysis model ...............................................................................42
4.5.1
4.5.2
4.5.3
4.5.4
Materials ....................................................................................................................42
Cross sections ............................................................................................................44
Structural analysis......................................................................................................47
4.6 Structural detailing model..............................................................................54
4.6.1
4.6.2
4.6.3
4.6.4
4.6.5
Materials, cross sections ............................................................................................54
Members ....................................................................................................................54
Processing features ....................................................................................................57
Connections ...............................................................................................................64
4.7 Cost estimation, bid preparation, billing........................................................70
4.8 Gaps in DtH 2.0 .............................................................................................70
4.8.1
4.8.2
5 Appendix
Missing building services model ...............................................................................70
Limited production model .........................................................................................71
72
5.1 References......................................................................................................72
5.2 List of figures .................................................................................................73
1 Abstract
5
1 Abstract
This document covers the integration of a product model for timber buildings and
timber structures into the Industry Foundation Classes of the International Alliance
for Interoperability (IAI).
Chapter 2 of this document outlines the business need for a product data model in
the timber construction industry and introduces available data models. The integration
of DtH into IFC is commented on, and the concept of partial product models that is
underlying both of these standards is briefly defined.
Chapter 3 describes the intended scope of the Structural Timber Model and determines the required information to be exchanged within timber construction projects.
Chosen as the main basis for the Structural Timber Model, the current DtH standard
is explained in chapter 4. All existing entities are introduced. (Refer to [5] for
complete attribute definitions.) Shortcomings and differences to IFC are pointed out.
The document is complemented by “Structural Timber Model – Part II: Schema
Reference” and “Part III: Implementation Guide”.
Document history
rev 1.final 31 December 2004
document renamed from “Overview” to “Requirements”
subsection 2.2.4 extended
rev 1.rc1
02 Jul 2004
numerous updates and edits in chapter 2
section 3.4 rewritten using material provided by FinnTimber-IFC
subsection 2.2.5 added, subsections 4.6.3…4.6.5 extended
rev 1.β3
06 Nov 2003
fig. 4-8, fig. 4-9 extended; fig. 4-20, fig. 4-21 added
comparisons to PSS added in subsection 4.6.3
rev 1.β2
30 Sep 2003
subsection 2.2.4, fig. 2-3, fig. 2-5, fig. 4-8 added
sections 3.4, 4.3.1, MEMBER_LTYP, CUTOUT_TIMBER clarified
section 4.8 extended
rev 1.β1
03 Sep 2003
first draft
6
Abbreviations
AEC
architecture, engineering, and construction
AVA
Ausschreibung, Vergabe und Abrechnung (bid preparation, placing of
contracts, billing)
CAD/CAM computer aided design, computer aided manufacturing
CIS
CIMsteel Integration Standards
DIN
Deutsches Institut für Normung e.V., German institute for standardization
DtH
Datentransfer im Holzbau (data transfer in timber construction)
FM
facility management
HVAC
heating, ventilation, air conditioning
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, life cycle cost analysis
LVL
laminated veneer lumber, an orthotropic engineered wood product used
in beam-like applications
OSB
oriented strand board, an orthotropic engineered wood product used in
plate-like applications and stress skins
PSS
Produktschnittstelle Stahlbau (product interface for steel construction)
SIP
structural insulated panel, a sandwich made of OSB skins and foam core
SLP
service live planning
STEP
Standard for the Exchange of Product Data
STLB
Standardleistungsbuch für das Bauwesen (standard construction services
manual for building construction; a German classification system used
in bills of quantities)
VNP
vertical nailed planks, also known as vertically laminated timber decks
or board stacks
2 Introduction
7
2 Introduction
2.1 Motivation for product modeling
Rising labor costs, shortages of skilled workers, consolidation in the builder business,
demand for higher product quality and for more resource saving production — all
these trends stimulate efforts in enhanced industrialized building production. More
and larger components are prefabricated, and automation in builders' shops is increasing. Prefabrication and automation are actually vital for the timber construction
sector to remain competitive with the concrete, masonry, and steel construction. On
the other hand, flexible building designs with an increasing degree of installed
building services are in demand. New construction methods and building systems
emerge as a result.
These developments pose new requirements on the planning process. The various
planning stages have to be more tightly integrated, and the way all involved parties
are planning and communicating has to improve in time and cost efficiency. This is
especially important for timber construction: It involves a higher degree of detail in
planning and a closer link between planning and manufacturing than masonry and
concrete construction. It also features a broader mix of traditional and modern
materials and technologies than structural steelwork.
Currently available solutions for electronic data exchange are however unable to
cover the needs of all parties in a construction project (fig. 2-1), and they are unable
to ensure information sharing continuously during the complete project. Limitations
of existing data exchange interfaces lead to project information being spread over
disparate documents and files which are hard to keep synchronized during the project.
Moreover, proprietary interfaces are in use that complicate implementation and defy
long-term accessibility of data.
fig. 2-1
Data transfer through
conventional interfaces
fig. 2-2
Information sharing via
a product model
Architect
Engineer
Work Prep.
Machine A
Architect
Bldg.Services
Draftsman
Machine B
Engineer
Work Prep.
Product
Model
Machine A
Bldg.Services
Draftsman
Machine B
Therefore, a new data model is required that combines information requirements of
all actors involved in construction projects. Such a data model ultimately focuses on
the product (the building) instead of individual applications, which is why such a data
model is called a product model. Some of the benefits of a product model become
immediately clear from fig. 2-2: The number of interfaces necessary to connect all
8
information endpoints decreases considerably. All endpoints are equally well connected. Redundancies and therefore sources for errors are minimized. Design changes are
passed on faster, and conflicts can be detected and resolved in a timely manner.
Moreover, product modeling recognizes building design and construction planning as
multidisciplinary optimization tasks. The goal is a product that delivers maximum
value to the owner within given limits of money, time, and other restrictions. A
product model supports optimization by allowing views upon the project as a whole,
as it combines information about all the different aspects that influence the optimum.
A product model typically fulfills the following criteria:
• Context is provided.
Just like we expect it from a decent technical drawing, electronically
transmitted data shall have clear meaning and shall reflect the designer’s
intent. Relationships between different project aspects must be expressed.
• System independency is maintained.
System independency means more than computer platform independency.
The way how project data are structured shall not be determined by a single
tool, discipline, or process. Instead, the great diversity of processes and
planning tools involved in construction projects must be taken into account
in the first place. This leads necessarily to a focus on the product instead of
a focus on an application.
• Information grows during the project’s whole time span.
To design is to learn and to solve problems, as is production planning.
Previously generated information has to be reevaluated, supplemented, or
rectified while the project is progressing. The data model carrying design
information must support this iterative process. Successive planning
processes reuse existing information and accumulate newly obtained
information.
• Data formats shall be non-proprietary. Conformance shall be assessed.
The methods of presenting information in electronic form shall be neutrally
developed and openly published. Implementations shall be tested for
conformance using formalized methods.
2.2 Existing product models
2.2.1 STEP
The ISO 10303 family of standards a.k.a. STEP [1] provides methods and models for
product data representation and exchange for a wide range of industry sectors. STEP
essentially consists of
• description methods, implementation methods, and conformance testing
methodology,
• generic models (common resources),
• specialized models (Application Protocols, which have been supplemented
by Application Modules more recently).
2 Introduction
9
STEP documentation is distributed subject to charges by national standards institutes.
As aid for implementations, there is a free STEP Class Library available from NIST
as well as a variety of commercial software development tools and data management
solutions for STEP.
2.2.2 IFC
After several product modeling projects within the ISO and STEP context, it became
apparent that neither the ISO standardization process nor the initially monolithic
approach taken by STEP Application Protocols are well suited to the requirements of
the multi-disciplinary AEC/FM industries. This situation lead to development of the
Industry Foundation Classes [2] as an industry standard (instead of a formal
standard). The IFC addressed the problem of cross-disciplinary interoperation on its
conceptual level in the first place. The IFC are layered in
• common resources,
• core,
• interoperability layer (interdisciplinary),
• domain layer (special to disciplines).
The IFC are based on the STEP low level and have adopted parts of the STEP mid
level in the resource layer (STEP parts 41, 42, 43). The withdrawn STEP part 106
Building Construction Core Model was one of the major foundations of IFC
development.
The high level of first releases of IFC covered architecture, HVAC, FM, and cost
estimating. Recent releases added basic structural engineering, further building
services and FM elements. IFC documentation is freely distributed. Implementation
support and certification is provided under the terms of IAI. Software toolboxes for
STEP as well as dedicated toolboxes like EPM Technology EXPRESS/IFC toolbox,
Eurostep IFC Toolbox, or QualiSTEP CSC are available. Abstraction layers like the
SABLE APIs of the BLIS project are being developed.
2.2.3 DtH
DtH is a German product model specification that was developed by the Brandenburg
Technical University Cottbus and several software vendors for the DGfH, a nonprofit research organization of the German forest and wood industry and timber
construction industry. The DtH specification has its roots in PSS, the German product
model industry standard for steel construction [3]. Both PSS and DtH are based on
STEP. DtH is targeted to timber engineering construction, carpentry, and prefabricated residential buildings. It is oriented towards the viewpoint and language of
engineers, architects, and builders.
The first release version 1.05 (02.1996) contained three partial models: Structural
design model, detailing design model, and a simple building costs model [4]. Version
2.0 (12.1999) added an architectural model, enhanced the detailing model, and
addressed ISO 10303 conformance issues [5].
DtH uses feature based parametric descriptions of building elements in order to cover
information requirements of both engineering and fabrication. Low redundancy on
the level of the model concept is maintained with the goal of low data redundancy in
10
populated DtH models. Another characteristic of DtH is its low complexity; no
inheritance relationships, inverse attributes, or local rules are used.
DtH documentation is freely available. Implementation support was made available
only during the time spans of the version 1.0 and 2.0 research projects. DtH
implementers can utilize STEP development tools since DtH 2.0.
2.2.4 Product model developments in neighboring industries
Steel construction industry
Within the steel construction industry, the CIMsteel Logical Product Model (CIS/2
LPM, maintained by Steel Construction Institute, UK) and the German DSTV PSS
[3] are in use. Newer incarnations of LPM do not only cover information
requirements of analysis, design, and manufacturing of structural steel frames but also
to some extent more general processes of the construction industry such as scheduling
and costing. Capabilities of LPM that are not yet available in IFC include dynamic
analysis, and dimensions with tolerances. The possibility of mapping between LPM
and IFC is currently investigated by the American Institute of Steel Construction.
PSS is a model with similar scope but lesser capability than LPM. PSS is thereby less
complex and easier to implement. PSS was the primary source for the IAI ST-4
project, yielding the Structural Analysis domain that is already part of IFC 2x Edition
2, plus several extensions in lower IFC levels and the Structural Elements domain.
The work done in the ST-4 project provides an important basis for the IAI ST-5
extensions derived from DtH.
Proprietary AEC product models
Several architectural CAD and steel CAD application suites are based upon
proprietary product models, also called building information models. These models
are the result of customer demand for tight integration of CAD with other AEC
applications like quantity take-off, analysis software, and fabrication software.
Unlike standardized product models, proprietary models are limited to single-vendor
solutions that are able to integrate only business processes within a single
organization, e.g. within a design office or a construction company.
1
[9], [10], [11], [12]
2004
2003
2002
ANSI
ISO
SCI
IAI
ST-6
IFC 2x2
ifcXML
IFC 2.0
ST-5
ST-4.2
ST-4
ST-1
DSTV
PSS 04.2000
IFC 1.0
IFC 1.5.1
PSS
IFC
Ein Produktmodell
für den Stahlbau
(Haller)
DSTV NC protocol
DSTV uniform material
designations
DSTV interface between
structural analysis and CAD
Industry Foundation Classes
2001
CIS/2.1
CIS/1 finished
CIS/2 started
CIMsteel Integration
Standards
CIS/1.0
Computer Integrated Manufacturing for
Constructional
Steelwork
CIMsteel
Eureka program
IFC 2x
ISO 10303-225
IS published
circa 30 APs in the
works, e.g.
pt.225 - building elem.
pt.228 - HVAC
pt.230 - steel frames
pt.106 - BCCM (bldg.
constr. core model)
interoperability models
in the works
parts 1, 11, 21 etc
pt.201 - 2D drawing
pt.203 - 3D drawing
Standard for the
Exchange of Product
Model Data
initial ISO 10303
(STEP) release:
initial proposed standard
STEP
Product Data
Exchange
Specification
PDES
XBF
2000
1999
1998
1997
1996
1995
COMBI project
1994
CALS
ATLAS project
DIN
flächen-Schnittstelle
VDA-FS Freiform-
1993
IGES 6.0
IGES 3.0
CADLIB
VDA-PS
et de Transfert
SET Standard d'Echange
AFNOR
Esprit program
U.S.AF
IGES 1.0
Initial Graphics
Exchange
Specification
1991
1988
1987
1986
1984
ICAM program
DGfH
DtH 2.0
DtH 1.05
Datentransfer
im Holzbau
fig. 2-3
1982
1980
1973
2 Introduction
11
Timetable of product model developments1
12
Furniture industry
The European funSTEP project lead to an Application Protocol for the furniture
industry, which is currently prepared to become ISO 10303–236. Numerous high- and
low-level parts of ISO 10303 are reused by funSTEP. Main interest of the funSTEP
project is the exchange of product data between furniture manufacturers, furniture
retailers, and decoration studios. In scope of funSTEP are:
• product definition, product catalogues, simple furniture and modular
furniture,
• geometry, dimensions, parameterization, configuration, finishing,
accessories, price,
• interior decoration, room space definition and representation, furniture
placement.
While an intersection of scopes of IFC and funSTEP exists with respect to furniture
as facilities objects, there is no intersection with respect to manufacturing of woodbased products. Whereas the ST-5 IFC extensions consider machining and jointing of
engineered wood materials, there are no provisions in funSTEP for integration of
detailed design and manufacturing.
Forestry
In 2002, the German interface standard ELDAT for forestry was released that fulfills
the criteria of a product model for the most part. This standard serves for the
exchange of product data of raw wood (logs) and contractual data between forest
owners, wood consuming industries (especially mills and pulp industry), wood
traders, and carriers in the German wood market. The standard is conceived for filebased exchange using comma-separated text files or XML files. The data model
consists of a dozen entities with a huge number of attributes, combined with an
extensive controlled vocabulary. The use cases and information contents of ELDAT
and DtH / IFC Structural Timber Model do not yet overlap but might converge in the
long term.
2.2.5 Data models for manufacturing of structural timber
components
European and North American timber construction is characterized by rising degrees
of prefabrication using numerically controlled and semi-automatic fabrication
equipment. Consequently, a tight integration of workshop design and manufacturing
is practiced. Two examples of data models that are widely deployed in such
integration solutions are given below.
A unilateral interest of the CAD software industry exists to replace the various data
models by a unified product data model such as DtH or IFC. CAM integrators
however have so far shown little to no interest in non-proprietary solutions. The
North American initiative WINStep (Wood Industry Standard for the Exchange of
Product data), comprised of members of the CAD software industry as well as of
machinery retailers, is aiming to resolve this situation by means of a common data
protocol for CAD/CAM integration in woodworking. The protocol is to cover product
data, process data, and technology data; a specification is however not yet available.
2 Introduction
13
Hundegger data interface between CAD and NC joinery machines
The interface defined by Hans Hundegger Maschinenbau GmbH is used for integration solutions between timber detailing CAD and woodworking machines for
processing of beams. The interface uses line-oriented tabulated text files, i.e. with
fixed positions of characters. The files contain essentially
• a short header with designation of the project,
• a list of all beam types to manufacture. Each beam type is described by
amount of beams to manufacture, material grade, parameterized raw
geometry, and destination with respect to packeting and installation.
• Associated with each beam type are processing features. Each feature is
identified as a machining macro; in other words, the type of feature is
determined from the viewpoint of functionality of the machine, not from the
viewpoint of feature geometry.
• Features are parametrically defined; again the meaning of parameters
depends solely on the chosen machining macro. However the parameters
essentially describe the feature’s shape, not the exact path and velocities of
the tools.
The set of available machining macros depends on machine type and control firmware revision. More than 80 macros may be available. In essence, not only building
element data but also knowledge about machine functions and their optimal use is
required in order to create the files used by the Hundegger data interface; but lowlevel NC code is not transmitted.
Weinmann data interface between CAD and timber framing machines
The interface developed by Weinmann Holzbausystemtechnik GmbH, SEMA GmbH,
and GranIT GmbH is used for integration solutions between CAD and CAM for
production of building components in light timber frame construction style. The
interface uses line-oriented text files with comma separated fields. Each file describes
one assembly. The files contain essentially
• a header with overall parameters of the assembly,
• a list of all framing members, including their size, placement, and applied
machining processes,
• a list of all sheathing panels with their material, shape, placement,
machining processes, and nail rows.
The interface was originally based on a 2D coordinate system with layer information.
A third coordinate was recently added to accommodate more complex building styles.
Virtually no machine specific information is transmitted by this interface. Although
keywords for sawing, milling, and drilling exist, the actual tool is selected afterwards
by the machine’s firmware. Like in the Hundegger data interface, processing
parameters describe the shape to create, not actual tool paths.
2.3 Integration of DtH into IFC
Benefits
DtH and IFC are both STEP based and share the concept of partial models (see
section 2.4). The current IFC specification features extensive support for architectural
14
design, building services, project management, and facility management while
structural engineering tasks have not been covered until recently. DtH on the other
hand explicitly supports structural design for timber structures while other areas are
less comprehensively defined or even missing. It is therefore an obvious idea to
merge DtH and IFC.
The benefit for existing DtH implementations of this transition is to gain connectivity
to major architectural CAD applications and to building services design and to
overcome the limitation to the national AEC software market. The benefit for IFC is
the improved versatility of IFC implementations. The fact that DtH is already
implemented and used in practice is an important advantage for the new Structural
Timber Model since the process of standard definition, documentation, and testing is
considerably accelerated.
Scope of current IFC and DtH specifications
demolition
conservation
IF
C
use
2x
2
design, struct.
calculation
building
lifecycle
detailing
0
conversion
preliminary
design
prefabrication
erection
2.
fig. 2-4
Dt
H
Modeling strategy
The ST-5 model extensions are designed according to following rules:
• Avoid deep interventions into the IFC architecture in order to allow for
quick integration of the proposal.
• Do not duplicate functionality that is already available in IFC or will be
made available by ongoing projects.
• Aim at compatibility to the other structural domains: Steel construction,
reinforced concrete, and precast concrete domain.
• Maintain independence of national building codes.
• Do not delete functionality of the DtH model (unless it is agreed upon
obsolescence of a functionality).
Several necessary extensions are already provided by the IAI project ST-4 “Structural
Analysis Model and Steel Construction”2 and the IAI project ST-3 “Precast Concrete
Construction”—see fig. 2-5. These provisions will enable the ST-5 project to concentrate the majority of its additions into the domain layer in a mostly self-contained
form.
2
The ST-4 project is currently continued by a follow-up project that adds IFC extensions for detailing
of steel members and steel connections.
2 Introduction
15
Limitations of DtH/IFC harmonization
For several reasons — among them naming conventions — IFC files using the future
Timber Construction domain will not be compatible with DtH files.
However, while files are incompatible, the IFC model including the future Timber
Construction domain will be a superset of the complete DtH model. It should thus be
possible to convert DtH files into IFC files.
fig. 2-5
Extensions to IFC 2x by the ST-3, ST-4, and ST-5 projects3
HVAC
Domain
Architecture
Domain
Electrical
Domain
Construction Mgmt
Domain
FM
Domain
Precast
Concrete
Construction
Domain
Structural
Analysis
Domain
Steel
Construction
Domain
Timber
Construction
Domain
Domain Layer
Shared
Bldg Services
Elements
Shared
Spatial
Elements
Shared
Management
Elements
Shared
Facilities
Elements
Shared
Building
Elements
Shared Bldg
Elements
Extension
Additions
Product
Exten.
Extn.
Additions
IFC 2x platform
ISO/PAS 16739
non-platform part:
next candidates
Control
Extension
Process Product
Kernel
out of platform
IFC 2x ST-3 ST-4 ST-5
Core Layer
Material
Resource
Geometry
Resource
...
...
...
...
Material
Property
Resource
Geometric
Model
Resource
Profile
Resource
Measure
Resource
Representation
Resource
Topology
Resource
Profile
Extension
Resource
Measure
Extension
Resource
Representation
Extension
Topology
Extension
Resource
project
project
project
harmonization
with BEC
harmonization
with PSS,
CIS/2
harmonization
with DtH
Resource Layer
Additions Geometric
Model
Extension
Profile
Property
Resource
Structural
Load
Resource
Additions
2.4 The concept of partial models
For reasons of general applicability in the international AEC/FM business, product
models for building construction consist of partial models (see [8], section 2) . In the
following chapters, the terms
• architectural model,
• structural analysis model,
• structural detailing model,
3
See [13] and [14]. Most of the ST-3 and ST-4 proposals were integrated into IFC 2x2. A new
Structural Elements Domain schema subsumes the Steel and PC Construction Domain schemas. The
Timber Construction Domain is targeted to become part of the Structural Elements Domain.
16
• production model,
• physical building model
will be used. A complete product model for building construction in general and for
timber construction in particular contains of course further partial models, e.g. for
HVAC design, for cost estimation, or for project control.
The architectural model
describes geometrical, functional, and aesthetic aspects of the building. It contains
representations of tangible elements like floors, walls, columns, and representations
of intangible elements such as room functions or escape routes.
The structural analysis model
idealizes the load carrying system of a building together with actions. It contains
mechanical abstractions as well as design code dependent means for verification of
structural safety, serviceability, and durability.
The structural detailing model
provides information about the building parts: Materials, shapes, treatments, connections and so forth.
The production model
is a specification of the structural detailing model. It contains information related to
prefabrication, transport, and erection.
The physical building model
contains all tangible (physical) elements of the building structure and thus contains
parts of the architectural model and the structural detailing model. Elements of the
structural analysis model are associated to parts of the physical building model.
It is a three-dimensional virtual building including all structural and non-structural
components. As such it constitutes the core of the product model. All other partial
models are related to or directly derived from it. Partial models may share objects.
Optimal product model formulation aims at least possible redundancy with respect to
the meta model—in order to avoid ambiguities—and with respect to the instantiated
model—in order to avoid sources of errors during product design changes.
17
3.1 Scope of the Structural Timber Model
3.1.1 Scope by AEC sectors
In scope:
• building sector, especially:
• prefabricated house construction,
• structural timber engineering,
• carpentry.
Partially in scope:
• façade construction,
• finishing trades (fixtures and equipment),
• bridge engineering,
• scaffolding and formwork,
• building materials industry.
3.1.2 Scope by actors, disciplines4
In scope:
• architect,
• structural engineer,
• design engineer/ draftsman,
• contractor,
• building materials supplier.
Partially in scope:
• client (building owner),
• project manager,
• building authorities,
• building services engineer (HVAC, electric equipment, plumbing),
building services (sub-)contractor.
4
The concepts of actors, roles, and disciplines are freely intermixed in this document. One actor may
take over several roles as well as several actors may fulfill one and the same role.
18
3.1.3 Scope by project stages
The main application of the structural timber model are new building projects. The
structural timber model is furthermore relevant in reconstruction & rehabilitation and,
to a certain degree, to demolition projects.
Within a project, these stages are primarily in scope of the structural timber model:
• structural design,
• structural detailing,
• workshop drawing,
• production planning.
In scope are furthermore
• pre-fabrication,
• site construction,
• as-built documentation.
Partially in scope is
• preliminary design.
3.2 Vertical and horizontal information
sharing, model evolution
Vertical information sharing occurs between actors with different roles in a project.
An example is the shared use of geometry information by a CAD program and a finite
element analysis program.
Horizontal information sharing occurs between actors who fulfill the same role, e.g.
the shared use of geometry and feature information between two detailing CAD
programs.
An intermediary case is information sharing between actors with similar roles, e.g.
shared use of building member data between an architectural CAD application and a
detailing CAD program. While the latter maintains processing details as features, the
architectural CAD program will certainly only provide a geometry-oriented view on
these details.
Evolution: The amount of information increases during the various design and
realization stages:
• Superstructures are subdivided into members.
• Details are added to members.
• Qualitatively new information is added, additional partial models are
developed.
• Relations between partial models are established.
• Designs are optimized, inappropriate decisions are corrected, designs are
readjusted to changed boundary conditions (e.g. client requirements).
19
Hence the model structure has to support the development of the specific from the
generic. It has to provide shared elements of separate partial models and links
between partial models. Version information has to be stored to reflect the iterative
nature of the planning process.
Information provided by the structural timber model serves (but is not limited to)
• the derivation of the load carrying structure from the architectural model,
• the structural analysis of the timber structure,
• working design of timber members after analysis,
• connection design together with connection analysis,
• production planning based on working design and connection design.
3.3 Information requirements by actors,
disciplines
3.3.1 Architect
• receives various functional, technical, and non-technical requirements from
building client and from authorities, receives topological situation from
surveyor;
• creates spatial, functional, and formal model of the building;
• generates parts of the structural system of the building;
• checks final structural design from engineers or contractor for functional,
formal, and other aspects;
• checks building services model for inconsistencies.
The level of detail of the architect's planning varies to great extend depending on the
type of building, contractual constellations, and local practice. The architect generally
defines superstructures like walls and decks and chooses construction type and
material. The job of structural design and structural detailing of the final building
structure is left to the structural engineer (consulting engineer) or/ and the technical
office of the contractor.
The final structural model — as submitted from the engineer or contractor to the
architect for approval — does not necessarily need to provide complete explicit
geometry of secondary components like bolts, nails, fasteners etc., except if aesthetic
aspects are of concern.5
It is important that visual representation data (geometry, annotations) that were
generated by specific CAD tools for timber structures is also accessible by CAD
5
Examples: It may be desirable for exposed glulam structures with concealed connectors to show
explicit geometry of dowel faces — considering that joints substantially contribute to the visual
appearance of a timber structure. On the other hand, conventional beam hangers in a clad floor deck
could be presented by abstract symbols.
20
programs that implemented only the IFC Coordination view but not the structural
timber domain.
If components are referenced (not copied) from a library or electronic catalog, the
library has to be accessible by all relevant project participants. The availability of the
library has to be ensured for the whole lifetime of the building model data repository
which may by far outlast the actual project duration.
3.3.2 Structural engineer
• starts with the architectural model; considers geotechnical boundary
conditions;
• creates structural model of the building;
• decides on structural materials and principles of structural details;
• checks structural detailing model for aspects of structural safety,
serviceability, and durability.
Main task of the structural engineer is to create a structural analysis model on the
basis of the architectural model. Aside from 3D geometry, various contextual
information is required, e.g. identification of ‘floor of a residential building’,
‘structural/ non-structural wall’, and fire resistance requirements. If this information
is provided as formalized data, partial automation of structural modeling would be
facilitated.
The structural analysis model consists of several sub-models that are more or less
coupled. All building structures are basically 3D structures but can and will often be
simplified as 2D models.6 Structural components of timber structures are generally
modeled with linear, 2-node beam elements. Nodes may represent bearings or connections, which often allow for local elastic deformation.
Some structural analysis methods for structural timber design use mechanical systems
on a higher level than beam structures. An example is the simplified design of shear
walls provided by several design codes where certain practical assumptions about
distribution of internal forces and deformations are made.
Materials used for timber structures are in general anisotropic.7 Since the structural
behavior of wood-based materials depend on time and moisture content, contextual
information from the architectural model is important for generation of the structural
analysis model. Moreover, timber material properties depend on profile properties.8
If material properties are stored for horizontal data sharing, the associated design
code should be referenced because it provides necessary context for these values. It
6
A timber structure is actually a 4D problem since the time dimension is also important. Static
calculations reduce the 4th dimension to some relevant discrete points, like t = 0 (tinst) and t → ∞ (tfin).
7
8
As of yet, IFC contain only isotropic material descriptions.
Examples: The bending strength of solid timber according to Eurocode 5 increases below a certain
reference depth in bending. The capacity of a glued laminated timber beam depends not only on its
dimensions but also on the so-called lamination layup. Laminations of different grades can be arranged
throughout the depth of a glulam member.
21
should also be explicitly noted whether mechanical properties are given as factored
resistances (limit state design method, using partial safety factors) or as allowable
values (allowable stress design method).9
If the product model was limited to factored resistances only, its adoption could be
delayed for a very long time until all design codes and vendor catalogs are converted
from allowable stress design method to limit state design method. It is even conceivable that building materials and accessories that are not standardized in design codes
continue to use allowable stresses or allowable forces.
3.3.3 Design engineer, draftsman
• receives architectural model and structural analysis model;
• finishes the structural details of the building;
• checks building services model for collisions.
The structural detailing model is derived partly from the architectural model and
from the structural analysis model. — In return, structural details have of course often
impact on architecture and on structural analysis. At least basic parts of the structure
need in fact to be designed before structural analysis may begin. — The mapping
from structural load carrying members to structural analysis elements is, in general,
an M : N mapping. E.g. several beam elements in the structural analysis may
represent one solid timber beam, or one beam element in the structural analysis may
represent a series of parallel deck joists.
The mapping from the architectural model to the structural detailing model is
generally an M : N mapping as well, but in most cases it is a simple 1 : N mapping.
E.g. a wall consists of several studs, panels, fasteners, etc.. A similar mapping exists
between architectural and structural analysis model.
These mappings can be expressed by and stored as relationship entities, thus easing
eventual changes during the planning process, e.g. when change requests to the
building’s layout are passed down from the building owner. — However, while the
initial generation of these relationship entities is rather simple, the maintenance of
these relations may be difficult. For instance, if an architectural CAD program splits
one wall into two or if it removes a wall, either the architectural CAD program has to
rebuild a valid mapping, or the engineering CAD/CAE applications have to detect
and to react on outdated relations.
While the coupling between partial models and the resolution of conflicts due to
concurrent planning processes is still a matter of scientific research, IFC already
provide the means (but not the policy) for inter-model coupling. Policy, like
functionality for semi-automated conflict resolution, is and will remain out of scope
of the IFC model definition.
9
This will not only facilitate horizontal data sharing during the project execution but it will also
support future assessment of applied materials long after erection when vendor-provided data sheets or
then withdrawn design codes are not available anymore.
22
3.3.4 Building services engineer (HVAC, electric equipment,
plumbing)
• receives architectural model;
• considers details of the structural model where necessary;
• creates energetic model of the building (part of this task is sometimes
carried out by the architect or structural engineer);
• creates models of services networks;
• checks architectural/ structural model for collisions and incompatibilities.
The physical building model must provide explicit geometrical information wherever
installation equipment shall be routed. For instance, the location and shape of studs
within timber walls must be specified if there is no extra installation layer in a multilayered wall.
The explicit shape of components like metal fasteners is not required in any case.
However, information about minimal distances of openings from joints and from
member edges is necessary for proper layout of services networks. This information
is at present not explicitly given to the building services engineer, which often results
in time-consuming and error-prone iteration during the planning process (repeated
exchange and stepwise revision of plans).
Furthermore HVAC and plumbing design requires information provided by the
structural engineer whether members are part of the load carrying system.
To derive the energetic building model, contextual information (like classification in
‘outer’ and ‘inner’ walls and decks) and functional data of building spaces are to be
acquired, as well as thermal and hygroscopic properties of materials or compounds.
3.3.5 Contractor, manufacturer
• acts on the basis of architectural, structural, and building services model and
checks these models for compatibility, feasibility, economy;
• creates the production model (manufacturing, transport, and erection
model).
The production model contains production information like construction schedules
and parts lists.
Modern timber construction features a high degree of prefabrication. For improved
competitiveness, demand for higher automation of the production of timber building
parts conflicts with demand for highest possible flexibility of the building’s design.
To resolve this conflict, the design process has to be continuous and consistent from
early design until production. Fast, easy, and accurate deduction of manufacturing
information from the structural detailing model is necessary.
Hence feature based parametric models for timber members and joints are required.
Models that solely provide explicit geometry data are not sufficient for generation of
machine control data. For instance holes, notches, tenons, fasteners etc. have to be
formulated as features of a timber member in order to prepare fabrication with
numerically controlled joinery machines.
23
3.3.6 Building materials industry, supplier
• provides technical product information to architect, engineer, contractor.
External electronic catalogs — or libraries of materials and accessories — are of
enormous importance for the structural timber model. Such catalogs and libraries
need to be maintained by the building materials industry.
• Submits bids to contractor or client;
• receives material order from contractor or client.
Especially in the North American and Scandinavian markets, more and more building
components are prefabricated already by the supplier instead of by the builder. The
supplier needs therefore access to design data. However the design data handed out to
the supplier are often taken out of their original context in a project (relating to a
building) and put into a new context relating to a delivery order.
3.3.7 Project manager
• checks and approves documentation from architect and engineer;
• prepares bill of quantities, calls for bids, awards contracts;
• creates project schedules;
• checks and approves technical and non-technical documentation from
contractor.
The building model submitted to the project coordinator for approval, cost control,
and scheduling of production must not necessarily provide complete explicit geometry of secondary components, e.g. fasteners.
3.3.8 Client (building owner)
• specifies functional and aesthetic requirements and sets cost frame;
• authorizes technical and non-technical documentation from architect,
engineer, contractor;
• receives complete technical documentation from architect, engineer, and
contractor at the end of the project.
In early project stages the architect typically visualizes his idea of the building by
means of drawings and computer or true-scale models. At this stage specific timber
construction related information is generally not required, except for sophisticated,
exposed timber structures where a detailed rendering of typical details may be
desirable.
At the end of the project the client requires handover of complete documentation,
as-built documentation included. This information, stored in a product model, will
allow the client to access any data required for renovation, extension, conversion, sale
or wrecking of the building.
24
3.3.9 Building authorities
• check submitted building application for technical, formal and legal
requirements with respect to urban development, fire protection, energy
consumption, sound insulation, etc.;
• inspect construction site;
• finally check the finished building with respect to conformance to approved
specifications.
The required level of detail depends on national and local regulations and on type of
the building, as does the required form of physical representation of the
documentation. Electronic data exchange with authorities will become more common
in the future.
3.4 Information requirements by
project stages
The content of this section was kindly provided by the FinnTimber-IFC project.
3.4.1 Building construction process framework
The following main project stages are identified: Requirements definition, building
design, construction planning, construction, use and maintenance. Important milestones of a construction project are
1
project decision,
2
design decision,
3 building permit decision,
4
construction decision,
5 building commissioning decision.
Throughout and after the construction project, the following tasks are carried out:
Project management, authority control, requirements management, design coordination, architectural/ structural/ HVAC/ other design, construction, component
production, material supply, use, maintenance.
Subsequent sections analyze data exchange use cases during individual project stages
and tasks.
25
3.4.2 Data exchange use case: From requirements management to
design
fig. 3-1
Data exchange — From requirements management to design
Building design
Project
Project
managmt.
mgmt. Feasibility 1
study
Project
planning
Authority
control
Marketing
Design
control
2
Authority control
of design
4
Requirements
management
Requirements
management
Design
coordination
Requirements
definition
Design
coordination
Architectural
design
Requirements
definition
Requirements
management
Requirements
management
Detailed
design
Construction
supervision/ ARCH
Structural
design
Preliminary
design
Detailed
design
Construction
supervision/ STRUCT
HVAC
design
Preliminary
design
Detailed
design
Construction
supervision/ HVAC
Preliminary
design
LCC, LCA,
SLP
Detailed
design
Construction
supervision/ Other
ring
planning
planning
Construction
Component
production
Marketing of
product solutions
Requirements
management
Construction
supervision/ DC
Preliminary
design
Other
design
Use, Maintenance
Construction
supervision
Authority control
of construction
3
Requirements
management
Construction
Construction
control
Tendering
Component
design
Material
supply
Marketing of
product info
Procurement
Construction
5
planning
production
delivery
ment
Tendering
Material
deliveries
Use of the
building
Use
Building
maintenance
Maintenance
Project phase
the whole project
Sender
design coordinator, architect
Sending app.
requirements definition and management applications
Receiver
designers (arch., structural, buildg. services, LCC, LCA, SLP)
Receiving
application
design applications (CAD modeling),
LCC, LCA and SLP applications
Information
content
spatial requirements
spaces, building elements, building service systems
related requirements: quality requirements, energy efficiency,
service life, use of non-renewable resources, environmental impact
26
3.4.3 Data exchange use case: Between designs
fig. 3-2
Data exchange between designs
Building design
Project
Project
managmt.
mgmt. Feasibility 1
study
Project
planning
Marketing
Design
control
2
Authority
control
Authority control
of design
Requirements
management
Requirements
management
Design
coordination
Requirements
definition
Design
coordination
Architectural
design
Requirements
definition
Requirements
management
Requirements
management
Detailed
design
Construction
supervision/ ARCH
Structural
design
Preliminary
design
Detailed
design
Construction
supervision/ STRUCT
HVAC
design
Preliminary
design
Detailed
design
Construction
supervision/ HVAC
Preliminary
design
LCC, LCA,
SLP
Detailed
design
Construction
supervision/ Other
ring
planning
planning
Construction
Component
production
Marketing of
product solutions
Requirements
management
Construction
supervision/ DC
Preliminary
design
Other
design
Use, Maintenance
Construction
supervision
Authority control
of construction
3
Requirements
management
Construction
Construction
control
4
Tende- Production
planning
ring
Component
design
Material
supply
Marketing of
product info
Tendering
Procurement
Construction
5
production
delivery
ment
Material
deliveries
Use of the
building
Use
Building
maintenance
Maintenance
Project phase
design
Sender
Sending app.
CAD modeling; LCC, LCA and SLP applications
Receiver
Receiving
application
design applications (CAD modeling)
visualization, collision detection
Information
content
spaces, building elements, building service elements
construction types and equipment types
3D shape, location
materials
(LCC, LCA, and SLP analysis)
change requests
27
3.4.4 Data exchange use case: Manufacturers/ suppliers product
information to design
fig. 3-3
Data exchange — Suppliers product information to design
Building design
Project
Project
managmt.
mgmt. Feasibility 1
study
Project
planning
Marketing
Design
control
2
Authority
control
Authority control
of design
4
Requirements
management
Requirements
management
Design
coordination
Requirements
definition
Design
coordination
Architectural
design
Requirements
definition
Requirements
management
Requirements
management
Detailed
design
Construction
supervision/ ARCH
Structural
design
Preliminary
design
Detailed
design
Construction
supervision/ STRUCT
HVAC
design
Preliminary
design
Detailed
design
Construction
supervision/ HVAC
Preliminary
design
LCC, LCA,
SLP
Detailed
design
Construction
supervision/ Other
ring
planning
planning
Construction
Component
production
Marketing of
product solutions
Requirements
management
Construction
supervision/ DC
Preliminary
design
Other
design
Use, Maintenance
Construction
supervision
Authority control
of construction
3
Requirements
management
Construction
Construction
control
Tendering
Component
design
Material
supply
Marketing of
product info
Procurement
Construction
5
planning
production
delivery
ment
Tendering
Material
deliveries
Use of the
building
Use
Building
maintenance
Maintenance
Project phase
design
Sender
manufacturers and suppliers
Sending app.
product libraries
Receiver
Receiving
application
early design applications
Information
content
building elements, building service elements
3D shape, (location)
specific properties
service life in use condition, service life declaration
cost information
price information
28
3.4.5 Data exchange use case: From design to construction
planning
fig. 3-4
Data exchange — From design to construction planning
Building design
Project
Project
managmt.
mgmt. Feasibility 1
study
Project
planning
Authority
control
Marketing
Design
control
2
Authority control
of design
4
Requirements
management
Requirements
management
Design
coordination
Requirements
definition
Design
coordination
Architectural
design
Requirements
definition
Requirements
management
Requirements
management
Detailed
design
Construction
supervision/ ARCH
Structural
design
Preliminary
design
Detailed
design
Construction
supervision/ STRUCT
HVAC
design
Preliminary
design
Detailed
design
Construction
supervision/ HVAC
Preliminary
design
LCC, LCA,
SLP
Detailed
design
Construction
supervision/ Other
ring
planning
planning
Construction
Component
production
Marketing of
product solutions
Requirements
management
Construction
supervision/ DC
Preliminary
design
Other
design
Use, Maintenance
Construction
supervision
Authority control
of construction
3
Requirements
management
Construction
Construction
control
Tende- Production
planning
ring
Component
design
Material
supply
Marketing of
product info
Tendering
Procurement
Construction
5
production
delivery
ment
Material
deliveries
Use of the
building
Use
Building
maintenance
Maintenance
Project phase
design, construction planning
Sender
designers (arch., structural, building services)
Sending app.
Receiver
construction planners
component designers
Receiving
application
quantity take-off and cost estimation applications
construction planning applications
component design applications
Information
content
building elements, building service elements
3D shape, location
specific properties
29
3.4.6 Data exchange use case: Between project management,
construction and deliveries
fig. 3-5
Data exchange between project management, construction, deliveries
Building design
Project
Project
managmt.
mgmt. Feasibility 1
study
Project
planning
Authority
control
Marketing
Design
control
2
Authority control
of design
4
Requirements
management
Requirements
management
Design
coordination
Requirements
definition
Design
coordination
Architectural
design
Requirements
definition
Requirements
management
Requirements
management
Detailed
design
Construction
supervision/ ARCH
Structural
design
Preliminary
design
Detailed
design
Construction
supervision/ STRUCT
HVAC
design
Preliminary
design
Detailed
design
Construction
supervision/ HVAC
Preliminary
design
LCC, LCA,
SLP
Component
production
Material
supply
Detailed
design
Construction
supervision/ Other
ring
planning
planning
Construction
Marketing of
product solutions
Requirements
management
Construction
supervision/ DC
Preliminary
design
Other
design
Use, Maintenance
Construction
supervision
Authority control
of construction
3
Requirements
management
Construction
Construction
control
Tendering
Component
design
Procurement
Construction
5
planning
production
delivery
ment
Marketing of
product info
Tendering
Material
deliveries
Use of the
building
Use
Building
maintenance
Maintenance
Project phase
construction planning, construction
Sender
project management
Sending app.
project management applications
delivery management applications
Receiver
project management
Receiving
application
project management applications
delivery management applications
Information
content
deliveries, delivery time schedule
requirements for receiving of the delivery: storage, lifting equipment
30
3.4.7 Data exchange use case: General project management
fig. 3-6
Data exchange by project management
Building design
Project
Project
managmt.
mgmt. Feasibility 1
study
Project
planning
Authority
control
Marketing
2
Authority control
of design
Requirements
management
Design
coordination
Project
managmt.
Requirem.
definition
Architectural
design
Project
managmt.
Requirem.
definition
Structural
design
Requirements
management
Requirements
management
Detailed
design
Construction
supervision/ ARCH
Project
managmt.
Preliminary
design
Detailed
design
Construction
supervision/ STRUCT
HVAC
design
Project
managmt.
Preliminary
design
Detailed
design
Construction
supervision/ HVAC
Other
design
Project
managmt.
Construction
Project
managmt.
Component
production
Project
managmt.
Material
supply
Project
managmt.
LCC, LCA,
SLP
Detailed
design
Construction
supervision/ Other
ring
planning
planning
Marketing of
product solutions
Requirements
management
Construction
supervision/ DC
Preliminary
design
Preliminary
design
Use, Maintenance
Construction
supervision
Authority control
of construction
3
Requirements
management
Construction
Construction
control
4
Requirem.
managmt.
Design
coordination
Design
control
Tende- Production
planning
ring
Component
design
Marketing of
product info
Tendering
Procurement
Construction
5
production
delivery
ment
Material
deliveries
Use of the
building
Use
Building
maintenance
Maintenance
Project phase
the whole project
Sender
project management
all actors
Sending app.
project management and time scheduling applications
cost monitoring applications
Receiver
project management
all actors
Receiving
application
project management and time scheduling applications
cost monitoring applications
Information
content
tasks, task decomposition
task sequences, timing
task dependencies
task results
cost monitoring information
31
3.4.8 Data exchange use case: From design and construction to
use and maintenance
fig. 3-7
Data exchange to use and maintenance
Building design
Project
Project
managmt.
mgmt. Feasibility 1
study
Project
planning
Authority
control
Marketing
Design
control
2
Authority control
of design
Construction
4
Authority control
of construction
3
Requirements
management
Requirements
management
Requirements
management
Design
coordination
Requirements
definition
Design
coordination
Architectural
design
Requirements
definition
Requirements
management
Requirements
management
Detailed
design
Construction
supervision/ ARCH
Structural
design
Preliminary
design
Detailed
design
Construction
supervision/ STRUCT
HVAC
design
Preliminary
design
Detailed
design
Construction
supervision/ HVAC
Preliminary
design
LCC, LCA,
SLP
Detailed
design
Construction
supervision/ Other
ring
planning
planning
Construction
Component
production
Marketing of
product solutions
Requirements
management
Construction
supervision/ DC
Preliminary
design
Other
design
Use, Maintenance
Construction
supervision
Construction
control
Tendering
Component
design
Material
supply
Marketing of
product info
Procurement
Construction
5
planning
production
delivery
ment
Tendering
Material
deliveries
Use of the
building
Use
Building
maintenance
Maintenance
Project phase
commissioning of the building
Sender
designers, constructors
Sending app.
design applications, as-built applications
Receiver
users, maintenance
Receiving
application
maintenance applications
LCC applications
Information
content
building maintenance planning information: spaces, building
elements, building service elements; maintenance plans
life cycle information
service life information
32
3.4.9 Data exchange use case: Between use and maintenance
fig. 3-8
Data exchange between use and maintenance
Building design
Project
Project
managmt.
mgmt. Feasibility 1
study
Project
planning
Authority
control
Marketing
Design
control
2
Authority control
of design
Requirements
management
Requirements
management
Design
coordination
Requirements
definition
Design
coordination
Architectural
design
Requirements
definition
Requirements
management
Requirements
management
Detailed
design
Construction
supervision/ ARCH
Structural
design
Preliminary
design
Detailed
design
Construction
supervision/ STRUCT
HVAC
design
Preliminary
design
Detailed
design
Construction
supervision/ HVAC
Preliminary
design
LCC, LCA,
SLP
Component
production
Detailed
design
Construction
supervision/ Other
ring
planning
planning
Construction
Marketing of
product solutions
Tendering
Component
design
Material
supply
Requirements
management
Construction
supervision/ DC
Preliminary
design
Other
design
Use, Maintenance
Construction
supervision
Authority control
of construction
3
Requirements
management
Construction
Construction
control
4
Procurement
Construction
5
planning
production
delivery
ment
Marketing of
product info
Tendering
Material
deliveries
Use of the
building
Use
Building
maintenance
Maintenance
Project phase
building use and maintenance
Sender
owners, service providers, (users)
Sending app.
maintenance planning
fault reporting applications
Receiver
owners, service providers, (users)
Receiving
application
maintenance planning
fault reporting applications
Information
content
fault reporting
service requests
maintenance tasks, timing, execution
33
4.1 Basics
4.1.1 File format
The file format is described in ISO 10303–21. The files are divided into a header
section and a data section:
ISO-10303-21;
HEADER;
/* mandatory headers from ISO 10303-21 header_section_schema, see section 4.2.1 */
keyword(parameter list);
/* DtH headers, see section 4.2.2 */
keyword(parameter list);
ENDSEC;
DATA;
/* entity instances from DtH schema: */
#number = keyword(parameter list);
ENDSEC;
END-ISO-10303-21;
4.1.2 Parameter tokens, units
Parameter lists in DtH files may contain these ISO 10303–21 tokens:
INTEGER
REAL
STRING
ENTITY_NAME
ENUMERATION
LIST
e.g. 1
e.g. 1.50
e.g. 'example'
e.g. #0250
e.g. .STEEL.
e.g. (#1,#2,#3)
All values are measured in following base units and in units derived thereof:
Lengths
Force
Angle
Temperature difference
Weight
Time (duration)
mm
N
°
K
kg
s
(millimeter)
(Newton)
(degree)
(Kelvin)
(kilogram)
(second)
Positive angles move counterclockwise.
Date and time are expressed in strings of the format 'dd.mm.yyyy' and 'hh:mm'.
If optional attributes are omitted, the $ sign appears in the DtH file as a placeholder.
34
4.1.3 Coordinate systems
The global coordinate system is a right-handed Cartesian system with the xy plane
being horizontal and the positive z dimension directed upwards.
Local coordinate systems can be nested. In other words a local coordinate system can
relate to the global system or to another local system.
A local coordinate system is defined by three points within the parent coordinate
system:
KI
KJ
KR
origin of the locale coordinate system
a point at the positive x axis of the locale coordinate system
a point at the first quadrant of the xz plane of the coordinate system
Points in two-dimensional spaces — e.g. contours of cut-outs — carry x and z
coordinates in DtH, unlike IFC where they carry x and y coordinates. Exceptions are
the shapes of cross sections which are defined in the yz plane. The local coordinates
of straight beam-like members are hence oriented with the x axis along the member
center axis. The local y axis of plate-like members is aligned to the direction of the
plate depth.
4.1.4 Version control
All DtH entities provide a NR attribute which serves as a unique identifier. It is
sufficient to ensure uniqueness per type of entity. The value of NR has to be preserved
throughout every modification of the STEP file until an entity instance is deleted.
Furthermore there is a DATE attribute which denotes the day of last modification of
the entity instance. Whenever any other attribute of an entity instance is modified, the
DATE attribute has to be updated.10
4.1.5 External references and component catalogs
Numerous attributes denote short names or descriptors that should be machine
readable. Such attributes are strings of a precisely defined form. Several classification
systems provide such descriptor definitions, e.g. DIN standards that are concerned
with material properties. A special German classification system is the Bauteilkatalog
Holz (timber building parts catalog) which was developed by the DGfH along with
DtH.
The referred classification system is denoted in a string attribute by a prefixed source
symbol. The prefix is delimited by a colon. The prefix symbols are declared by a
SOURCES record. Example:
A header line
SOURCES(('B:BTK1.0','D4047:DIN 4074-2'));
introduces two classification sources. An attribute
'B:BTK=01.RNA;TG=DIN1052;D=6;L=260;OB=GV;TFK=III'
denotes an galvanized ring-shank nail of the size 6mm × 260mm and capacity
10
Exception: The date must not be modified if reference attributes are renumbered during re-ordering
of STEP file records.
35
class III, while the most often used German timber grade would be denoted as
'D4047:NH II'.
A special case are the attributes AVA_POSITION.STLB and AVA_POSITION.STLNR
which reference keys according to the German classification system Standardleistungsbuch STLB without need for a header entry and string prefixes. Another
special kind of reference is used in MEMBER_LTYP which may contain the file name of
a DXF file with member geometry data.
4.2 General project data
4.2.1 Standard ISO 10303–21 headers
The following file headers are defined by the ISO 10303–21 header_section_schema.
ENTITY file_description;
description
: LIST [1:?] OF STRING (256);
implementation_Level : STRING (256);
END_ENTITY;
ENTITY file_name;
name
time_stamp
author
organization
preprocessor_version
originating_system
authorisation
END_ENTITY;
:
:
:
:
:
:
:
ENTITY file_schema;
schema_identifiers
END_ENTITY;
: LIST [1:?] OF STRING (256);
STRING (256);
STRING (256);
LIST [1:?] OF STRING (256);
LIST [1:?] OF STRING (256);
STRING (256);
STRING (256);
STRING (256); -- can't decide on en-us or en-gb…
The schema identifier of the current version of DtH is 'DtH 2.0'.
4.2.2 DtH headers
ENTITY OWNER;
OWNER_NAME
END_ENTITY;
: STRING;
-- building owner
ENTITY BUILDING_SITE;
BS
: STRING;
END_ENTITY;
-- location of site (e.g. postal address)
ENTITY ARCHITECT;
ARCH
: STRING;
END_ENTITY;
-- name and address of architect
ENTITY SPECIFICATION;
SPECI
: STRING;
END_ENTITY;
-- description of the projected building
ENTITY SOURCES;
SOURCE_STRINGS : LIST OF STRING;
END_ENTITY;
-- external references (see section 4.1.5)
The DtH spec adds these entities to the ISO 10303–21 header_section_schema, not
to the DtH schema. Hence they appear in the HEADER of a STEP file, unlike all
following entities that belong to the DATA section.
36
4.3 Common classes
4.3.1 Generic classes
ENTITY STRING_VALUE;
NR
: OPTIONAL INTEGER;
DATE
: OPTIONAL INTEGER;
VALUE1 : STRING;
END_ENTITY;
ENTITY INTEGER_VALUE;
NR
: OPTIONAL INTEGER;
DATE
: OPTIONAL INTEGER;
VALUE1 : INTEGER;
END_ENTITY;
ENTITY REAL_VALUE;
NR
: OPTIONAL INTEGER;
DATE
: OPTIONAL INTEGER;
VALUE1 : REAL;
END_ENTITY;
These entities are provided for vendor-specific extensions, e.g. as reference to inhouse libraries of prefabricated components or for 3D visualization parameters.
4.3.2 Groupings
ENTITY STRUCTURE;
NR
: OPTIONAL INTEGER;
DATE
: OPTIONAL STRING;
TYP
: STRUCTURE_TYP;
BEZ
: OPTIONAL STRING;
ENT
: LIST OF SEL_ALL_ENT;
END_ENTITY;
-- kind of group, see below
-- designation of group
-- group members
TYPE STRUCTURE_TYP = ENUMERATION OF
(CONSTRUCTION,
-- group of detailing data
DESIGN,
-- group of architectural data
STRUCTURAL_ANALYSIS, -- group of structural data
PRODUCTION,
-- group of fabrication data
AVA,
-- group of bid/bill data
USER,
-- arbitrary group; provide context in STRUCTURE.BEZ
STRUCTURAL,
-- group of load-bearing members
NON_STRUCTURAL);
-- group of non-bearing members
END_TYPE;
STRUCTURE allows to group arbitrary entities into logical groups. Note that there are
entities for special groups, e.g. BUILDING_PART or DESIGN_CALCULATION. Hence
STRUCTURE should only be used if none of the special group entities fits.
ENTITY STRUCTURE_LOCATION;
NR
: OPTIONAL INTEGER;
DATE
: OPTIONAL STRING;
STRCT
: STRUCTURE;
KI
: SELECT_VERTEX_XYZ;
KJ
KR
END_ENTITY;
-- local coordinate system of group relative to
-the global coordinate system
--
Building components that are grouped by a STRUCTURE can be placed collectively
into the building geometry by STRUCTURE_LOCATION once or multiple times.
37
4.3.3 Geometry
ENTITY VERTEX;
NR
: OPTIONAL
DATE
: OPTIONAL
X
: REAL;
Y
: OPTIONAL
Z
: REAL;
ALPHA
: OPTIONAL
END_ENTITY;
INTEGER;
STRING;
-REAL; --REAL; --
coordinate
coordinate
coordinate
enclosing angle
By convention of DtH, two-dimensional geometric objects are to be defined in an xz
plane. IFC uses xy coordinates in two-dimensional space.
TYPE XYZ_POINT = ARRAY [0:2] OF REAL;
END_TYPE;
TYPE SELECT_VERTEX_XYZ = SELECT (VERTEX, XYZ_POINT);
END_TYPE;
This select data type offers the alternative between references to vertexes and direct
insertion of coordinate values into parameter lists.
ENTITY POLYLINE;
NR
: OPTIONAL INTEGER;
DATE
: OPTIONAL STRING;
V
: LIST OF VERTEX;
END_ENTITY;
A polyline is a sequence of n–1 lines and arcs between n points defined by VERTEX
entities. Arcs are distinguishable from straight lines by a non-zero angle given in the
endpoint VERTEX.
4.3.4 Grids
ENTITY GRID;
NR
: OPTIONAL INTEGER;
DATE
: OPTIONAL STRING;
BEZ
: OPTIONAL STRING;
TYP
: GRID_TYP;
GL
: LIST OF GRID_LINE;
END_ENTITY;
TYPE GRID_TYP = ENUMERATION OF
(ACHSRASTER,
BANDRASTER);
END_TYPE;
-- label
-- kind of grid, see below
-- axial grid
-- strip grid
Axial grids usually comprise center lines of building elements. Strip grids consist of
boundaries of longish building elements. IFC does not differentiate these types of
grids.
38
ENTITY GRID_LINE;
NR
: OPTIONAL
DATE
: OPTIONAL
BEZ
: OPTIONAL
TYP
: GL_TYP;
KI
: OPTIONAL
KJ
: OPTIONAL
KR
: OPTIONAL
PL1
: OPTIONAL
PL2
: OPTIONAL
A1
: OPTIONAL
A2
: OPTIONAL
A3
: OPTIONAL
N1
: INTEGER;
N2
: OPTIONAL
N3
: OPTIONAL
S1
: OPTIONAL
S2
: OPTIONAL
S3
: OPTIONAL
END_ENTITY;
INTEGER;
STRING;
STRING;
SELECT_VERTEX_XYZ;
SELECT_VERTEX_XYZ;
SELECT_VERTEX_XYZ;
POLYLINE;
POLYLINE;
GL_ABSTAND;
GL_ABSTAND;
GL_ABSTAND;
INTEGER;
INTEGER;
STRING;
STRING;
STRING;
-----------------
label (visible labels in attrib. S1…S3)
kind of grid line, see below
KI…KR = local coordinate system of
grid relative to global coordinate system
PL1…PL2 = root polyline
A1…A3 = distances
N1…N3 = number of repetitions or
of grid divisions
S1…S3 = names of the root polyline of
each dimension; names of subsequent
grid lines are incrementally derived
The semantics of PL1…N3 depend on GL_TYP.
TYPE GL_TYP = ENUMERATION OF
(RECTANGULAR, -- composed by repetition of 2…3 orthogonal lines
POLYGONAL,
-- composed by repetition of a polygon
CIRCULAR,
-- composed of repeated segments of concentric circles
II_ORDER);
-- grid on a quadric surface
END_TYPE;
TYPE GL_ABSTAND = SELECT (REAL_TYPE, XYZ_POINT, VERTEX);
END_TYPE;
While DtH allows for spatial grids, e.g. 3D rectangular grids or even warped 2nd order
grids, IFC contains only planar grids: rectangular, radial, and triangular grids.
4.3.5 Other defined data types
TYPE REAL_TYPE = REAL;
END_TYPE;
TYPE INTEGER_TYPE = INTEGER;
END_TYPE;
TYPE STRING_TYPE = STRING;
END_TYPE;
TYPE SEL_ALL_ENT = SELECT
(INTEGER_VALUE, REAL_VALUE, STRING_VALUE, VERTEX, POLYLINE, GRID, GRID_LINE,
STRUCTURE, STRUCTURE_LOCATION, BUILDING_PART, OPENING, FOUNDATION, MATERIAL,
CROSS_SECTION, COMPOSITE_CROSS_SECTION, DESIGN_CALCULATION, NODE,
BOUNDARY_CONDITION, ELEMENT, ELASTIC_SUPPORT, ELEMENT_NODE_CONNECTIVITY,
ELEMENT_ECCENTRICITY, ACTION, ACTION_COMBINATION_RULE, ACTION_COMBINATION,
NODAL_ACTION, ELEMENT_ACTION, NODAL_REACTION, ELEMENT_REACTION, MEMBER, SURFACE,
MITER_SQUARE, CUTOUT, CUTOUT_TIMBER, HOLE, SIGNATURE, COLD_BEND, MEMBER_LOCATION,
BOLT, WELD, GLUE, TIMBER_CONNECTION, CONNECTION, AVA_TITEL, AVA_POSITION);
END_TYPE;
39
4.4 Architectural model
4.4.1 Building sections, floors
ENTITY BUILDING_SECTION;
NR
: OPTIONAL INTEGER;
DATE
: OPTIONAL STRING;
BEZ
: STRING;
BS_TEXT : OPTIONAL LIST OF STRING_VALUE;
END_ENTITY;
ENTITY FLOOR;
NR
: OPTIONAL INTEGER;
DATE
: OPTIONAL STRING;
BEZ
: STRING;
FL_TEXT : OPTIONAL LIST OF STRING_VALUE;
END_ENTITY;
-- label, e.g. 'east wing'
-- descriptive texts
-- label, e.g. 'ground floor'
-- descriptive texts
There are select data types that allow simple strings as alternative to the above
entities:
TYPE SEL_SECT
END_TYPE;
= SELECT (STRING_TYPE, BUILDING_SECTION);
TYPE SEL_FLOOR = SELECT (STRING_TYPE, FLOOR);
END_TYPE;
The assignment of building parts to building sections and floors happens in DtH by
specification of building section and floor as attributes of building parts.
4.4.2 Building parts
ENTITY BUILDING_PART;
NR
: OPTIONAL
DATE
: OPTIONAL
PROD_SPEC
: OPTIONAL
TYP1
: BP_TYP1;
TYP2
: OPTIONAL
TYP3
: OPTIONAL
INTEGER;
STRING;
STRING_VALUE;
BP_TYP2;
BP_TYP3;
-----
product identifier
kind of building part
external part?
load bearing part?
-- placement in global coordinates
KI
: OPTIONAL SELECT_VERTEX_XYZ;
KJ
KR
-- location
FLOOR
SECTION
: OPTIONAL SEL_FLOOR;
: OPTIONAL SEL_SECT;
-- geometry
CONTOUR
THICK
ALIGN
CONTOUR_TEXT
FABRIC
:
:
:
:
:
-- components
PARTS
OPEN
: OPTIONAL LIST OF MEMBER_LOCATION;
: OPTIONAL LIST OF OPENING;
LIST OF POLYLINE;
OPTIONAL REAL;
OPTIONAL BP_ALIGN;
OPTIONAL LIST OF STRING_VALUE;
OPTIONAL LIST OF BP_FABRIC;
-- values for structural analysis
AXIAL_STIFF
: OPTIONAL REAL;
BENDING_STIFF : OPTIONAL REAL;
SHEAR_STIFF
: OPTIONAL REAL;
STAT_TEXT
: OPTIONAL STRING_VALUE;
-- description conc. structural analysis
40
-- special zones of the building part
SPECIAL_POLY : OPTIONAL LIST OF POLYLINE;
SPECIAL_TEXT : OPTIONAL LIST OF STRING_VALUE;
-- physical properties
F
: OPTIONAL STRING;
K
: OPTIONAL REAL;
RW
: OPTIONAL REAL;
END_ENTITY;
-- fire resistance classification
-- thermal transmittance in W/m²K (U)
-- sound transmission loss in dB
TYPE BP_TYP1
END_TYPE;
= ENUMERATION OF (WALL, ROOF, SLAB, COLUMN, GIRDER);
TYPE BP_TYP2
END_TYPE;
= ENUMERATION OF (EXTERNAL, INTERNAL);
TYPE BP_TYP3
END_TYPE;
= ENUMERATION OF (STRUCTURAL, NON_STRUCTURAL);
TYPE BP_ALIGN
END_TYPE;
= ENUMERATION OF (N, M, P);
TYPE BP_FABRIC = SELECT (SURFACE, CUTOUT, CUTOUT_TIMBER, HOLE, SIGNATURE);
END_TYPE;
The geometry of a wall can be specified in three ways:
• by one polygon in CONTOUR, wall thickness in THICK, alignment in y
direction relative to the polygon in ALIGN (P = thickness in positive y
direction, N = thickness in negative y direction, M = centered);
• by two polygons in CONTOUR for inner surface and outer surface;
• by more than two polygons in CONTOUR for inner and outer surface and all
other boundaries.
CONTOUR_TEXT may provide designations for the wall surfaces and edges like 'ridge',
'eaves', 'verge'. The number of strings in the CONTOUR_TEXT list depends on how
CONTOUR is given.
The components of a wall are members and openings — except for bore holes,
notches, and the like for which the FABRIC (fabrication) attribute exists. Note that
MEMBER_LOCATION entities are located relative to the global coordinate system while
OPENING entities are placed relative to the local coordinate system of the
BUILDING_PART.
4.4.3 Openings
ENTITY OPENING;
NR
: OPTIONAL INTEGER;
DATE
: OPTIONAL STRING;
PROD_SPEC : OPTIONAL STRING_VALUE;
TYP1
: OP_TYP1;
TYP2
: OPTIONAL OP_TYP2;
TYP3
: OPTIONAL OP_TYP3;
TYP4
: OPTIONAL OP_TYP4;
KI
KJ
KR
CONTOUR
: LIST OF POLYLINE;
END_ENTITY;
----------
product identifier
kind of opening
external opening?
door/window panel operation
operation direction relative to y
placement in coordinates of the
BUILDING_PART local coordinate
system
geometry
TYPE OP_TYP1 = ENUMERATION OF (DOOR, WINDOW, STAIRS_X, CHIMNEY, OTHER);
END_TYPE;
41
TYPE OP_TYP2 = ENUMERATION OF (EXTERNAL, INTERNAL);
END_TYPE;
TYPE OP_TYP3 = ENUMERATION OF (FIXED, LEFT, RIGHT, LR, LEFT_P, RIGHT_P,
LR_P, TOP, BOTTOM, V_PIVOT, H_PIVOT, V_SLIDE, H_SLIDE, LOUVRE, OTHER);
END_TYPE;
TYPE OP_TYP4 = ENUMERATION OF (POS, NEG);
END_TYPE;
The CONTOUR of an opening is constructed of polylines as described for the
BUILDING_PART entity.
4.4.4 Stairs
ENTITY STAIRS;
NR
: OPTIONAL INTEGER;
DATE
: OPTIONAL STRING;
BEZ
: OPTIONAL STRING;
PROD_SPEC : OPTIONAL LIST OF STRING_VALUE;
TYP1
: ST_TYP1;
TYP2
: ST_TYP2;
FLOOR
: OPTIONAL SEL_FLOOR;
SECTION
WALKLINE : POLYLINE;
STEPS
: OPTIONAL INTEGER;
GOING
: OPTIONAL REAL;
RISE
: OPTIONAL REAL;
ML
: OPTIONAL LIST OF MEMBER_LOCATION;
BP_O
: OPTIONAL BUILDING_PART;
BP_U
: OPTIONAL BUILDING_PART;
OPEN
: OPTIONAL OPENING;
END_ENTITY;
---------------
label
product identifier
kind of construction
geometric type
location
location
walking line
number of risers
tread length
riser height
components
upper support
lower support
opening within BP_O
TYPE ST_TYP1 = ENUMERATION OF (CONCRETE, CARRIAGE,
STRINGER, CANTILEVER, HANGING, BOLTS, OTHER);
END_TYPE;
TYPE ST_TYP2 = ENUMERATION OF (STRAIGHT, RECT, ANGLE, CURVED, SPIRAL);
END_TYPE;
4.4.5 Foundations
ENTITY FOUNDATION;
NR
: OPTIONAL INTEGER;
DATE
: OPTIONAL STRING;
BEZ
: OPTIONAL STRING;
PROD_SPEC : OPTIONAL STRING_VALUE;
TYP
: FOU_TYP;
KI
KJ
KR
SEC
CONTOUR
: LIST OF POLYLINE;
THICK
: OPTIONAL REAL;
FABRIC
: OPTIONAL LIST OF FOU_FABRIC;
ASXO
: OPTIONAL REAL;
ASYO
: OPTIONAL REAL;
ASXU
: OPTIONAL REAL;
ASYU
: OPTIONAL REAL;
AS_TEXT
: OPTIONAL STRING;
STAT_TEXT : OPTIONAL STRING_VALUE;
END_ENTITY;
-----
label
product identifier
kind of foundation
placement in global coordinates
-- location
-- geometry
-- maximum upper reinforcement
-- maximum lower reinforcement
-- description of reinforcement
-- description conc. structural analysis
TYPE FOU_TYP = ENUMERATION OF (SINGLE, STRIP, SPREAD);
END_TYPE;
42
TYPE FOU_FABRIC = SELECT (SURFACE, CUTOUT, HOLE, SIGNATURE);
END_TYPE;
4.4.6 Comparison to IFC
IFC 2x2 already provide extensive support for architectural design. The respective
entities reside mainly in the Interoperability layer, IfcSharedBldgElements schema.
4.5 Structural analysis model
4.5.1 Materials
ENTITY MATERIAL;
NR
DATE
BEZ
: OPTIONAL INTEGER;
: OPTIONAL STRING;
: OPTIONAL STRING; -- short name according to a classification
-- general properties
E_P
: OPTIONAL
E_S
: OPTIONAL
G
: OPTIONAL
RHO
: OPTIONAL
U
: OPTIONAL
ALPHA_S
: OPTIONAL
REAL;
REAL;
REAL;
REAL;
REAL;
REAL;
---------
elastic modulus along the grain
elastic modulus across the grain
shear modulus
specific gravity
moisture content, in %
shrinkage and swelling: dimensional change
coefficient in % per 1% change in moisture
content
-- allowable stresses
ZUL_SIGMA_B
: OPTIONAL
ZUL_SIGMA_ZP
: OPTIONAL
ZUL_SIGMA_ZS
: OPTIONAL
ZUL_SIGMA_DP
: OPTIONAL
ZUL_SIGMA_DS1
: OPTIONAL
ZUL_SIGMA_DS2
: OPTIONAL
ZUL_TAU_A
: OPTIONAL
ZUL_TAU_Q
: OPTIONAL
ZUL_TAU_T
: OPTIONAL
REAL;
REAL;
REAL;
REAL;
REAL;
REAL;
REAL;
REAL;
REAL;
----------
bending stress along the grain
tensile stress along the grain
tensile stress across the grain
compressive stress along the grain
compressive stress across the grain
ditto, larger deformation accepted
shearing stress (splitting along the grain)
shear stress (under transverse load)
torsional stress
-- properties of wood-based panels
LABFU
: OPTIONAL REAL; -- number of plies in plywood
PND
: OPTIONAL REAL; -- nominal thickness
-- elastic modulus along the face grain
E_PXY
: OPTIONAL REAL; -- out-of-plane bending
E_PXZ
: OPTIONAL REAL; -- in-plane bending/ compression/ tension
-- elastic modulus across the face grain
E_SXY
: OPTIONAL REAL; -- out-of-plane bending
E_SXZ1
: OPTIONAL REAL; -- in-plane bending/ compression/ tension
E_SXZ2
: OPTIONAL REAL; -- in-plane compression/ tension
-- shear modulus
G_XY
: OPTIONAL REAL; -- out-of-plane bending (rolling shear)
G_XZ
: OPTIONAL REAL; -- in-plane bending (shear through thickness)
-- allowable stresses of wood-based
ZUL_SIGMA_B_PXZ : OPTIONAL REAL;
ZUL_SIGMA_B_SXZ : OPTIONAL REAL;
ZUL_SIGMA_B_PXY : OPTIONAL REAL;
ZUL_SIGMA_B_SXY : OPTIONAL REAL;
ZUL_SIGMA_Z_PX : OPTIONAL REAL;
ZUL_SIGMA_Z_SX : OPTIONAL REAL;
ZUL_SIGMA_D_PX : OPTIONAL REAL;
ZUL_SIGMA_D_SX : OPTIONAL REAL;
ZUL_SIGMA_D_PZ : OPTIONAL REAL;
ZUL_SIGMA_D_SZ : OPTIONAL REAL;
ZUL_TAU_PZX
: OPTIONAL REAL;
ZUL_TAU_SZX
: OPTIONAL REAL;
ZUL_TAU_PYX
: OPTIONAL REAL;
ZUL_TAU_SYX
: OPTIONAL REAL;
43
panels
-- in-plane bending, stress along the grain
-- in-plane bending, stress across the grain
-- out-of-plane bending, stress along the grain
-- out-of-plane bending, stress across the grain
-- in-plane tension along the grain
-- in-plane tension across the grain
-- in-plane compression along the grain
-- in-plane compression across the grain
-- out-of-plane compression along the grain
-- out-of-plane compression across the grain
-- in-plane shear, component along the grain
-- in-plane shear, component across the grain
-- rolling shear, component along the grain
-- rolling shear, component across the grain
-- allowable bearing stress on bolt holes (intrados pressure)
ZUL_SIGMA_PL
: OPTIONAL REAL; -- along the grain
ZUL_SIGMA_SL
: OPTIONAL REAL; -- across the grain
END_ENTITY;
The terms “along the grain”/ “across the grain” are used in in-line comments above
for shortness. The terms “parallel to the grain” and “perpendicular to the grain” are
more common and more accurate. Sometimes “fiber” is used instead of “grain”, or a
“strength axis” of panels is referred to. German design codes symbolize these terms
and the term “at an angle to the grain” by indexed glyphs ||, ⊥, and Ë while the
European design code uses the indexes 0 (null), 90, and α.
Furthermore, the direction of the load that generates stresses is usually referred to
where mechanical properties are considered. For solid timber (and for dowel-type
connectors), the terms “axially loaded” and “laterally loaded” are used. The terms
“axially loaded”, “loaded perpendicular to wide faces of lamination”, and “loaded
parallel to wide faces of lamination” are common for glulam.11 For wood-based
panels, the terms “loaded out of plane” and “loaded in plane” are used.
The name provided by BEZ is meant to be machine-readable. Such names are humanreadable in most cases as well. However, in case of a hard-to-read classification
system, an additional attribute for a human-readable clear text name would be helpful.
Such a name attribute could also provide supplemental information not covered by
the classification system, like trade names.
The LABFU attribute may be insufficient to describe some less common types of
plywood. A complete identification requires the number of layers along with the
number of plies.12
The attribute ALPHA_S is actually a mean value, also known as the selected or
weighted dimensional change coefficient cC. This value derives from the according
directed dimensional change coefficients of solid timber, cR (radial to growth ring
grain orientation) and cT (tangential to growth ring orientation). cC is the value of
most practical importance for solid timber and glulam. Wood-based panels would be
11
DtH does not provide this differentiation for glulam, consistent with traditional German design
practice. The differentiation becomes necessary in order to utilize the full load-carrying capacity of
newer high-strength glulam layups.
12
A plywood consists of layers. Each layer consists of one or two plies with grain in the same
direction. A notation common in North America is “number of plies/ number of layers”.
44
better characterized by RLE (relative linear expansion; within panel plane)13 and RTS
(relative thickness swell).
The less significant property “modulus of rupture” is not provided.
4.5.2 Cross sections
ENTITY CROSS_SECTION;
NR
: OPTIONAL INTEGER;
DATE
: OPTIONAL STRING;
TYP
: CS_TYP;
-- section type, see CS_TYP below
DEF
: CS_DEF;
-- used if TYP is one of CCS, PL1, or PL2
BEZ
: OPTIONAL STRING; -- label
-- geometric dimensions and angles; semantics depend
H
: OPTIONAL REAL;
B
: OPTIONAL
T_S
: OPTIONAL REAL;
T_G
: OPTIONAL
R_1
: OPTIONAL REAL;
R_2
: OPTIONAL
R_3
: OPTIONAL REAL;
K
: OPTIONAL
H_2
: OPTIONAL REAL;
H_3
: OPTIONAL
B_2
: OPTIONAL REAL;
B_3
: OPTIONAL
F_1
: OPTIONAL REAL;
F_2
: OPTIONAL
F_3
: OPTIONAL REAL;
T_1
: OPTIONAL
C
: OPTIONAL REAL;
ALPHA_S : OPTIONAL
ALPHA_G : OPTIONAL REAL;
E_Y
: OPTIONAL
E_Z
: OPTIONAL REAL;
ALPHA
: OPTIONAL
on TYP
REAL;
REAL;
REAL;
REAL;
REAL;
REAL;
REAL;
REAL;
REAL;
REAL;
REAL;
-- mechanical section properties
A
: OPTIONAL REAL; -- area
I_Y
: OPTIONAL REAL; -- moment of inertia
I_Z
: OPTIONAL REAL; -- ditto
I_ETA
: OPTIONAL REAL; -- moment of inertia around principal axis
I_XI
I_T
: OPTIONAL REAL; -- torsional moment of inertia
W_YP
: OPTIONAL REAL; -- moment of resistance (max. y coordinate)
W_YN
(min. y coordinate)
W_ZP
(max. z coordinate)
W_ZN
(min. z coordinate)
W_T
: OPTIONAL REAL; -- torsional moment of resistance
C_M
: OPTIONAL REAL; -- resistance to warping torsion
W_PLY
: OPTIONAL REAL; -- plastic moment of resistance
W_PLZ
A_Y
: OPTIONAL REAL; -- area for calculation of shear deflection
A_Z
A_SY
: OPTIONAL REAL; -- area for calculation of shear stress
A_SZ
Y_M
: OPTIONAL REAL; -- position of shear center
Z_M
-- other
G
: OPTIONAL REAL;
G_H
: OPTIONAL REAL;
U
: OPTIONAL REAL;
END_ENTITY;
-- nominal weight per length
-- commercial weight per length
-- circumferential area per length
TYPE CS_DEF = SELECT (CS_DEF_PL, COMPOSITE_CROSS_SECTION);
END_TYPE;
TYPE CS_DEF_PL = LIST OF POLYLINE;
END_TYPE;
13
Strictly spoken, RLE is not a constant but a function of moisture content.
TYPE CS_TYP
(I,
-L,
-U,
-B,
-RU,
-RO,
-M,
-C,
-T,
-Z,
-SO,
-KA,
-KF,
-KQ,
-CCS, -PL1, -PL2); -END_TYPE;
45
= ENUMERATION OF
hot-rolled I steel section
hot-rolled L steel section
hot-rolled U steel section
rectangular section, optionally beveled
circular section, optionally a sector only
circular steel tube section
rectangular steel tube section
cold-rolled or folded C steel section
hot-rolled T steel section
hot-rolled Z steel section
special
hot-rolled steel crane rail section, German type A
hot-rolled steel crane rail section, German type F
hot-rolled steel crane rail section, German type Q
composite cross section, see COMPOSITE_CROSS_SECTION
arbitrary, defined by outer and inner boundary lines
arbitrary cold-rolled steel section, defined by sheet center line
Several attributes and cross section types typical to steel structures were adopted from
PSS because timber structures may contain steel elements as well.
Unlike German design practice, structural performance of plywood panels is often
calculated using effective values of A and I in American practice. These effective
values depend on stress direction relative to grain orientation of the plywood layers.
In DtH, mechanical section properties of CROSS_SECTION are meant to be real values
solely based on geometry, not on material.
Wood-based I beams and other composed sections where effective values of A and I
are required are meant to be described by COMPOSITE_CROSS_SECTION instances.
Effective section properties can easily be computed from real properties of the parts
of a composed cross section. However, a simplified representation of prefabricated I
beams and similar commodity products by one MATERIAL and one CROSS_SECTION
instead of COMPOSITE_CROSS_SECTION is conceivable.
fig. 4-1
Rectangular and circular cross sections
TYP=.B.
TYP=.RU.
46
fig. 4-2
Cross section types
ENTITY COMPOSITE_CROSS_SECTION;
NR
: OPTIONAL INTEGER;
DATE
: OPTIONAL STRING;
CS
: LIST OF CROSS_SECTION;
CS_Y
: LIST OF REAL;
CS_Z
: LIST OF REAL;
CS_ALPHA : LIST OF REAL;
CS_SP
: LIST OF CCS_CS_SP;
CS_MA
: OPTIONAL LIST OF MATERIAL;
V_CS_1
: OPTIONAL LIST OF CROSS_SECTION;
V_CS_2
: OPTIONAL LIST OF CROSS_SECTION;
V_Y
: OPTIONAL LIST OF REAL;
V_Z
WHERE
WK1: SIZEOF(CS) = SIZEOF(CS_Y);
WK2: SIZEOF(CS) = SIZEOF(CS_Z);
WK3: SIZEOF(CS) = SIZEOF(CS_ALPHA);
WK4: SIZEOF(CS) = SIZEOF(CS_SP);
WK5: SIZEOF(CS) = SIZEOF(CS_MA);
WK6: SIZEOF(V_CS_1) = SIZEOF(V_CS_2);
WK8: SIZEOF(V_Y) = SIZEOF(V_Z);
END_ENTITY;
47
-----------
partial cross sections
insertion coordinates
insertion coordinates
insertion angle
insert flipped around z axis
partial materials
connected partial cross sections
connected partial cross sections
coordinates of connections
coordinates of connections
TYPE CCS_CS_SP = ENUMERATION OF (MIRRORED, UNMIRRORED);
END_TYPE;
fig. 4-3
Examples of composed cross sections
4.5.3 Structural analysis
Model layout
The structural analysis model may contain several mechanical systems, each grouping
nodes, elements, loads, and reactions.14 A mechanical system can be three- or twodimensional.
DtH 2.0 contains only linear elements; in other words there are so far no shells,
plates, solids, contact elements, et cetera. Elements connect to nodes. The connections
can be eccentric. Elements can be continuously elastically supported.
Load cases group loads. Load combinations actually group both load cases as well as
reactions. Load combination rules define how load cases come together in a
combination.
For example, “wind” may be a load case, “snow” another one. “Wind ¾ snow”
comprise a load combination. According to the German code DIN 1055-5:06.1975,
the deterministic rules “wind + snow/2” and “wind/2 + snow” may be used. The
14
A node, element, or load could theoretically be part of more than one mechanical system. Practical
reasons stand against that however.
48
results (reactions) of the load combination shall be calculated using the most
unfavorable rule.
Nodal loads and nodal reactions provide references to the according nodes. Likewise,
element loads and element reactions reference their respective elements. One instance
of a load may be associated to multiple nodes or elements and thus can represent
actually a multitude of “real” loads.
fig. 4-4
Hierarchies in the structural analysis model
structural analysis model
│
└─ mechanical systems
│
├─ elements
│
│
│
└─ nodes
│
│
│
└─ boundary conditions
│
└─ load combinations
│
├─ load combination rules
│
│
├─ load cases
│
│
│
└─ loads
│
· nodal loads: forces and displacements
│
· element loads: forces, temperature loads,
│
imperfections
│
└─ reactions (results)
· nodal reactions:
support reactions, node displacements
· element reactions:
internal forces, element displacements
Apart from the references depicted in the following figure, the ELEMENT entity
references MATERIAL and CROSS_SECTION, entities which are shared with the
structural detailing model. Material and cross section of an element may alternatively
be determined by reference to a MEMBER_LOCATION entity of the structural detailing
model. Such a reference also allows for implementation of consistency checks
between the two models.
fig. 4-5
49
DtH entities for structural analysis, simplified EXPRESS-G
Mechanical systems
ENTITY DESIGN_CALCULATION;
NR
: OPTIONAL INTEGER;
DATE
: OPTIONAL STRING;
TYP
: DC_TYP;
BEZ
: OPTIONAL STRING;
EL
: OPTIONAL LIST OF ELEMENT;
AC
: OPTIONAL LIST OF ACTION_COMBINATION;
KI
KJ
KR
END_ENTITY;
--------
dimensionality
label
members
combined loads
placement in global
coordinates
TYPE DC_TYP = ENUMERATION OF
(TWO_DIM,
-- planar structure
THREE_DIM,
-- spatial structure
BEAM_GRID,
-- grid of beams
CONT_BEAM); -- continuous span beam
END_TYPE;
Nodes and boundary conditions
ENTITY NODE;
NR
: OPTIONAL INTEGER;
DATE
: OPTIONAL STRING;
K
BC
: OPTIONAL BOUNDARY_CONDITION;
END_ENTITY;
-- placement
-- supports
50
ENTITY BOUNDARY_CONDITION;
NR
: OPTIONAL INTEGER;
DATE
: OPTIONAL STRING;
ALPHA_X : OPTIONAL REAL;
ALPHA_Y : OPTIONAL REAL;
ALPHA_Z : OPTIONAL REAL;
FX
: OPTIONAL BC_TYP;
FY
: OPTIONAL BC_TYP;
FZ
: OPTIONAL BC_TYP;
MX
: OPTIONAL BC_TYP;
MY
: OPTIONAL BC_TYP;
MZ
: OPTIONAL BC_TYP;
MW
: OPTIONAL BC_TYP;
END_ENTITY;
-- angle between bearing reactions and
-superior coordinate system
--- translational components
-- rotational components
-- warpage
TYPE BC_TYP = SELECT
(BC_FC,
-- free, or rigid constraint
REAL_TYPE,
-- spring coefficient
INTEGER_TYPE); -- coupled with the same degree of freedom of another node,
END_TYPE;
-node number is given as a negative integer number
TYPE BC_FC = ENUMERATION OF (FREE, CONSTRAINED);
END_TYPE;
Structural elements
ENTITY ELEMENT;
NR
: OPTIONAL INTEGER;
DATE
: OPTIONAL STRING;
TYP
: ELEMENT_TYP;
N
: LIST OF EL_N;
K
ALPHA : OPTIONAL REAL;
ML
: OPTIONAL MEMBER_LOCATION;
CS_1
: OPTIONAL CROSS_SECTION;
CS_2
: OPTIONAL CROSS_SECTION;
MAT
: OPTIONAL MATERIAL;
ES
: OPTIONAL ELASTIC_SUPPORT;
END_ENTITY;
TYPE ELEMENT_TYP = ENUMERATION
(BEAM,
-- member
TRUSS,
-- member
TENSION_MEMBER); -- member
END_TYPE;
-- local orientation
-- local orientation
-- cross section at starting point
-- cross section at end point
OF
carries bending moment, transversal and axial force
carries axial force only
carries axial tensile force only
TYPE EL_N = SELECT (NODE, ELEMENT_NODE_CONNECTIVITY, ELEMENT_ECCENTRICITY);
END_TYPE;
– continuous elastic support of an element:
ENTITY ELASTIC_SUPPORT;
NR
: OPTIONAL INTEGER;
DATE
: OPTIONAL STRING;
RI
: RICHTUNG;
-X
: OPTIONAL REAL; -L
: OPTIONAL REAL; -C1
: REAL;
-C2
: OPTIONAL REAL; -D
: OPTIONAL REAL; -END_ENTITY;
direction
start abscissa
length
bedding value at starting point
bedding value at end point
eccentricity
TYPE RICHTUNG = ENUMERATION OF (FX, FY, FZ, MX, MY, MZ, MW);
END_TYPE;
51
– eccentric connection of an element to a node:
ENTITY ELEMENT_ECCENTRICITY;
NR
: OPTIONAL INTEGER;
DATE
: OPTIONAL STRING;
N
: EE_N;
KS
: EE_KS;
EX
: OPTIONAL REAL;
EY
: OPTIONAL REAL;
EZ
: OPTIONAL REAL;
END_ENTITY;
TYPE EE_N = SELECT (NODE, ELEMENT_NODE_CONNECTIVITY);
END_TYPE;
TYPE EE_KS =
(WCS,
-SCS,
-ECS); -END_TYPE;
ENUMERATION OF
world coordinates
coordinates in local coordinate system of DESIGN_CALCULATION
element coordinates
– type of connection of an element to a node:
ENTITY ELEMENT_NODE_CONNECTIVITY;
NR
: OPTIONAL INTEGER;
DATE
: OPTIONAL STRING;
N
: ENC_N;
KS
: ENC_KS;
FX
: OPTIONAL ENC_CON; -- translational components
FY
: OPTIONAL ENC_CON;
FZ
: OPTIONAL ENC_CON;
MX
: OPTIONAL ENC_CON; -- rotational components
MY
: OPTIONAL ENC_CON;
MZ
: OPTIONAL ENC_CON;
MW
: OPTIONAL ENC_CON; -- warpage
END_ENTITY;
TYPE ENC_N = SELECT(NODE, ELEMENT_ECCENTRICITY);
END_TYPE;
TYPE ENC_KS = ENUMERATION OF
(WCS,
-- world coordinates
SCS,
-- coordinates in local coordinate system of DESIGN_CALCULATION
ECS); -- element coordinates
END_TYPE;
TYPE ENC_CON = SELECT
(ENC_CON_E,
-- free or rigid
REAL_TYPE); -- spring coefficient
END_TYPE;
TYPE ENC_CON_E = ENUMERATION OF (FREE, CONSTRAINED);
END_TYPE;
Loads
– load case:
ENTITY ACTION;
NR
: OPTIONAL INTEGER;
DATE : OPTIONAL STRING;
TYP
: ACTION_TYP;
GAMMA : OPTIONAL REAL;
BEZ
: OPTIONAL STRING;
ACT
: LIST OF ACTION_ACT;
END_ENTITY;
-----
semi-probabilistic category
partial safety factor, or arbitrary load factor
label
forces and displacements
52
TYPE ACTION_TYP = ENUMERATION OF
(IMPERFECTION,
-- imperfection
PERMANENT,
-- dead load
VARIABLE,
-- life load
EXTRAORDINARY); -- accidental load
END_TYPE;
TYPE ACTION_ACT = SELECT (NODAL_ACTION, ELEMENT_ACTION);
END_TYPE;
The attributes TYP and GAMMA were adopted from PSS. The German design code for
steel structures has been based on the limit state design method since the early 1990s,
hence these attributes were chosen with partial factor method in mind.
The German design code for timber structures is still based on allowable stresses.15
However, the distinction between dead loads, life loads, and accidental loads is
significant nonetheless. Allowable stresses can be modified according to the kind of
load. Furthermore the ratio between dead loads and live loads is important for the
determination of flexure.
– load combination:
ENTITY ACTION_COMBINATION;
NR
: OPTIONAL INTEGER;
ACR
: OPTIONAL ACTION_COMBINATION_RULE;
ACT
: OPTIONAL LIST OF ACTION; -- list of load cases to combine
PSI
-- list of combination factors
MODE : AC_MODE;
-- mechanical theory
REA
: OPTIONAL LIST OF AC_REA; -- results
END_ENTITY;
TYPE AC_MODE = ENUMERATION OF
(E_TH_I_O,
-- elastic materials, 1st order theory
E_TH_II_O); -- elastic materials, 2nd order theory
END_TYPE;
TYPE AC_REA = SELECT (NODAL_REACTION, ELEMENT_REACTION);
END_TYPE;
– collection of load combination rules:
ENTITY ACTION_COMBINATION_RULE;
NR
: OPTIONAL INTEGER;
ACT
: LIST OF LIST OF ACTION; -- list of mutually exclusive combinations
PSI
: LIST OF LIST OF REAL;
-- list of combination factors
MODE : ACR_MODE;
-- mechanical theory
WHERE
WK1: SIZEOF(ACT) = SIZEOF(PSI);
WK2: SIZEOF(ACT[I]) = SIZEOF(PSI[I]);
END_ENTITY;
TYPE ACR_MODE = ENUMERATION OF
(E_TH_I_O,
-- elastic materials, 1st order theory
E_TH_II_O); -- elastic materials, 2nd order theory
END_TYPE;
15
The national design code is now in the process to be replaced by the Eurocode, or a national
derivative of the Eurocode respectively. The Eurocode is based on limit state design.
53
– nodal forces and displacements:
ENTITY NODAL_ACTION;
NR
: OPTIONAL INTEGER;
N
: LIST OF NODE; -KS
: NA_KS;
-RI
: RICHTUNG;
-TYP
: NA_TYP;
-F_K
: REAL;
-END_ENTITY;
location(s) of occurrence
reference coordinate system
load direction, see definition below ELASTIC_SUPPORT
type of load
load value (characteristic value)
TYPE NA_KS = ENUMERATION OF
(WCS,
TCS); -- coordinates in local coordinate system of DESIGN_CALCULATION
END_TYPE;
TYPE NA_TYP = ENUMERATION OF (FORCE, DISPLACEMENT);
END_TYPE;
– element forces and displacements:
ENTITY ELEMENT_ACTION;
NR
: OPTIONAL INTEGER;
EL
: LIST OF ELEMENT;
KS
: EA_KS;
X
: REAL;
L
: REAL;
RI
: RICHTUNG_2;
TYP
: EA_TYP;
F_K1 : REAL;
F_K2 : OPTIONAL REAL;
END_ENTITY;
---------
location(s) of occurrence
reference coordinate system
start abscissa
length
load direction
type of load
load value (characteristic value) at starting point
load value (characteristic value) at end point
TYPE EA_KS = ENUMERATION OF
(WCS,
WCS_ECS,
-- world coordinates; F_K1 and F_K2 relate to the true element length
SCS,
-- coordinates in local coordinate system of DESIGN_CALCULATION
SCS_ECS); -- ditto; F_K1 and F_K2 relate to the true element length
END_TYPE;
TYPE RICHTUNG_2 = ENUMERATION OF (FX, FY, FZ, MX, MY, MZ, MW, X, Y, Z);
END_TYPE;
TYPE EA_TYP = ENUMERATION OF (FORCE, TEMPERATURE, IMPERFECTION);
END_TYPE;
Results (reactions)
– nodal forces (support reactions) and nodal displacements:
ENTITY NODAL_REACTION;
NR
: OPTIONAL INTEGER;
N
: NODE;
-FX
: OPTIONAL REAL; -FY
: OPTIONAL REAL;
FZ
: OPTIONAL REAL;
MX
: OPTIONAL REAL; -MY
: OPTIONAL REAL;
MZ
: OPTIONAL REAL;
MW
location
translation, or force
rotation, or clamping moment
warping deformation, or warping moment
It depends on the boundary condition of each degree of freedom if the attributes
FX…MW denote a displacement or a force. Generally only displacements are stored
and support reactions have to be calculated using the spring coefficient at the
54
respective degree of freedom. Only if a rigid support is present, the particular value
denotes a force or moment.
– element forces (internal forces) and element displacements (deflections):
ENTITY ELEMENT_REACTION;
NR
: OPTIONAL INTEGER;
EL
: ELEMENT;
X
: REAL;
-TYP
: ER_TYP;
-FX
: OPTIONAL REAL; -FY
: OPTIONAL REAL;
FZ
: OPTIONAL REAL;
MX
: OPTIONAL REAL; -MY
: OPTIONAL REAL;
MZ
: OPTIONAL REAL;
MW
abscissa
type of reaction
deflection, or internal force
rotation, or bending moment
warping deformation, or warping moment
TYPE ER_TYP = ENUMERATION OF
(DEFORMATION,
-- deflection
MEMBER_FORCE); -- internal force
END_TYPE;
IFC 2x2 already provide support for structural analyzing tasks, mainly by the
IfcStructuralAnalysisDomain schema in the Domain layer. Materials and cross
sections are described in the IfcMaterialPropertyResource, IfcProfileResource, and
IfcProfilePropertyResource within the lowest IFC layer. Minor extensions for timber
structures are necessary.
4.6 Structural detailing model
4.6.1 Materials, cross sections
The MATERIAL and CROSS_SECTION classes of the structural analysis model are used
by the structural detailing model as well.
4.6.2 Members
Principles
DtH discerns between configuration and placement of members, i.e. there are
separate objects for member types and for member occurrences.
The member configuration contains a parametric description of the shape. Only raw
shapes are stored; shape modifications are separately added by additional feature
objects (subsection 4.6.3).
55
Member configuration
ENTITY MEMBER;
NR
: OPTIONAL
DATE : OPTIONAL
CS
: OPTIONAL
MAT
: OPTIONAL
PR
: OPTIONAL
PNR
: OPTIONAL
BEZ
: OPTIONAL
LTYP : OPTIONAL
PL1
: OPTIONAL
CATCH : OPTIONAL
C_SEL : OPTIONAL
G
: OPTIONAL
G_H
: OPTIONAL
U
: OPTIONAL
END_ENTITY;
INTEGER;
STRING;
CROSS_SECTION;
MATERIAL;
LIST OF MEMBER_PR;
STRING;
STRING;
MEMBER_LTYP;
POLYLINE;
MEMBER;
MEMBER_C_SEL;
REAL;
REAL;
REAL;
-----------
processing features
position number (alphanumeric label)
descriptor (name, label)
geometry
gluing direction
for cutting into two members
ditto
norm weight
commercial weight
circumferential area
TYPE MEMBER_PR = SELECT
(SURFACE, MITER_SQUARE, CUTOUT, CUTOUT_TIMBER, HOLE, SIGNATURE, COLD_BEND);
END_TYPE;
TYPE MEMBER_LTYP = SELECT
(REAL_TYPE,
-- length
POLYLINE,
-- variant 1: MEMBER.LTYP is the center axis, MEMBER.CS provides
-- profile geometry. First and last point of MEMBER.LTYP differ.
-- variant 2: MEMBER.LTYP is the contour, MEMBER.CS provides
-- thickness. First and last point of MEMBER.LTYP are identical.
STRING_TYPE); -- file name of a DXF file holding explicit 3D member geometry
END_TYPE;
TYPE MEMBER_C_SEL = ENUMERATION OF
(L,
-- left
R); -- right
END_TYPE;
There is a possibility to define two members being cut out of one raw member. The
benefit is optimized utilization of joinery machines. The two parts which are created
by a severing process (CUTOUT_TIMBER, TYP=.T1.) are “caught” by two MEMBER
entities. The attribute CATCH of these members refers to the sawed original member.
C_SEL selects which of the two parts is caught. The attributes CS, MAT, LTYP and PL1
are ignored and must be set to “$”.
fig. 4-6
Cutting a raw member into two
MEMBER 0
with CUTOUT_TIMBER
of TYP = .T1.
MEMBER 1A
MEMBER 1B
with CATCH = MEMBER 0
and C_SEL = .L.
with CATCH = MEMBER 0
and C_SEL = .R.
After a member has been defined by one MEMBER instance, it can be inserted into the
structure by MEMBER_LOCATION multiple times.
56
Placement of members
ENTITY MEMBER_LOCATION;
NR
: OPTIONAL INTEGER;
MEM
: OPTIONAL MEMBER;
ML
: OPTIONAL MEMBER_LOCATION;
PNR
: OPTIONAL STRING;
BEZ
: OPTIONAL STRING;
-----
member configuration
structure superordinate to this member
position number (alphanumeric label)
descriptor (name, label)
-- placement in global coordinates or in local coordinates of superordinate member
KI
KJ
KR
-- offset
LAGE :
ALPHA :
DX1
:
DX2
:
DY
:
DZ
:
between MEMBER_LOCATION local coordinates and MEMBER local coordinates
ML_LAGE;
-- shift from MEMBER center to MEMBER edge
OPTIONAL REAL; -- rotation around MEMBER x axis
OPTIONAL REAL; -- x translation for alignment of the MEMBER start point
OPTIONAL REAL; -- x translation for alignment of the MEMBER end point
OPTIONAL REAL; -- y translation
OPTIONAL REAL; -- z translation
GK
: OPTIONAL REAL;
END_ENTITY;
-- weight
TYPE ML_LAGE = ENUMERATION OF
(NYNZ,
-- NY and NZ
NY,
-- shift in negative
NYPZ,
-- NY and PZ
NZ,
-- shift in negative
M,
-- no shift
PZ,
-- shift in positive
PYNZ,
-- PY and NZ
PY,
-- shift in positive
PYPZ); -- PY and PZ
END_TYPE;
y direction
z direction
z direction
y direction
The attribute ML is set if the member is part of an assembled configuration (if the
member is attached to a superordinate member).
PNR, BEZ, GK are typically only set if the member is a superordinate member (if this
instance of MEMBER_LOCATION represents an assembled unit). Superordinate members
may have an empty MEM attribute.
Translations by DX1 are in fact identical to those by DX2. Only one of these attributes
should be used, otherwise they must be set to the same value. The differentiation
between DX1 and DX2 gives a hint whether the translation serves to align the start
point of the member or its end point.16
16
There is however no hint to which other member surface, grid line, or expansion joint etc. the
member is actually aligned to. Furthermore, the case where no particular alignment was intended is
indistinguishable from cases with intended alignment.
fig. 4-7
57
Alignment of a member by offsets
α = 0 LA = .NYNZ. Dx = 0 Dy = 0 Dz = 0
α = 0 LA = .M. Dx = 0 Dy = 0 Dz = 0
α =-20 LA = .NYNZ. Dx = 0 Dy =-100 Dz = 0
α =-20 LA = .NYNZ. Dx = 0 Dy = 0 Dz = 0
fig. 4-8
DtH entities for structural detailing, simplified EXPRESS-G
assembly
MEMBER_LOCATION
building part
connection
L
L
division
L
MEMBER
L
CROSS_SECTION
MATERIAL
L
SURFACE
COMPOSITE_CROSS_SECTION
HOLE
SIGNATURE
4.6.3 Processing features
Following entities describe
• surface treatment,
• mitering,
• contour out-cutting,
• spatial cutting and severing cuts,
• bore holes and hole patterns,
• signatures (imprints),
• and cold bending of sheet metal
MITER_SQUARE
COLD_BEND
CUTOUT
CUTOUT_TIMBER
58
in a feature-oriented manner. Not only geometry information is provided by the
following entities but also high-level information about the type of feature. This
allows for subsequent modification of these features using specialized CAD modules
and potentially helps to derive NC machine control protocol.
Surface treatment
ENTITY SURFACE;
NR
: OPTIONAL INTEGER;
BEZ : OPTIONAL STRING; -- description
TYP : SURFACE_TYP;
-- process type
D
: OPTIONAL REAL;
-- thickness, penetrated depth, or insertion time
V_PL : OPTIONAL LIST OF POLYLINE; -- geometry of treated area
END_ENTITY;
TYPE SURFACE_TYP= ENUMERATION OF
(PLANING,
-- planing
ROUGHLY_PLANING,
-- rough-planing
PAINTING,
-- brush application
SPRAYING,
-- spray application
DIPPING,
-- dip application
TANK,
-- tank steeping
PRESSURE,
-- boiler pressure impregnation
ALTERNATING_PRESSURE, -- alternating pressure process
VACUUM,
-- vacuum impregnation
BANDAGE,
-- wrapping
INJECTION);
-- injection process
END_TYPE;
If V_PL is omitted, the whole member is to be treated.
Mitering
ENTITY MITER_SQUARE;
NR
: OPTIONAL
DATE
: OPTIONAL
ORT
: MS_ORT;
ALPHA_Y : REAL;
ALPHA_Z : REAL;
END_ENTITY;
INTEGER;
STRING;
-- location
-- angle around local y axis
-- angle around local z axis
TYPE MS_ORT = ENUMERATION OF (BEGINNING_OF_MEMBER, END_OF_MEMBER);
END_TYPE;
fig. 4-9
Definition of miter angles
a y= –40°
x
y
a y= –25°
a z= 42°
z
a z= –19°
There is no explicit definition of positive and negative angles given in the DtH
specification, only an explanation by example as shown in fig. 4-9, which was
derived from PSS.
59
The miter feature was eventually taken out of PSS whereas the CUTOUT entity of PSS
was extended for miters.
Contour out-cutting
ENTITY CUTOUT;
NR
: OPTIONAL INTEGER;
PL
: POLYLINE;
KI
KJ
KR
Y1
: REAL;
Y2
: REAL;
END_ENTITY;
-------
2-dimensional subtrahend contour
placement of the subtrahend contour,
given in local member coordinates
upper y ordinate of subtrahend volume
lower y ordinate of subtrahend volume
A cut-out is a Boolean subtraction of an extruded polyline from a member.
fig. 4-10
Member with cut-out
In PSS, the CUTOUT entity was extended by another attribute that describes by
enumeration whether the cut-out is a miter, a cope, a preparation for welding, an
interior cut-out (i.e. an arbitrarily shaped hole), or an arbitrary exterior cut-out.
Spatial cutting, severing cuts, drilling, other surface processing
ENTITY CUTOUT_TIMBER;
NR
: OPTIONAL INTEGER;
DATE
: OPTIONAL STRING;
TYP
: CT_TYP;
-- type of feature
SUB_TYP : OPTIONAL CT_SUB_TYP;
-- subtype of feature
BEZ
: OPTIONAL STRING;
-- description (artisanal term)
V
: LIST OF VERTEX;
-- geometry by significant points
K
: OPTIONAL LIST OF REAL; -- edge qualities or radii
A
: OPTIONAL LIST OF CT_A; -- plane qualities, entrance and exit of borer
-- SUB_TYP may only be set if TYP = .F1. … .F8.
-- number and meaning of values in V, K, and A depend on the type of feature
-- order of values in V, K, and A is significant
END_ENTITY;
60
TYPE CT_TYP = ENUMERATION OF
-- CUTOUT_TIMBER.V defines…
-- shaping
(F1,
-- …3 points, 1 plane, no edges
F2,
-- …4 points, 2 planes, 1 edge
F3,
-- …6 points, 3 planes, 2 edges
F4,
F5,
F6,
F7,
F8,
-- subtype dependent
-- drilling
B1,
-- …one or more bore holes
B2,
-- …one or more pocket holes
B3,
-- …a keyway for a ring connector
-- severing
T1,
-- …3 points of the dividing plane
-- marking
O1,
-- …2 points of a marker line (chalk line or keyway)
-- planing
O2); -- …n points of an area that is to be planed
END_TYPE;
TYPE CT_SUB_TYP = ENUMERATION OF
(ALLGEMEIN,
-- arbitrary shape
ABGRATUNG,
-- edge cut
KERVE,
-- bird’s mouth, perpendicular to member axis
SCHLEIFKERVE,
-- bird’s mouth
BLATT,
-- scarf
FALZ,
-- rabbet
GRAT,
-- ridge, e.g. on a hip rafter
KEHLE,
-- chase, e.g. on a valley rafter
HEXENSCHNITT,
-- end face of hip rafter or valley rafter towards eaves
FIRSTBLATT,
-- scarf to join rafters at the ridge
AUSBLATTUNG,
-- cogging, seating
KLAUENKERVE,
-- cogging, seating
ZAPFENLOCH,
-- mortise
NUT,
-- groove, dado
ZAPFEN,
-- tenon (with 2 shoulders)
ZAPFEN_ABGESETZT, -- stub tenon (tenon with 3…4 shoulders)
ZAPFEN_GEDREHT,
-- stub tenon, not parallel to member side faces
VERSATZ,
-- stepped joint: strut end
VERSATZ_KERVE,
-- stepped joint: seating
GERBER,
-- splayed scarf
HAKENBLATT);
-- splayed and tabled scarf
END_TYPE;
TYPE CT_A = ENUMERATION OF
-- quality of cut planes
(AE0,
-- the plane is preserved
AE1,
-- the plane may be destroyed at the edges
AE2,
-- the plane may be destroyed
-- quality of bore holes
AB0,
-- unspecified
AB1,
-- drill entry must be splinter-free
AB2,
-- drill exit must be splinter-free
AB3,
-- AB1 and AB2
AB4,
-- hole is mechanically prepared as a pocket hole and manually finished
-- as a drilled-through hole
AB5); -- AB1 and AB4
END_TYPE;
The CUTOUT_TIMBER entity focuses on processing of straight work pieces with
originally rectangular cross section. The working planes are defined by intersection
points. High-level type information is provided to allow CAD software to edit the
processing features by parametric routines.
61
The shape parameters (intersection points) actually comprise a face based surface
model (an open faceted B-rep) with some unique characteristics:
• A limited set of possible face topologies is supported. The face topology is
explicitly given by CUTOUT_TIMBER.TYP.
• Depending on the topology type, only a subset of all vertices are stored.
Missing vertices have to be reconstructed by receiving applications based on
the feature information and on the raw shape of the member before feature
creation.
• No edges and faces are stored. Their topology and geometry is to be derived
from vertices and the feature topology type information.
• Since a fixed order of sequence of vertices, edges, and faces is implied, it is
easy to address selected edges and faces within the surface model. This is
used to attach information about manufacturing quality to individual edges
and faces.
There is some overlapping between CUTOUT_TIMBER and processing entities inherited
from PSS (MITER_SQUARE, CUTOUT, HOLE). This redundancy was accepted in order to
support steel members by DtH in a limited way, preserving similarity to PSS.
The CUTOUT_TIMBER.A attribute allows for appropriate selection of processing tool
and speed when NC code is generated, according to the desired quality of cuts and
holes.
fig. 4-11
CUTOUT_TIMBER, type F1: a single cut
.F1. two times
fig. 4-12
CUTOUT_TIMBER, type F2: two cuts
.F2. two times
62
fig. 4-13
CUTOUT_TIMBER, type F3: three cut planes, meeting in two edges
fig. 4-14
CUTOUT_TIMBER, type F4: three cut planes, meeting in three edges
fig. 4-15
CUTOUT_TIMBER, type F5: four cut planes — type F6: five cut planes
for mortises and grooves — type F7: tenons
fig. 4-16
CUTOUT_TIMBER, type F8: polygonal intersection
stepped joint
strut
splayed and tabled scarf
seating
63
Circular holes, hole patterns
ENTITY HOLE;
NR
: OPTIONAL
DATE
: OPTIONAL
V
: OPTIONAL
TYP
: OPTIONAL
D
: OPTIONAL
T
: OPTIONAL
ALPHA_E : OPTIONAL
KI
: OPTIONAL
KJ
: OPTIONAL
KR
: OPTIONAL
END_ENTITY;
INTEGER;
STRING;
LIST OF VERTEX;
-- for hole patterns: placements of holes
HOLE_TYP;
-- type of hole
REAL;
-- diameter
REAL;
-- depth of pocket hole, thread, or countersink
REAL;
-- angle of countersink or thread end
SELECT_VERTEX_XYZ; -- placement of the hole or of the
SELECT_VERTEX_XYZ; -hole pattern, given in local
SELECT_VERTEX_XYZ; -member coordinates
TYPE HOLE_TYP = ENUMERATION OF
(DRILLING,
-- bore hole
PUNCHING,
-- punched hole
FLAME_DRILLING,
-- autogenous drilling
TAPPING,
-- threaded hole
CENTRE_DRILLING, -- center punch
COUNTERSINKING); -- pocket hole or countersink
END_TYPE;
fig. 4-17
Hole pattern
Multiple HOLE instances may be needed for one actual hole according to the
fabrication steps. E.g. a pocket hole, a countersink, and a thread comprise a threaded
pocket hole. The technologic sequence is however not indicated.
Oblong holes and prismatic holes are not covered by HOLE but by CUTOUT.
The HOLE entity of the current PSS specification also differentiates whether a thread
is left- or right-handed and whether the hole coordinates relate to the original form of
a workpiece or to its form after cold-bending.
Signatures (imprints)
ENTITY SIGNATURE;
NR
: OPTIONAL INTEGER;
H
: OPTIONAL REAL;
TEXT : STRING;
KI
KJ
KR
END_ENTITY;
-- text height
-- text content
-- placement relative to the local member coor-dinate system
--
64
In PSS, a signature can alternatively be represented by a list of polylines instead of a
character string.
fig. 4-18
Member with signature
Cold bending of sheet metal
ENTITY COLD_BEND;
NR
: OPTIONAL INTEGER;
KI
KJ
KR
ALPHA : REAL;
R
: REAL;
END_ENTITY;
fig. 4-19
------
start point
end point
reference point
bending angle
bending radius
Cold bent sheet metal
4.6.4 Connections
Following entities describe
• standard metal fasteners like bolts and nails,
• welded joints of steel parts,
• glued joints,
• arbitrary mechanical fasteners.
The first few entities in this subsection describe the type and configuration of
fasteners and joints used in a project. The last entity in this subsection, entity
CONNECTION, represents the physical instances of these fasteners and joints. This
65
allows to define e.g. one type of BOLT once and to insert it multiple times at different
locations using CONNECTION.
Several entities and attributes typical to connections in steel structures were adopted
from PSS because timber structures may contain steel elements as well.
Bolts, nails, and similar fasteners
Two main possibilities to exchange information about fastener types exist:
• Explicit specification of the various geometric and mechanic fastener
properties, or
• exchange of a standard fastener designation, recognized by all receiving
applications.
The latter was determined as the preferred method, and a classification and notation
system for materials and components used in German timber construction practice
was issued by DGfH (“Bauteilkatalog Holz”). For example, a ringed shank nail could
be specified by the name BTK=01.RNA;TG=DIN1052;D=6;L=260;OB=GV;TFK=III.
This example of a standardized designation contains the product subclass, technical
standard, size, surface protection, and capacity class of the fastener.
ENTITY BOLT;
NR
: OPTIONAL INTEGER;
DATE
: OPTIONAL STRING;
-- labels
BEZ1
BEZ2
BEZ3
TYP
VF
(descriptors)
: LIST OF STRING;
: OPTIONAL LIST OF LIST OF STRING;
: OPTIONAL LIST OF STRING;
: OPTIONAL BOLT_TYP;
: OPTIONAL BOLT_VF;
------
parts on side of the bolt head
parts between connected members
parts on side of the nut
kind of fastener, see below
bored with clearance (play)
-- mechanical properties
ASP
: OPTIONAL REAL;
MY
: OPTIONAL REAL;
FV
: OPTIONAL REAL;
-- stress area
-- friction coefficient
-- pre-stress force
-- dimensions
K
: OPTIONAL
D1
: OPTIONAL
D2
: OPTIONAL
D3
: OPTIONAL
D4
: OPTIONAL
D5
: OPTIONAL
ALPHA_K : OPTIONAL
LN
: OPTIONAL
LK_MIN : OPTIONAL
LK_MAX : OPTIONAL
LR
: OPTIONAL
LH
: OPTIONAL
LG
: OPTIONAL
LS
: OPTIONAL
ALPHA_G : OPTIONAL
E
: OPTIONAL
S
: OPTIONAL
F
: OPTIONAL
RF
: OPTIONAL
R
: OPTIONAL
HM
: OPTIONAL
SA
: OPTIONAL
KG
: OPTIONAL
N
: OPTIONAL
T
: OPTIONAL
A
: OPTIONAL
H
: OPTIONAL
----------------------------
REAL;
REAL;
REAL;
REAL;
REAL;
REAL;
REAL;
REAL;
REAL;
REAL;
REAL;
REAL;
REAL;
REAL;
REAL;
REAL;
REAL;
REAL;
REAL;
REAL;
REAL;
BOLT_SA;
INTEGER;
REAL;
REAL;
REAL;
REAL;
height of bolt head
nominal thread diameter
shank diameter
diameter below countersunk head
transitional diameter
head diameter
angle of countersunk head
nominal length
minimal grip length
maximal grip length
width of staple
resin-coated length
thread length
thread pitch, or groove distance
thread pitch (angle)
corner-to-corner dimension of bolt head
head width (width of flats)
height of lens head
head radius
curvature radius
nut height
head type (wrench type)
nominal wrench size
slot width (wrench size)
slot depth
clamp thickness
clamp height
66
BR
: OPTIONAL REAL;
BS
: OPTIONAL REAL;
HS
: OPTIONAL REAL;
END_ENTITY;
-- width of clamp back
-- width of clamp top
-- washer height
TYPE BOLT_TYP = ENUMERATION OF
(WOOD_SCREW,
-- wood screw
STEEL_SCREW,
-- bolt
SCREW_SET,
-- set of bolt + washers + nut (assembly)
NAIL,
-- smooth nail
SPECIAL_NAIL,
-- threaded nail
CRAMP,
-- staple
BAUKLAMMER_FORM_A, -- clamp, DIN shape A (carpenter’s dog, timber dog)
BAUKLAMMER_FORM_C, -"
"
"
C
"
"
"
"
BAUKLAMMER_FORM_D, -"
"
"
D
"
"
"
"
DOWEL,
-- dowel
PIN);
-- threaded rod
END_TYPE;
TYPE BOLT_VF = ENUMERATION OF (TRUE, FALSE);
END_TYPE;
TYPE BOLT_SA = ENUMERATION OF
(NORMAL,
-- slotted head
KREUZSCHLITZ_H,
-- Phillips head type H
KREUZSCHLITZ_Z); -- Phillips head type Z
END_TYPE;
The BOLT entity is an extension of the equally named entity in PSS. It covers not only
bolts but also nails, screws, and dowel type fasteners used in timber connections.
The current PSS specification splits BOLT into a shortened BOLT entity for bolt sets
and a BOLT_ELEMENT for the parts of a set.
Welded joints
ENTITY WELD;
NR
: OPTIONAL
DATE : OPTIONAL
BEZ
: OPTIONAL
NA
: OPTIONAL
ND
: OPTIONAL
KL
: OPTIONAL
OFORM : OPTIONAL
SV
: OPTIONAL
A
: REAL;
INTEGER;
STRING;
STRING;
WELD_NA;
REAL;
WELD_KL;
WELD_OFORM;
WELD_SV;
B
: OPTIONAL REAL;
C
: OPTIONAL REAL;
END_ENTITY;
------------
description, additional specification
type, shape
thickness
orientation of fillet welds
surface: plane, convex, or concave?
technology
calculation value of thickness (of linear
welds), or height (of flush welds),
or diameter (of spot welds)
single weld length of intermittent welds
gap length of intermittent welds
TYPE WELD_NA = ENUMERATION OF (BOERDEL_NAHT, I_NAHT, V_NAHT, HV_NAHT, Y_NAHT,
HY_NAHT, U_NAHT, HU_NAHT, GEGENNAHT, KEHLNAHT, LOCHNAHT, PUNKTNAHT, LINIENNAHT,
STEILFLANKENNAHT, HALB_STEILFLANKENNAHT, STIRNFLAECHENNAHT, FLAECHENNAHT,
SCHRAEGNAHT, FALZNAHT, AUFTRAGSNAHT, DV_NAHT, DHV_NAHT, DY_NAHT, DHY_NAHT,
DU_NAHT, DHU_NAHT, VU_NAHT, V_NAHT_MIT_GEGENLAGE, DOPPELKEHLNAHT, DREIBLECHNAHT,
SONSTIGE_NAHT, UNTERBROCHENE_KEHLNAHT, VERSETZT_UNTERBROCHENE_KEHLNAHT);
END_TYPE;
TYPE WELD_KL = ENUMERATION OF (POSITIV, NEGATIV);
END_TYPE;
TYPE WELD_OFORM = ENUMERATION OF (GLATT, GEWOELBT, HOHL);
END_TYPE;
TYPE WELD_SV = ENUMERATION OF (AUTOGEN, OFFENES_LICHTBOGEN_VON_HAND,
OFFENES_LICHTBOGEN_MECHANISCH, UNTERPULVER, UNTERSCHIENEN, WIG, MIG,
MAG, PUNKT, ABBRENNSTUMPF, BOLZEN);
END_TYPE;
67
Glued joints
ENTITY GLUE;
NR
: OPTIONAL
DATE : OPTIONAL
PL
: OPTIONAL
TYP : OPTIONAL
PRZ : OPTIONAL
END_ENTITY;
INTEGER;
STRING;
LIST OF POLYLINE;
GLUE_TYP;
REAL;
-- geometry and direction
-- material
-- pressing time (drying time, curing time)
TYPE GLUE_TYP = ENUMERATION OF
(KAL,
-- blood-albumin adhesive
KC,
-- casein adhesive
KCPD,
-- copolymer dispersion adhesive
KEP,
-- epoxy resin adhesive
KG,
-- glutine glue (animal glue / Scotch glue)
KIS,
-- isocyanate adhesive
KMF,
-- melamine formaldehyde resin
KPAN,
-- polyacrylic nitril rubber adhesive
KPBC,
-- polychloroprene adhesive
KPF,
-- phenol formaldehyde resin
KPVAC,
-- polyvinyl acetate dispersion adhesive
KRF,
-- resorcinol-formaldehyde resin
KSCH,
-- hot melt adhesive
KUF,
-- urea formaldehyde resin
KUP,
-- polyester adhesive
OTHER); -- non-listed adhesive
END_TYPE;
The abbreviations in GLUE_TYP were taken from DIN 4076-3:01.1974.17
The corresponding entity in PSS does not provide an enumeration for the glue
material but it adds an enumeration attribute to differentiate gluing in spots, lines, or
areas. In PSS, the geometry is not an attribute of PSS’s GLUE but of an extra
attribute named CONNECTION_ELEMENT_LOCATION.
Arbitrary fasteners
ENTITY TIMBER_CONNECTION;
NR
: OPTIONAL INTEGER;
BEZ : STRING;
-- descriptor
END_ENTITY;
Other fasteners like beam hangers are represented by TIMBER_CONNECTION. They are
described solely by the BEZ attribute which has to provide complete information by
reference of an external catalog or library. The mere use of a key word according to a
classification system would be insufficient since classification systems do not contain
explicit geometry information.
17
now replaced by European standards
68
Placement of fasteners and joints
ENTITY CONNECTION;
NR
: OPTIONAL INTEGER;
ML
: LIST OF CONNECTION_ML;
CON : OPTIONAL CONNECTION_CON;
VER : OPTIONAL LIST OF CONNECTION_VER;
KI
KJ
KR
LOC : OPTIONAL CONNECTION_LOC;
END_ENTITY;
--------
connected members or building parts
connecting fastener or joint
position of multiple grouped fasteners
placement of the connection, given in
local coordinates of the first
member listed in ML
place where the connection is made
TYPE CONNECTION_ML = SELECT (MEMBER_LOCATION, BUILDING_PART, FOUNDATION);
END_TYPE;
TYPE CONNECTION_CON = SELECT (BOLT, WELD, GLUE, TIMBER_CONNECTION);
END_TYPE;
TYPE CONNECTION_VER = SELECT (CONNECTION_VER_VL, POLYLINE);
END_TYPE;
TYPE CONNECTION_VER_VL = LIST OF VERTEX;
END_TYPE;
TYPE CONNECTION_LOC = ENUMERATION OF
(SHOP,
-- pre-assembled
ON_SITE); -- field-assembled
END_TYPE;
Once a type of fastener or joint is defined by one of the previous entities, it can be
inserted into the structure by CONNECTION multiple times. The CONNECTION instances
specify not only the location of fasteners but also the members which they connect,
and whether they are joined in the carpenter’s shop or at the building site.
fig. 4-20
DtH entities for connections, simplified EXPRESS-G
CONNECTION
L
BUILDING_PART
FOUNDATION
MEMBER_LOCATION
L
BOLT
GLUE
WELD
TIMBER_CONNECTION
The equivalent of DtH’s CONNECTION in the current PSS specification is split into a
similar CONNECTION entity and an additional CONNECTION_ELEMENT_LOCATION
entity, see fig. 4-21. The latter contains coordinates and references to type entities
while the former provides references to the connected members. Thus PSS’s
CONNECTION entity resembles the IFC concept of objectified relationships. One
CONNECTION instance can reference one or more CONNECTION_ELEMENT_LOCATION
instances. Furthermore, there is an optional numeric attribute for PSS’s CONNECTION
to denote the technological order of all connections.
fig. 4-21
69
PSS entities for connections, simplified EXPRESS-G
CONNECTION
L[1:?]
CONNECTION_ELEMENT_LOCATION
L[1:?]
MEMBER_LOCATION
BOLT
GLUE
WELD
L[1:?]
BOLT_ELEMENT
There are no high-level classes for structural timber detailing in IFC 2x2 yet. Several
base classes exist that may serve as parent classes for timber specific entities.
One important concept of DtH — to split configuration of members and placement of
members into two distinct classes (MEMBER for configuration, MEMBER_LOCATION for
placement) — has not been available in IFC until release of IFC 2x. In terms of the
current IFC architecture, configuration objects are type objects (IfcTypeObject of
IFC 2x and its subtypes), placement objects are occurrence objects (IfcObject of
IFC 1.0 and its subtypes). Placement objects of DtH are very light-weighted in
contrast to occurrence objects of IFC. A great number of subtypes of IfcTypeObject
was added just recently to IFC by the 2x2 release, acknowledging the advantages of
type objects for the versatility of the product model as well as for its interoperability.
The basic concept of feature elements was introduced into IFC 2x2 as a deliverable of
the ST-3 Precast Concrete Construction project. Note that this concept is only
available in form of (and in association with) occurrence objects of IFC. Different to
that, DtH associates processing features with type objects; compare fig. 4-8.18
Furthermore, IFC characterizes feature elements as dependent elements that modify
shape and appearance whereas DtH combines shape information with technological
information.
The concept of connections was also introduced into IFC 2x2 by the ST-3 project and
— in the slightly different context of structural analysis — by the ST-4 project.
Several entities were proposed by ST-3 to present connecting elements (like mortar
and mechanical fasteners), all of which are again only occurrence objects, and an objectified relationship between connected building elements and connecting elements.
When the ST-3 deliverables were integrated into IFC, type objects for fasteners were
added.
IFC classes for steel detailing are supposed to be developed by the IAI ST-4 followup project within about the same time span as the IAI ST-5 project duration. Some
features and connection types of DtH that are specific to steel elements will therefore
be not included into the Structural Timber Model.
18
An exception is the assignment of processing features to building parts. The DtH building parts like
walls and slabs are located objects (occurrence objects).
70
4.7 Cost estimation, bid preparation, billing
The current DtH specification emphasizes on bid preparation, in particular on bills of
quantities. In German practice, a bill of quantities is divided into titles which again
comprise of positions (items).
ENTITY AVA_TITEL;
NR
: OPTIONAL
DATE : OPTIONAL
BEZ
: OPTIONAL
AP
: OPTIONAL
PREIS : OPTIONAL
END_ENTITY;
INTEGER;
STRING;
STRING;
LIST OF AVA_POSITION;
REAL;
ENTITY AVA_POSITION;
NR
: OPTIONAL INTEGER;
POSNR : OPTIONAL INTEGER;
ART
: OPTIONAL AVA_ART;
STLB : OPTIONAL STRING;
STLNR : OPTIONAL STRING;
KTEXT : OPTIONAL STRING;
LTEXT : OPTIONAL STRING;
EIN
: OPTIONAL STRING;
MENGE : OPTIONAL REAL;
P_E
: OPTIONAL REAL;
P_G
: OPTIONAL REAL;
ENT
: LIST OF SEL_ALL_ENT;
END_ENTITY;
------------
-- label
-- associated items
-- summary price
item number
type
service scope according to STLB
key number according to STLB
short description
long description
unit of measurement
quantity
price per unit
total price
associated building parts and members
TYPE AVA_ART = ENUMERATION OF
(G,
-- basic item
A,
-- alternative item
Z,
-- extra item
E,
-- contingency item
B,
-- request item
F); -- item without allocated production overhead
END_TYPE;
Comparison to IFC
IFC 2x2 provide support for cost estimation, bid preparation, billing, as well as
scheduling and construction management throughout the various layers.
4.8 Gaps in DtH 2.0
4.8.1 Missing building services model
There are no provisions for HVAC, plumbing, and electric installation design. The
main reason was lack of feedback from relevant software vendors during the past two
phases of DtH development.
IFC 2x2 provide HVAC, Plumbing, Fire Protection, Electrical, and Building Controls
domains.
71
4.8.2 Limited production model
Differentiation into prefabrication and on-site fabrication
While connections can be marked as shop-assembled or field-assembled, there is no
such attribute for processing features. This information would be useful for
prefabrication planning, erection planning, and quality control. Surface treatments
might even be deeper differentiated into treatments applied before prefabrication,
applied after prefabrication but before transport, or applied on site.
Technologic sequences
There is no more sophisticated way to describe the order of manufacturing steps
beyond the LIST of processing features applied to a member. There is no possibility
to express dependencies or process sequences beyond the scope of single members.
Superstructures that are divided during prefabrication
Prefabricated timber frame panels, especially wall panels, are manufactured in units
as large as the production facility allows. After that they are sawn into the actual wall
segments. The mechanism shown in fig. 4-6 should therefore be generalized in order
to be applicable to superstructures, not only to simple members.
(A MEMBER entity — which can represent a raw unit to be sawn into two units —
cannot represent an assembled unit like a wall panel. On the other hand, DtH entities
for representation of assemblies cannot be attributed with a dividing cut.)
Assemblies, superstructures
DtH offers three ways to group building elements into preassembled units. Neither is
this ambiguity desirable, nor is any of the three ways perfectly satisfying:
• First and foremost, the BUILDING_PART entity is meant to represent superstructures. However the physical segmentation of building parts in the
production model is generally not identical to the logical segmentation of
building parts within the architectural model.
The position of members of a building part is given in global coordinates,
not in coordinates local to the building part.
• The MEMBER_LOCATION entity can represent a superstructure as well, but it
does not provide references to its parts. There are only references from the
parts to the superstructure.
Furthermore, processing features cannot be assigned to an instance of
MEMBER_LOCATION.19
• The STRUCTURE entity can also represent preassembled units, but there is no
possibility to assign properties like transportation weight or processing
features to such a structure.
Machine control
There is no formal way to assign machine control data (NC protocol) to members and
structures, neither directly in a DtH file nor as a reference to an external file.
19
Certain processing features can only be assigned to a superstructure, not to single members. For
instance, holes for electrical installation are usually bored into wall panels after sheathing, studs,
blocking, and so forth were joined.
72
5 Appendix
5.1 References
[1]
TC184/SC4, http://www.tc184-sc4.org/
[2]
International Alliance for Interoperability, 2004, http://www.iaiinternational.org/iai_international/Technical_Documents/R2x2_final/
[3]
Standard Description Product Interface Steel Construction – Part 2: Data Model.
Deutscher Stahlbau-Verband, Düsseldorf, 2004,
http://www.deutscherstahlbau.de/asp/biblioaussdet.asp?auss=7
[4]
DtH-Produktschnittstelle für den Datenaustausch im Holzbau, Version 1.05.
Deutsche Gesellschaft für Holzforschung, Munich, 1996
(DtH product interface for data exchange in timber construction; in German)
[5]
Universität Cottbus, Germany, 2000, ISSN 1615-3952,
http://www.statik.tu-cottbus.de/dth
(Product model DtH for timber engineering construction, carpentry, and
prefabricated building construction. English model reference available)
[6]
IFC 2x Model Integration Guide. IAI Model Support Group, 2002,
http://www.iai-international.org/iai_international/Technical_Documents/
documentation/Ifc2xModelIntegration/Model_Integration_Guide_v1.00.pdf
[7]
IFC 2x Extension Modelling Guide. IAI Model Support Group, 2001,
http://cig.bre.co.uk/iai_international/Technical_Documents/documentation/Ifc2
x_EMG/EMG-Base.htm
[8]
Support Group, 2000, http://www.iai-international.org/iai_international/
Technical_Documents/documentation/IFC_2x_Technical_Guide.pdf
[9]
Thomas Liebich, Jeffrey Wix, et al: Standard Analysis – Current Situation –
Building Models. prodAEC deliverable D4.1.2, 2002, http://www.prodaec.com/
[10] Curtis Parks: IGES – Historical Milestones. NIST, 2003,
http://www.nist.gov/iges/milestones.html
[11] What is STEP? – Organisation/ History (ISO). ProSTEP iViP Association,
2003, http://www.prostep.org/en/stepportal/was/orga/
[12] STEP Management Overview – History of STEP. PDIT Inc.; 1996
5 Appendix
73
[13] Christoph Hörenbaum, Peter Katranuschkov, Thomas Liebich, Matthias Weise,
et al: IAI ST-4 Released Drafts. iCSS project, 2001–2002, http://cib.bau.tudresden.de/icss/structural_papers.html
[14] Kari Karstila, Kalle Serén, et al: IAI ST-3 Released Drafts. 2002,
http://www.eurostep.fi/public/PCC_IFC/English/
[15] Kari Karstila: FinnTimber-IFC — Data exchange use cases and requirements.
Product data exchange and sharing for timber construction. 2004
5.2 List of figures
fig. 2-1
Data transfer through conventional interfaces ...............................................7
fig. 2-2
Information sharing via a product model.......................................................7
fig. 2-3
Timetable of product model developments..................................................11
fig. 2-4
Scope of current IFC and DtH specifications ..............................................14
fig. 2-5 Extensions to IFC 2x by the ST-3, ST-4, and ST-5 projects .......................15
fig. 3-1 Data exchange — From requirements management to design ....................25
fig. 3-2 Data exchange between designs...................................................................26
fig. 3-3 Data exchange — Suppliers product information to design ........................27
fig. 3-4 Data exchange — From design to construction planning............................28
fig. 3-5 Data exchange between project management, construction, deliveries.......29
fig. 3-6 Data exchange by project management .......................................................30
fig. 3-7 Data exchange to use and maintenance .......................................................31
fig. 3-8 Data exchange between use and maintenance .............................................32
fig. 4-1
Rectangular and circular cross sections .......................................................45
fig. 4-2
Cross section types.......................................................................................46
fig. 4-3
Examples of composed cross sections .........................................................47
fig. 4-4 Hierarchies in the structural analysis model ................................................48
fig. 4-5
DtH entities for structural analysis, simplified EXPRESS-G......................48
fig. 4-6 Cutting a raw member into two ...................................................................55
fig. 4-7
Alignment of a member by offsets...............................................................57
fig. 4-8
DtH entities for structural detailing, simplified EXPRESS-G.....................57
fig. 4-9
Definition of miter angles ............................................................................58
fig. 4-10
Member with cut-out..................................................................................59
74
fig. 4-11
CUTOUT_TIMBER, type F1: a single cut................................................61
fig. 4-12
CUTOUT_TIMBER, type F2: two cuts.....................................................61
fig. 4-13
CUTOUT_TIMBER, type F3: three cut planes, meeting in two edges.....62
fig. 4-14
CUTOUT_TIMBER, type F4: three cut planes, meeting in three edges...62
fig. 4-15 CUTOUT_TIMBER, type F5: four cut planes — type F6: five cut planes
for mortises and grooves — type F7: tenons .......................................................62
fig. 4-16 CUTOUT_TIMBER, type F8: polygonal intersection ..............................62
fig. 4-17
Hole pattern................................................................................................63
fig. 4-18
Member with signature ..............................................................................64
fig. 4-19
Cold bent sheet metal.................................................................................64
fig. 4-20 DtH entities for connections, simplified EXPRESS-G..............................68
fig. 4-21
PSS entities for connections, simplified EXPRESS-G ..............................69
(fig. 3-1…fig. 3-8 by courtesy of FinnTimber-IFC project)
IAI Project ST-5
Part II
Schema Reference
by
document rev.: 1.final
document status: proposal
31 Dec 2004
Acknowledgement
is carried out by the Brandenburg Technical University Cottbus, Germany, Chair for
Structural Analysis under guidance of the German Association for Wood Research
(Deutsche Gesellschaft für Holzforschung, DGfH) with funding by the German
Federal Ministry of Education and Research between July 2003 and December 2004
under project number 0330424.
Table of Contents
3
Table of Contents
1 Abstract
5
Current status ...........................................................................................................................5
2 Introduction
8
2.1 Prerequisites .....................................................................................................8
2.2 Concepts and terms ..........................................................................................8
2.2.1
2.2.2
2.2.3
2.2.4
Summary of terms .......................................................................................................8
Concepts regarding model items .................................................................................8
Concepts regarding the model architecture................................................................11
Concepts of geometric modeling ...............................................................................12
3 Schema extensions
14
3.1 Summary of data types and property sets ......................................................14
3.1.1
3.1.2
3.1.3
New definitions proposed by ST-5 ............................................................................14
Changed definitions proposed by ST-5 .....................................................................14
Unchanged definitions used by ST-5 (excerpt) .........................................................15
3.2 IfcTimberConstructionDomain Schema ........................................................15
3.3 Locations of model extensions in the IFC 2x2 architecture ..........................16
4 Materials, cross sections
17
4.1 Material resources..........................................................................................17
4.1.1
4.1.2
4.1.3
4.1.4
IfcMaterial .................................................................................................................17
IfcRelAssociatesMaterial...........................................................................................17
Other material resource entities .................................................................................18
4.2 Shapes, cross sections, profile resources .......................................................19
4.2.1
4.2.2
Shape representation..................................................................................................19
Shape parameters.......................................................................................................20
4.3 Quantities, Material Quality...........................................................................20
4.3.1
4.3.2
IfcElementQuantity ...................................................................................................20
Pset_TimberElementQuality......................................................................................21
5 Building elements
22
5.1 Members and accessories: Occurrence objects..............................................22
5.1.1
5.1.2
IfcBeam, IfcColumn, IfcMember ..............................................................................22
Accessories ................................................................................................................22
5.2 Members and accessories: Type objects ........................................................23
5.2.1
5.2.2
5.2.3
IfcBeamType, IfcColumnType, IfcBeamTypeEnum, IfcColumnTypeEnum............23
IfcMemberType .........................................................................................................23
IfcMemberTypeEnum ...............................................................................................26
5.3 Assemblies .....................................................................................................26
5.3.1
5.3.2
5.3.3
IfcElementAssembly, IfcWall, IfcSlab, IfcRoof........................................................26
IfcWallTypeEnum .....................................................................................................27
Layers of assemblies (IfcBuildingElementPart) ........................................................27
4
IAI Project ST-5 — Structural Timber Model — Part II: Schema Reference
6 Detailing, Connections
29
6.1 Processing features: Modeling decisions .......................................................29
6.2 Processing features: Property sets..................................................................32
6.2.1
6.2.2
6.2.3
6.2.4
6.2.5
6.2.6
6.2.7
IfcShapeAspect..........................................................................................................32
IfcShapeAspectProperties..........................................................................................33
6.3 Processing features: Extended properties ......................................................41
6.3.1
6.3.2
6.3.3
6.3.4
6.3.5
6.3.6
Subtypes of IfcShapeAspectProperties......................................................................41
6.4 Connections: Occurrence objects...................................................................43
6.4.1
6.4.2
6.4.3
IfcFastener .................................................................................................................43
IfcMechanicalFastener (to be deleted).......................................................................44
IfcDiscreteAccessory.................................................................................................44
6.5 Connections: Type objects.............................................................................45
6.5.1
6.5.2
6.5.3
IfcFastenerType .........................................................................................................45
IfcMechanicalFastenerType ......................................................................................45
IfcDiscreteAccessoryType.........................................................................................47
6.6 Connections: Property sets.............................................................................47
6.6.1
6.6.2
6.6.3
6.6.4
6.6.5
6.6.6
6.6.7
6.6.8
Pset_ElementComponentCommon............................................................................47
Pset_FastenerGlue .....................................................................................................48
Pset_FastenerGroup...................................................................................................48
Pset_MechanicalFastenerBolt....................................................................................49
Pset_MechanicalFastenerScrew ................................................................................50
Pset_MechanicalFastenerNail....................................................................................50
Pset_MechanicalFastenerStaple ................................................................................51
Pset_MechanicalFastenerNailPlate............................................................................51
6.7 Connections: Relationship objects.................................................................52
7 Structural analysis
53
7.1 Materials ........................................................................................................53
7.1.1
7.1.2
7.1.3
IfcMechanicalMaterialProperties...............................................................................53
IfcMechanicalTimberMaterialProperties...................................................................53
7.2 Cross sections.................................................................................................58
7.2.1
IfcStructuralProfileProperties ....................................................................................58
7.3 Mechanical elements......................................................................................59
7.3.1
IfcStructuralMember .................................................................................................59
7.4 Loads, systems, strength verification.............................................................59
8 Appendix
61
8.1 References......................................................................................................61
8.2 List of figures .................................................................................................61
1 Abstract
5
1 Abstract
for Interoperability (IAI). Business needs, information requirements, and the roots of
the Structural Timber Model in the DtH model are discussed in the accompanying
document “Structural Timber Model – Part I: Requirements”.
Chapter 2 of this document introduces basic concepts and selected terms.
Chapter 3 summarizes the proposed schema extensions on top of IFC 2x2. The
extent of the formal Structural Timber Model and its integration into the IFC model
are outlined.
Chapters 4 to 7 define the data types of the structural timber model. Subsections
named Discussion and footnotes are not part of the actual model definition. Equivalent HTML documentation is available.
The document is complemented by “Structural Timber Model – Part III: Implementation Guide”.
Current status
This document reflects the project’s proposed data model. Names, attributes, or
entire definitions may change during model integration by the IAI Model Support
Group.
6
Document history
rev 1.final 31 December 2004
IfcMemberType: clarification and illustrations on member axes and
material orientation, ‘Fiber’ may also be a direction;
IfcWall: discussion added;
IfcWallTypeEnum: new item FRAME;
IfcShapeAspectCutoutProperties: geometric model is independent of steel
or timber construction (view definitions may be more specific than the
model specification);
IfcShapeAspectSurfaceProperties: Name in use definition for steel
members replaced by Purpose, IfcMaterialSelect mentioned instead of
IfcMaterial, Shape may refer to several shape representations at once
(useful for assemblies);
chapter 3 updated;
minor text corrections
rev 1.rc2
27 October 2004
section 5.4 deleted, sections 5.1 and 5.2 reorganized: IfcMember from
IFC 2x2 Addendum 1 used as universally applicable occurrence of timber
members together with IfcMemberType, extended usage of
IfcPlate(Type(Enum)) withdrawn;
IfcRelAssociatesMaterial, IfcMemberTypeEnum: updated to IFC 2x2
Addendum1;
IfcElementAssembly: added IfcWall, IfcSlab, IfcRoof as alternatives;
IfcShapeAspectSurfaceProperties: use of attribute Name changed,
attributes Purpose and EntireBody added;
IfcShapeAspectCutoutProperties: explanation of ‘Cut’ extended;
IfcMechanicalFastenerType: spaces in object type names removed;
IfcExtendedMaterialProperties: Compression in property names;
chapter 3 updated;
various minor text corrections
rev 1.rc1
02 July 2004
chapter 3 and sections 2.2, 5.3, 5.4, 6.1 updated and extended;
Pset_TimberMemberMaterial renamed to Pset_TimberElementQuality
and some properties moved to IfcExtendedMaterialProperties;
use definition of IfcPlate edited, IfcPlateTypeEnum cleaned up;
IfcFeatureProperties renamed to IfcShapeAspectProperties, its five
subtypes renamed accordingly;
attribute IfcShapeAspectProperties.Type renamed, attribute Order deleted
and replaced by an extended property in subsection 6.3.1;
use of surface model in IfcShapeAspectCutoutProperties explained;
IfcShapeAspectSurfaceProperties: three kinds of surface specification
explained, note on CIS/2 added, area attribute added;
several CIS/2 derived extended properties added, property for number-ofcoats deleted;
representation of fastener groups moved to IfcFastener and edited;
deletion of IfcMechanicalFastener proposed;
attributes and use definition of IfcMechanicalFastenerType extended;
1 Abstract
7
section 6.6 cleaned up, Psets for dowels and shear connectors deleted;
attributes of IfcMechanicalTimberMaterialProperties and extended
material properties renamed
rev 1.β3
19 May 2004
discussion added to IfcElementQuantity;
laminated solid wood elements moved from section 5.1.2 to 5.1.3;
geometric representation of IfcMemberType and IfcPlateType extended in
order to use shape aspects for shape features;
alternative extrusion added to representation of IfcPlateType;
section 5.3 extended;
section 5.4 added;
all feature related entities and property sets of β2 deleted;
extensive discussion of feature modeling decisions added;
change to IfcShapeAspect added;
added: IfcFeatureProperties, IfcFeatureBendingProperties,
IfcFeatureCutoutProperties, IfcFeatureHoleProperties,
IfcFeatureSignatureProperties, IfcFeatureSurfaceProperties;
feature Psets transformed to extended properties of IfcFeatureProperties;
chapters 2.2 and 3 updated
rev 1.β2
07 April 2004
illustrations added in chapter 6 (processing features);
IfcHoleFeatureType: 3 of 4 informal propositions removed;
IfcMiterFeatureType: note on attributes extended, discussion added;
IfcTimberFeatureType: clarification in ShapeIsSquare attribute definition;
IfcTimberFeatureTypeEnum: items RIDGE and CHASE integrated into
EDGECUT, CUT renamed to ENDCUT, configuration TWO added to
ENDCUT, TABLEDSCARF integrated into SCARF;
Pset_ProcessingFeatureCommon: footnote on tolerances;
new property in Pset_MechanicalFastenerGroup, ~Nail, ~Staple, and
~Dowel respectively;
IfcExternalSpace renamed to IfcSpatialStructureElementProxy,
QuantityMultiplier attribute deleted;
IfcRelAssignsToProductWithPlacement deleted;
IfcMechanicalWoodbasedBeamMaterialProperties and ~PanelMaterialProperties replaced by IfcExtendedMaterialProperties
rev 1.β1
15 March 2004
first released draft
8
2 Introduction
2.1 Prerequisites
It is assumed that the reader is familiar with base parts of [1], especially with the
EXPRESS language.
The building blocks of the Structural Timber Model are formulated as extensions on
top of [2]. Underlying concepts and architectural principles, of which some are
discussed in the following subsection, are documented in [3].
2.2 Concepts and terms
2.2.1 Summary of terms
Terms introduced in subsection 2.2.2 (model items):
Element (building element),
Member,
Assembly,
Component,
Feature: geometric feature, processing feature,
Connection,
Semi-finished product.
Terms introduced in subsection 2.2.3 (model architecture):
Occurrence object,
Type object,
Property set,
Objectified relationship.
Terms introduced in subsection 2.2.4 (geometric modeling):
Shape representation,
Mapped representation,
Parametric modeling,
Feature-based geometric modeling.
2.2.2 Concepts regarding model items
Element (building element)
• is a physically existing object — it possesses a solid body and consists of
one or more materials;
• is a product — it is created (manufactured or supplied) and remains permanently in a building or is temporarily used in a construction project.
2 Introduction
9
Element may denote either aggregated or “atomic” objects. Specific terms for aggregations (assemblies) and “atomic” objects (members, components) are introduced
below. Building elements form the structure and the space separating system of a
building and are therefore permanently used.
NOTE: In the timber construction industry, the term element is often used for
prefabricated assemblies such as wall sections. This document uses the term
with a general meaning as described above, consistently with the usage in the
IFC model.
Member
• is a building element that is usually comprised of a single workpiece;
• may provide space boundaries;
• often has load carrying function.
Examples of members are rafters, posts, and sheathing panels .
Assembly
• is an element which is comprised of smaller elements which are connected
to each other (in other words, parts aggregate an assembly);
• often provides space boundaries;
Examples of assemblies are wall segments and roof trusses.
Note that assembly, as part of the structural model, is conceptually different from
building part, such as walls or roofs, in the architectural model.
Component
• is an element of minor importance from the overall building structure’s
viewpoint;
• usually does not provide space boundaries;
• may have load carrying function;
• can be a fastener or an accessory.
Examples of fasteners are nails. Examples of accessories are beam hangers, electrical
conduits and window lining.
NOTE: In the materials supplier industry, the term component is often used for
prefabricated products such as panels or trusses. This document uses the term
with a different meaning as described above, consistently with the usage in the
IFC model.
Feature: geometric feature, processing feature
A geometric feature is a shape aspect of a building element that adds detail to the
base (primitive) geometric form of the element. Examples of geometric features are
mitered ends and holes.
A processing feature or machining feature is a physical aspect of a building element
that is added to the raw element by a manufacturing process during prefabrication or
10
erection, often in order to create a geometric feature. Examples of processing features
are sawn miters, bore holes, and painted surfaces.
The proposed Structural Timber Model does not distinguish geometric features from
processing features. A processing feature is regarded a geometric feature with added
technological information.
A processing feature is realized by a dedicated manufacturing process during prefabrication or erection. The technological information offered by a processing feature
does not describe the manufacturing process but serves to plan the process. For
example, a bore hole feature may be attributed with the information whether special
care shall be taken for a splinter free bore exit.
Connection
• is a physical link between two or more building elements;
• may require fasteners, accessories, or features to be accomplished;
• is realized by a manufacturing process during prefabrication or erection;
An example of a connection is the support of a joist on a header via a beam hanger
and nails. Another example is a glued finger joint between parts of a rigid glulam
frame.
Note that connection as the relation between joined parts is conceptually different
from aggregation, which is the relation between an assembly and its parts.
Semi-finished product
is an element that is used in fabrication processes to form one or more building
elements.1 It may be a simple element or an aggregated element (a semi-finished
assembly). Examples are
• long lumbers consisting of finger-jointed solid timber that are sawn into
shorter beams;
• large wood-based panels that are cut into fitting pieces;
• walls, decks, or roof elements that are fabricated in a size as large as
possible with the available factory equipment and then sawn into wall
segments as actually needed in the respective construction projects and as
allowable for street transport.
A semi-finished product does not possess a location within a building. Therein it is
different from the products made from it, which each are located at a particular
position in a building. Products made from one and the same semi-finished product
may even be used in different buildings or construction projects.
The classes that represent semi-finished products are actually not different from those
of objects that are finally located in a building. Their instances are only differently
spatially contained.
1
A more precise term for semi-finished product would be semi-finished element. Another term used
within the context of fabrication processes is workpiece.
2 Introduction
11
2.2.3 Concepts regarding the model architecture
Occurrence object
or “located object” represents exactly one physical element that can be identified by
its unique location within a space.
Several occurrence objects may have equal properties and features but they differ
with respect to the location where the elements are placed. The quantity of materials
needed for a building can be determined by counting occurrence objects.
Type object
represents a category or style of several (or one, or none) elements.
A type object is typically used when a considerable number of elements possess the
same shape, material, description etc.. The occurrence objects that represent these
elements do not contain separate data about the shared shape and material. Instead,
this data is obtained from the according type object.
Note that many capabilities of occurrence objects are not available with type objects.
For example, occurrence objects can form an aggregation, but type objects cannot. In
other words, there is no such model item like an assembled group of styles.
Property set
represents a collection of attributes of several (or one, or none) objects.2
A property set is typically used as a pool of related attribute data. A property set may
be associated with multiple occurrence objects and is then called a shared property
set.
Definitions of objects (occurrence or type objects) are refined by associated property
sets. An object may have multiple defining property sets. Property sets that are
assigned to the same object complement each other or override one another.
Properties each consist of a name and a value. Properties are treelike organized in a
property set. Properties whose values are not known when a property set is
instantiated — or which are not useful in an instance — are simply omitted from the
property set instance.
Two types of property sets exist:
• “Model driven” property sets are part of the IFC model. They are defined in
EXPRESS schemas.
• “Data driven” property sets are extendable collections of properties. They
are defined outside of the IFC model. The meaning of a property is not
determined by the class of the property entity but by the value of a name
attribute, hence “data driven”.
Data driven property sets may be defined in documents published by IAI, or by local
agreement of implementers, or potentially even by project-wise agreement of end-
2
In the context of the IFC architecture, property sets (namely IfcPropertySetDefinition) are also called
“partial types” — as opposed to type objects.
12
users. Property sets thereby allow for “private” application software specific model
extensions at the attribute level.3
Objectified relationship
represents a relation between objects. This way to model relationships is a more
powerful alternative to the simpler method to express a relationship by an attribute of
the relating object that refers to related objects. Objectified relationships allow for
• separation of relationship semantics from the relating objects;
• further description of the relationship by its own type and attributes;
• realization of relations between objects across IFC layer boundaries.
Relationship objects in IFC can represent 1:1 or 1:N relationships. M:N relationships
can sometimes be resolved by M instances of a relationship class.4
The common case is a binary relationship between 1 relating object and 1…N related
objects. A special case is a ternary relationship, which additionally involves 1…n
realizing objects (subordinate objects whose sole purpose is to accomplish the
relationship).
2.2.4 Concepts of geometric modeling
Shape representation
is a collection of geometric items that symbolize the shape of an element. An element
may possess multiple (shape) representations for use in different contexts, e.g. with
different levels of geometric details. Modeling methods for shape representation are,
among others, constructive solid geometry, boundary representation, bounding box.
Mapped representation
IFC allows for multiple elements sharing one shape representation by a mapping
mechanism. There is one source representation, called representation map, and
multiple replicated representations, called mapped items. Each mapped item may be
translated, rotated, mirrored and/ or scaled by Cartesian transformation.
Parametric modeling
involves control parameters in addition to geometric modeling methods mentioned
above. Simple modifications of parameters can cause complex modifications of the
shape. The added parameters also help interpret the model in heterogeneous applications, provided a well-defined set of parameters has been agreed upon.
3
Furthermore, private extensions at the object level are possible by IfcProxy and IfcBuildingElementProxy.
4
M:N or even 1:N relationships are often prohibited by inverse attributes of the relating entities.
Example 1: A WHERE rule in IfcObject concerning its inverse IsDefinedBy attribute forbids that an
occurrence object is specified by more than one type object.
Example 2: The bound specification of the inverse Decomposes attribute of IfcObject states that an
object may be a part in no more than one decomposition.
2 Introduction
13
Feature-based geometric modeling
treats geometric aspects of a geometric object as additional subordinate objects. (See
also geometric feature above.) This way, more qualified information about the shape
aspect as well as its relation to the main shape is captured. Features may again be
modeled using parameters.
The persistence of feature data is of special importance in iterative design processes.
While it is possible to reproduce feature information from unstructured geometric
data by feature recognition techniques, this is an expensive approach to solve design
problems iteratively.
Feature-based modeling not only describes shape. It also allows for non-geometric
product data to be assigned to particular shape aspects. Furthermore, relations
between geometric objects that govern existence and parameters of certain shape
aspects can be explicitly associated with these aspects when they are manifest as
objects themselves.
It shall be noted that both parametric modeling and feature-based modeling may complicate a translation between two established model architectures.
14
3 Schema extensions
3.1 Summary of data types and property sets
3.1.1 New definitions proposed by ST-5
• IfcTimberConstructionDomain schema
(should be integrated into IfcStructuralElementsDomain)
• IfcShapeAspectProperties, IfcShapeAspectBendingProperties,
IfcShapeAspectCutoutProperties, IfcShapeAspectHoleProperties,
• Pset_ElementComponentCommon, Pset_FastenerGlue,
Pset_FastenerGroup, Pset_MechanicalFastenerBolt,
Pset_MechanicalFastenerNail, Pset_MechanicalFastenerNailPlate,
Pset_MechanicalFastenerScrew, Pset_MechanicalFastenerStaple
• Pset_TimberElementQuality
• IfcMechanicalTimberMaterialProperties
3.1.2 Changed definitions proposed by ST-5
• IfcMaterial: not limited to isotropic materials anymore
• IfcMechanicalFastener: deleted
• IfcMechanicalFastenerType: attributes added, use definition extended
• IfcMemberType, IfcFastener, IfcExtendedMaterialProperties,
IfcStructuralMember:
extended use definitions
• IfcShapeAspect: mandatory attribute changed into optional attribute;
informal proposition added
• IfcSharedComponentElements schema: property sets for fasteners
• IfcMaterialPropertyResource schema: additional entity
IfcMechanicalTimberMaterialProperties as a new immediate subtype of
IfcMechanicalMaterialProperties
• IfcWallTypeEnum: one item added
3 Schema extensions
15
3.1.3 Unchanged definitions used by ST-5 (excerpt)5
• IfcRelAssociatesMaterial
• IfcGeneralMaterialProperties, IfcHygroscopicMaterialProperties
• IfcRectangleProfileDef, IfcCircleProfileDef, IfcCompositeProfileDef,
IfcArbitraryClosedProfileDef, IfcIShapeProfileDef
• IfcElementQuantity
• IfcBeam, IfcColumn, IfcMember, IfcMemberTypeEnum,
IfcDiscreteAccessory, IfcDiscreteAccessoryType, IfcFastenerType,
IfcElementAssembly, IfcWall, IfcSlab, IfcRoof, IfcBuildingElementPart
• IfcRelConnectsWithRealizingElements
• IfcStructuralProfileProperties
3.2 IfcTimberConstructionDomain Schema6
Scope of the IfcTimberConstructionDomain schema, in conjunction with other schemas related to physical aspects of the building model, are information requirements of
detailed planning of timber structures and in fabrication and erection of timber
structures. Modern building systems using timber and engineered wood products are
covered as well as traditional timber building styles.
HISTORY: New schema proposed by ST-5.
Interfaced schemas (4):
REFERENCE FROM IFCKERNEL
(IfcPropertySetDefinition);
REFERENCE FROM IFCMEASURERESOURCE
(IfcAreaMeasure,
IfcBoolean,
IfcLabel,
IfcLengthMeasure,
IfcPlaneAngleMeasure,
IfcPositiveLengthMeasure,
IfcPositivePlaneAngleMeasure);
REFERENCE FROM IFCPROPERTYRESOURCE
(IfcProperty);
REFERENCE FROM IFCREPRESENTATIONRESOURCE
(IfcShapeAspect);
5
This subsection lists some of existing definitions that are used by the Structural Timber Model but are
neither extended nor modified. The intention is to provide reference for future IFC developments.
6
The whole content of this schema is expected to become integrated into IfcStructuralElementsDomain due to large overlapping with steel detailing. The new schema is held separately in this
proposal only in order to expose the model extensions and their interfaces to existing model items.
16
Entities (6):
IfcShapeAspectBendingProperties, IfcShapeAspectCutoutProperties,
IfcShapeAspectHoleProperties, IfcShapeAspectProperties,
3.3 Locations of model extensions in the
IFC 2x2 architecture
fig. 3-1
Graph of added, changed, and interfaced schemas
extended use
definition
...
to be
integrated
6 new entities
1 new pset
Architecture
Domain
Structural
Analysis
Domain
Structural
Elements
Domain
Timber
Construction
Domain
Shared
Facilities
Elements
Shared
Mgmt
Elements
Shared
Component
Elements
Shared
Bldg
Elements
Domain Layer
Shared
BldgServices
Elements
Process
Extension
IFC 2x2 platform
ISO/PAS 16739
out of platform
new by ST-5
1 changed
attribute
Core Layer
...
Resource Layer
Measure
Resource
extd. use
definition,
extended
enumertn.
Product Control 1 entity deleted,
Exten- Exten- 1 entity extd.,
8 new psets,
sion
sion
extended use
definitions
Kernel
1 new entity,
extended use
definition
Representation
Resource
Property
Resource
Profile
Property
Resource
Material
Property
Resource
4 schemas interfaced by TimberConstructionDomain
17
4.1 Material resources
4.1.1 IfcMaterial7
Definition from IAI: A homogeneous substance that can be used to form elements.
NOTE: Usage of anisotropic materials is defined in IfcMaterialPropertyResource schema and in use definitions of applicable element entities.8
See [2] for complete definition.
4.1.2 IfcRelAssociatesMaterial9
Definition from IAI: Objectified relationship between a material definition and
building elements to which this material definition applies. — See [2] for complete
definition.
Discussion
IFC 2x2 Addendum 1 extended the applicability of IfcRelAssociatesMaterial.RelatedObjects to subtypes of IfcTypeProduct, for example IfcMemberType. This will be the
standard way of material association in the Structural Timber Model. Type objects (as
opposed to occurrence objects) are meant to provide as much member configuration
details as possible, including material information. The same was intended by the IAI
ST-4 project, see [4] volume II.
4.1.3 IfcExtendedMaterialProperties10
[see also subsection 7.1.3]
Definition from IAI: A container class for user defined properties of associated
material. This provides a mechanism to assign properties that have not been defined
in IFC specification. — See [2] for complete definition.
HISTORY: New Entity in IFC 2x.
Extended use definition proposed by ST-5.
7
defined in IfcMaterialResource schema; part of IFC 2x2 Platform
8
Applicable entities are subtypes of IfcElement, especially subtypes of IfcBuildingElement, and
subtypes of IfcBuildingElementType.
9
defined in IfcProductExtension schema; part of IFC 2x2 Platform
10
defined in IfcMaterialPropertyResource schema (IFC 2x2 non-platform part)
18
Use definition for properties of wood and wood-based materials
This is a collection of properties applicable to wood-based materials that specify kind
and grade of material as well as moisture related parameters.
Name
Property Type Data Type
Definition
material quality properties
Species
wood species of a solid wood or
IfcProperty\
IfcLabel
laminated wood product
SingleValue
Strength\
grade with respect to mechanical
IfcProperty\
IfcLabel
Grade
strength and stiffness
SingleValue
Appearance\ IfcProperty\
grade with respect to visual quality
IfcLabel
Grade
SingleValue
properties of laminated materials
Layup
configuration of the lamination
IfcProperty\
IfcLabel
SingleValue
Layers
number of layers
IfcProperty\
IfcInteger
SingleValue
Plies
number of plies
IfcProperty\
IfcInteger
SingleValue
properties related to moisture effects
Moisture\
total weight of moisture relative to
IfcProperty\
IfcPositive\
Content
SingleValue
RatioMeasure oven-dried weight of the wood
Dimensional\ IfcProperty\
weighted dimensional change
IfcPositive\
Change\
SingleValue
RatioMeasure coefficient, relative to 1% change in
Coefficient
moisture content
Thickness\
swelling ratio relative to board
IfcProperty\
IfcPositive\
Swelling
SingleValue
RatioMeasure depth
NOTE: The ratio measures are often specified in percent. All percentages have
to be divided by 100% in order to be expressed as a dimensionless IfcPositiveRatioMeasure.
IfcExtendedMaterialProperties is furthermore a container class for user-defined
properties of associated material, e.g. input for energy calculation, like thermal
conductivity. See [2] for use definition.
4.1.4 Other material resource entities11
IfcGeneralMaterialProperties contains an attribute for material mass density (specific
gravity). IfcHygroscopicMaterialProperties contains an attribute for vapor permeability. See [2] for definition of these entities. See section 4.3 for material related
property sets. See section 7.1 for mechanical material properties.
11
defined in IfcMaterialPropertyResource schema (IFC 2x2 non-platform part)
19
4.2 Shapes, cross sections, profile resources
4.2.1 Shape representation
See also “Part III: Implementation Guide” and geometry use definitions of respective
building elements in following chapters.
Standard member shapes of linear members
Most members used in timber construction can be geometrically represented by
IfcExtrudedAreaSolid.12 Profile definitions for IfcExtrudedAreaSolid.SweptArea that
are most useful for linear members are
• IfcRectangleProfileDef
e.g. for beams of solid timber, glulam, or LVL;
• IfcCircleProfileDef
e.g. for round posts and logs;
• IfcCompositeProfileDef
e.g. for custom composite beams, e.g. I-beams;
• IfcArbitraryClosedProfileDef e.g. for industrially available composite beams;
• IfcIShapeProfileDef
e.g. for industrially available symmetric I-beams.
The extrusion direction would be lengthwise in these standard cases (i.e. orthogonally
to the profile; thus the cross section is the same as the profile and the cut length is the
same as the extrusion length). Further conventions are specified in geometry use
definitions of according entities for building elements and element types.
Standard member shapes of planar members
IfcArbitraryClosedProfileDef is the profile definition that is most useful for planar
members (wood-based panels) with arbitrary outline. IfcRectangleProfileDef could
potentially be used for panels with rectangular outline, however it is deprecated in
favor of IfcArbitraryClosedProfileDef (for reasons of uniform representation and
because of the centric local origin of ordinates of the rectangle profile). The extrusion
direction would be depthwise, perpendicular to the profile. Thus the profile is
identical with the panel contour and the extrusion depth identical with the material
thickness.
Planar members, especially planks, may also be lengthwise extruded similar to
beams. The material thickness has then to be determined from the profile.
Further conventions are specified in geometry use definition of according entities for
building elements and element types.
Non-standard member shapes
Irregular member shapes, like tapered beams, cambered beams, arcs etc. can be
represented by IfcExtrudedAreaSolid with sideward extruded IfcArbitraryClosedProfileDef in most cases; IfcSectionedSpine with a lengthwise spine curve may also
be applicable.
12
IfcExtrudedAreaSolid is defined in IfcGeometricModelResource schema. Profile definitions are
defined in IfcProfileResource schema. Both schemas are part of IFC 2x2 Platform.
20
Cambered beams with only a slight precamber—such as for partial compensation of
deflection under load—should be represented as a straight beam. The precamber
would be expressed like a non-geometric property of the member.
Bent plywood is singly curved and can therefore be represented by sideward extrusion, possibly in conjunction with clipping. The extrusion direction would be
perpendicular to the depth of the plywood panel. Other shells, like shells composed of
joined boards, might be doubly curved and can only be approximated by the current
IFC geometric model using IfcFacetedBrep.
Fully detailed shapes of timber building elements including all shape features,
especially those common in joinery, will usually be represented by IfcFacetedBrep.
Other complicated shapes like that of mechanical fasteners, e.g. beam hangers, can be
represented by IfcFacetedBrep or by 2D projections.
Shapes of processing features
Feature shapes may be given in parameterized form or by explicit geometric
representation (in case of sawn or milled features usually as faceted surface model
which refers to parts of a faceted B-Rep of the members’ body). Shape parameters, if
available, take precedence.
Aggregations
The geometric representation of assemblies is implicitly given by the sum of the
representations of its parts. An additional simplified representation of the whole
aggregation may be given explicitly.
Simplified representation
Shapes can be represented in simplified form, e.g. as an IfcBoundingBox.
4.2.2 Shape parameters
See IfcProfileResource schema in [2] for geometric profile parameters. See section
7.2 for mechanical profile parameters.
4.3 Quantities, Material Quality
4.3.1 IfcElementQuantity13
Definition from IAI: An element quantity defines a set of derived measures of an
element’s physical property. — See [2] for definition.
Discussion
One property that is important for lists of parts for timber members and steel
members is missing in IfcElementQuantity: Miter angles. In order to express angle
measures in a quantity property set, a new subtype of IfcPhysicalQuantity would be
necessary. The ST-5 proposal does not introduce such a new quantity entity. Instead,
13
defined in IfcProductExtension schema; part of IFC 2x2 Platform
21
information about miter angles should be expressed through IfcShapeAspectCutoutProperties.
4.3.2 Pset_TimberElementQuality14
Applicability
Applicable classes
General property set
subtypes of IfcBuildingElement, IfcBuildingElementType,
IfcBuildingElementPart, or IfcCovering
Applicable type value
Definition
Definition from IAI: Material and quality related properties
common to timber members and wood-based products,
especially properties used in bills of material
Project Code
ST5
Property Definitions
Name
Definition
properties of built-up products
(e.g. vertically laminated timber decks, or siding consisting of boards)
BoardDepth IfcProperty\
depth of boards that are used to
IfcPositive\
SingleValue
LengthMeasure build up the composite
BoardWidth IfcProperty\
width of boards that are used to
IfcPositive\
SingleValue
BoardLength IfcProperty\
length of boards that are used to
IfcPositive\
SingleValue
prefabrication properties
Surface\
e.g. ‘Rough’, ‘Planed’, ‘Grinded’
IfcProperty\
IfcLabel
Quality
SingleValue
Lengthwise\ IfcProperty\
e.g. ‘Rough’, ‘Planed’, ‘Grinded’,
IfcLabel
Widthwise\
e.g. ‘Rough’, ‘Planed’, ‘Grinded’,
IfcProperty\
IfcLabel
Precamber
precamber of a glulam beam or of a
IfcProperty\
IfcPositive\
SingleValue
LengthMeasure truss, given as absolute value
Precamber\
precamber of a glulam beam or of a
IfcProperty\
IfcPositive\
Ratio
SingleValue
RatioMeasure truss, given relative to length
14
proposed for new IfcTimberConstructionDomain schema or IfcStructuralElementsDomain schema
(IFC 2x2 non-platform part)
22
5 Building elements
5.1 Members and accessories:
Occurrence objects
5.1.1 IfcBeam, IfcColumn, IfcMember15
IfcBeam represents a horizontal, or nearly horizontal, structural member designed to
carry loads. IfcColumn represents a vertical, or nearly vertical, structural member
designed to transfer loads to its base. An IfcMember is a structural member designed
to carry loads between or beyond points of support. It is not required to be load
bearing. — See [2] for full definitions.
Discussion
The Structural Timber Model will not introduce changes to the definitions of
IfcBeam, IfcColumn, IfcMember. There are however further aspects that should be
covered by View specifications:
• IfcMappedItem is the preferred—or only supported—form of geometric
representation for timber members.
• Type information shall be provided through IfcRelDefinesByType and an
appropriate subtype of IfcBuildingElementType.
• Material information shall be associated with the defining type object, not
directly with the occurrence.
IfcMember may represent linear members like beams but also planar members (panels
or board stacks), or curved members like glulam arches or shells made of planks.
Whenever an application program cannot determine for sure whether a member is a
beam, column, or other kind of member, IfcMember should be instantiated.
5.1.2 Accessories
Auxiliary parts may be represented by IfcDiscreteAccessory or, in case of building
service elements, by subtypes of IfcDistributionElement. See section 6.4 for fasteners
and other parts used in joints.
Parts that cover other elements, such as siding, sheathing, shingles, or vapor barrier
may be represented by IfcCovering. If more detailed geometry and quantity data are
required, e.g. the layout of wall sheathing including the contours of all its panels, use
multiple instances of IfcMember or IfcPlate instead of IfcCovering. IfcCovering is not
suited for production planning since it is difficult to track individual parts of the
covering.
15
defined in IfcSharedBldgElements schema; part of IFC 2x2 Platform
5 Building elements
23
5.2 Members and accessories: Type objects
16
5.2.1 IfcBeamType, IfcColumnType, IfcBeamTypeEnum,
IfcColumnTypeEnum
See [2] for definition of these entities and enumerations.
Discussion
For timber structures, IfcBeamType is applicable to joists, lintels, and main beams,
especially exposed beams. IfcColumnType is applicable to main columns, especially
exposed columns. IfcMemberType is applicable to all other timber members.
Nearly all members in common timber frame structures are
best described by IfcMemberType.
The timber-specific use definition of IfcMemberType as described below applies to
IfcBeamType and IfcColumnType as well. This use definition is not explicitly added
to IfcBeamType and IfcColumnType.
5.2.2 IfcMemberType
See [2] for definition from IAI.
HISTORY New entity in Release IFC2x Edition 2.
Additional use definition for timber members proposed by ST-5.
IFC2x2 ADDENDUM CHANGE: The entity IfcMember has been added to
serve as the occurrence object for all member types.
Use definition for steel members
See [2].
Use definition for members in timber structures
IfcMember(Type) may represent all kinds of members, including beams, panels,
arches, board stacks. The same conventions as for steel members apply with respect
to material associations, position number, non-geometric properties, and quantity
related properties.
Geometric representation
One or more of the following representations may be assigned as representation
maps: Up to one ‘Body’, ‘Blank’, ‘Fiber’, and/or ‘Layup’ may exist in the same
representation context. More than one ‘Bending’, ‘Cutout’, ‘Hole’, ‘Signature’,
and/or ‘Surface’ representation may exist in the same representation context.
reprs. identifier representation type
‘Body’
‘SweptSolid’, ‘Clipping’,
‘Brep’, or ‘CSG’
‘Blank’
‘SweptSolid’
16
content
body of the member, including all shape
features
body of the raw member without shape
features, i.e. before processing
24
‘Fiber’
one IfcCurve or
one IfcDirection
‘Layup’
‘Bending’,
‘Cutout’,
‘Hole’,
‘Signature’,
‘Surface’
a line, curve, or direction running in
parallel or concentric with the grain or
lamination
one IfcDirection
a direction perpendicular to the lamination (perpendicular to glue lines);
in case of unbalanced layups, it points
from the tension face to the compression
face of the layup
see Ifc ShapeAspectBendingProperties,
Ifc ShapeAspectCutoutProperties,
Ifc ShapeAspectHoleProperties,
Ifc ShapeAspectSignatureProperties,
Ifc ShapeAspectSurfaceProperties
The following constraints apply to ‘SweptSolid’ representation:
• IfcRectangleProfileDef shall be supported. IfcIShapeProfileDef, IfcCircleProfileDef, IfcCompositeProfileDef and IfcArbitraryClosedProfileDef
should also be supported.
• The extrusion axis shall be perpendicular to the swept profile:
IfcExtrudedAreaSolid.ExtrudedDirection.DirectionRatios = (0,0,1).
In the following illustrations and propositions, xP and yP denote the 2D coordinate
system of the profile definition (in case of a IfcParameterizedProfileDef: before
transformation by its Position). zE denotes the extrusion direction.
In case of common beams and posts, IfcExtrudedAreaSolid.Depth equals the gross
length of the member. In case of wood-based panels, the profile may represent the
outline of the panel (while the extrusion depth is identical to the panel’s thickness) or
it may represent a cross section of the panel (while the extrusion depth is the length or
with of the panel).
fig. 5-1
Extruded area solids for simple beams and panels
zE
profile
beam
panel
panel (alternative)
Cambered beams with only a slight precamber, e.g. for compensation of deflection,
shall be represented as a straight beam with precamber expressed in an attached
property set.
Material orientation
If not indicated otherwise by ‘Fiber’ and/or ‘Layup’ representations, the following
orientation of material is implied by the IfcExtrudedAreaSolid representation:
• Beam-like members:
The grain of a wooden member is oriented in parallel to zE. The layup of
glulam and LVL is directed in yP or xP. I.e. glue lines or veneers are
coplanar to the plane xP zE or yP zE.
5 Building elements
25
If xP is the width and yP the depth of the beam, in-plane bending and inplane shear occur due to load in yP zE. Out-of-plane bending and out-ofplane shear occur under load in xP zE. Axial loading occurs in parallel to zE.
• In case of glulam beams with unbalanced layup, the compression face is
located on top with respect to the global z direction. I.e. it depends on the
object placement of the member’s occurrence.
• Wood-based panels:
The lamination (the veneer) of a wood-based panel is oriented perpendicular
to the thickness of the solid model. Therefore, in-plane bending and in-plane
shear occur due to load within the plane of width × length (the panel acts as
a membrane). Out-of-plane bending and out-of-plane shear (rolling shear;
the panel acts as a slab) occur under load which is directed in parallel with
the thickness of the solid model. No particular orientation of face grain or
unbalanced layups is implied by IfcExtrudedAreaSolid.
fig. 5-2
Material orientation implied by IfcExtrudedAreaSolid
yP
yP
zE
zE
xP
th
zE
xP
plywood
len
gth
xP
wid
yP
wood
glulam
LVL
If a ‘Fiber’ representation is given, the elastic modulus and permissible stress is
highest in parallel to the ‘Fiber’ direction. In other words, resistance of orthotropic
materials against bending about an axis perpendicular to this direction is higher than
against bending about this direction.
fig. 5-3
Examples of ‘Fiber’ and ‘Layup’ representations
‘Body’ representation
‘Fiber’ representation
tension face
‘Layup’ representation
fa
ce
gr
ain
‘Body’ representation
‘Fiber’ representation
See [2] for EXPRESS specification, attribute definitions, and inheritance graph of
IfcMemberType.
26
5.2.3 IfcMemberTypeEnum
Definition from IAI: This enumeration defines the different types of linear elements
an IfcMemberType object can fulfill. — See [2] for definition.
Discussion
The identifiers PLATE and STUD should not be used for sloped members, at least
not in the context of prefabricated walls. Plates that are not strictly horizontal or studs
that are not strictly vertical with respect to the local coordinate system of the
respective wall segment might instead be typed as USERDEFINED. This restriction,
if desired, should however be imposed by a View definition, not at the model level.
Note that an IfcMemberType with ElementType = PLATE is something different from
an IfcPlate(Type). The former are special beam-like frame parts, the latter are planar
parts.
Other commonly used member types like ‘blocking’, ‘rim board’, ‘sill’, ‘truss extension’ and so forth are too specific for timber construction to include them as
predefined items of IfcMemberTypeEnum into interoperability layer. Such types may
be specified by IfcMemberType.ElementType.
5.3 Assemblies
5.3.1 IfcElementAssembly, IfcWall, IfcSlab, IfcRoof17
See [2] for definitions of IfcElementAssembly, IfcWall, IfcSlab, IfcRoof. Assemblies
usually relate to member occurrences like IfcMember via IfcRelAggregates.
TODO: Property sets for purposes of transport and erection planning, e.g.
transport size and weight, assembling place of walls and slabs…
Discussion
It is often necessary to distinguish between aggregated (built-up) and “monolithic”
wall objects and other elements. Since it is not possible to introduce a new attribute
for this purpose without breaking IFC 2x platform compatibility, a distinction of such
elements can only be accomplished by means of existing inverse attributes which are
inherited from IfcObject:
• Aggregated elements can be recognized by the size of IsDecomposedBy.
• Partial elements can be recognized by the size of Decomposes.
• Both of these INVERSE SETs are empty for “atomic” elements.
17
IfcElementAssembly is defined in IfcProductExtension schema; part of IFC 2x2 Platform. IfcWall,
IfcSlab, IfcRoof are defined in IfcSharedBldgElements schema; part of IFC 2x2 Platform.
5 Building elements
27
5.3.2 IfcWallTypeEnum18
Definition from IAI: This enumeration defines the different types of walls an
IfcWallType object can fulfill:
• STANDARD: A standard wall, extruded vertically with a constant thickness
along the wall path.
• POLYGONAL: A polygonal wall, extruded vertically, where the wall
thickness changes along the wall path.
• SHEAR: A shear wall, having a non-rectangular cross section.
• FRAME: A stud-framed wall consisting of studs, sheathing etc., should be
extruded vertically with a constant thickness along the wall path.
• USERDEFINED: User-defined wall element.
• NOTDEFINED: Undefined wall element
HISTORY New Enumeration in Release IFC2x Edition 2.
Additional item FRAME proposed by ST-5.
EXPRESS specification:
TYPE IfcWallTypeEnum = ENUMERATION OF
(STANDARD,
POLYGONAL,
SHEAR,
FRAME,
USERDEFINED,
NOTDEFINED);
END_TYPE;
Discussion
The FRAME item can be used for walls with timber or steel frames, inner and outer
walls, structural and non-structural walls. Geometric characteristics of STANDARD
walls apply to stud-framed walls as well.
5.3.3 Layers of assemblies (IfcBuildingElementPart19)
Assemblies in light timber frame construction style (wall, floor, and roof assemblies)
consist of layers. It is often necessary to capture which members belong to which
layer. This can be modeled in two alternative ways:
• Aggregate assembly objects from instances of IfcBuildingElementPart, and
aggregate each IfcBuildingElementPart from members. An advantage of this
method is that processing features can be assigned not only to members and
the assembly but also to parts, thus allowing for finer specification of how
and when a processing feature shall be applied.
• Aggregate assembly objects directly from members. Also group members,
which belong to a layer, by means of IfcRelAssignsToGroup and IfcGroup.
An advantage of this method is that such a layer group could span over all
18
19
defined in IfcStructuralElementsDomain schema (IFC 2x2 non-platform part)
28
assemblies of the same kind of the whole building. This way, all members
that fulfill the same function can be quickly retrieved without iterating over
all assemblies or members.
Both methods have a disadvantage: There is no possibility to establish a direct link to
the layer concept of the architectural model. Architectural elements such as walls and
floor slabs may be layered by means of IfcMaterialLayer/ ~Set/ ~SetUsage. Applications that are aware of both concepts of layering have to ensure consistency between
the architectural and the structural concept.
If layers are expressed using IfcBuildingElementPart, each IfcBuildingElementPart
may be associated with the according IfcMaterialLayer through IfcRelAssociatesMaterial. However this association in itself does still not guarantee consistency with
the architectural model.
If layers are expressed by IfcGroup, IfcMaterialLayer cannot be associated with the
group. It is furthermore not advisable to associate IfcMaterialLayer directly to the
members within the layer, since this association would interfere with the actual
material of each member.
29
6.1 Processing features: Modeling decisions
Approach by ST-5 β1
There were two occurrence objects proposed in the 1st and 2nd beta release of the
Structural Timber Model — IfcProcessingFeature and IfcSurfaceTreatment.
IfcProcessingFeature extends the IFC 2x2 feature concept proposed by the ST-3
project.
The advantage of features at the occurrence object level is the great variety of
relationships that these feature objects are able to engage in. Such relationships
include decomposition, connection realization, assignments of various kinds (e.g. to
objects other than the one which possesses the feature, or assignments to processes or
actors).
fig. 6-1
Relationships between members and features in ST-5 β1
occurrence objetcs
type objects
IfcRel...
S[1:?]
(ABS) IfcElement
IfcRel...
(ABS) IfcFeatureElementType
1
IfcCutoutFeatureType
IfcRel...
S[1:?]
IfcRel...
IfcProcessingFeature
S[1:?]
IfcSurfaceTreatment
IfcHoleFeatureType
IfcMiterFeatureType
IfcTimberFeatureType
Approach by ST-5 β3 20
The 3rd beta release deletes the two occurrence entities and moves feature information
mostly into the geometric representation of building elements. There are several
benefits:
• All features of an element may be put into its type object; see figure below.
Thus the type object becomes a true representation of a ‘manufacturing
position’. All manufacturing characteristics of identically manufactured
elements are consolidated in one instance of the associated type object.
20
The ST-5 Release Candidate 1 contains the same feature entities and relationships as ST-5 β3. The
feature entity names have been changed to IfcShapeAspect[…]Properties in order to avoid confusion
with the IFC 2x2 feature entities introduced by ST-3.
30
fig. 6-2
Relationships between members and features in ST-5 β3
occurrence objetcs
type objects
IfcRel...
S[1:?]
(ABS) IfcElement
*L[1:?]
1
fig. 6-3
Alternative relationships in ST-5 β3 (used with assemblies)
occurrence objetcs
(partial) type objects
(ABS) IfcElement
1
IfcRel...
S[1:?]
• It is also still possible to address features in occurrence objects.
• Applications outside of the structural domain are not prepared for the β1
feature concept. All existing and most future IFC implementations would
not have been able to combine the shape representations of the element and
its features. The β3 concept integrates the feature shape representations into
the product representation of the member. Non-structural applications do
not have to deal with feature representations; they should simply ignore
representations other than the ‘Body’ representation.
• It is now easy to keep all processing feature entities out of the IFC
Interoperability Layer. The β3 proposal holds feature entities in the Domain
Layer. Interoperation with applications of non-structural domains occurs
through shape representation, i.e. at the Resource Layer.
• The β1 concept implied Boolean subtractions or additions of feature shapes,
i.e. CSG (constructive solid geometry). The new concept allows either CSG
or B-Rep (boundary representation, also surface models). B-Rep is better
suited for timber CAD and CAM, which are surface oriented applications.
31
• Another advantage is easier migration from the product models DtH [5] and
PSS [6] to IFC. This includes integration of the bending feature that was
omitted in the 1st and 2nd beta.
• According to a preliminary evaluation of CIS/2 LPM, the β3 proposal
should also cover the requirements of a transition or mapping between
CIMsteel and IFC. The LPM contains feature entities on the type objects’
side as well as on the occurrence objects’ side.
There are some disadvantages of the ST-5 β3 feature concept:
• The major drawback of the new feature concept is the loss of ability to put
features into relationships.
• The existing ST-3/ IFC 2x2 feature concept is not used by ST-5 anymore.
• A subtle platform change regarding the existing IfcShapeAspect definition is
required.
Note that the feature concept proposed by ST-5 β3 is not entirely new to IFC. The
concept already exists with door styles and window styles. Lining and panels can be
understood as features of doors and windows. The features can be defined by
parameters or by explicit shape or both. Explicit feature shape is provided by shape
aspects of the door or window shape. This concept was introduced by IFC 2.0.
The ST-5 β3 and rc1 proposal should provide enough feature capabilities for timber
structures and probably also for steel structures in foreseeable practice. Advanced
applications may however need the ability of features to engage in relationships with
elements other than the building element they modify; therefore they would need
feature occurrence objects. Examples:
• Advanced applications for concrete structures may require to associate
reinforcements with shape features such as corbels or openings.
• Advanced production management applications may require to associate
processing features with fabrication processes, actors, and costs.
• CIS/2 LPM potentially allows for relationships between feature objects and
objects other than the modified building element. An advanced CIMsteelIFC mapping may require the same capability in IFC. However it is not
clear whether such relationships are actually used by LPM implementations.
Parametric and explicit feature modeling
Both the β1 and β3 proposals model features partially parametric, partially by explicit
shape. The distinction between parametric and explicit parts was less clear in β1 than
in β3: IfcTimberFeatureType of β1 contained a special type of surface model which
mixed explicit vertex data with implicit topology information. This surface model is
now replaced by IfcShapeAspectCutoutProperties in conjunction with the standard
surface model of the IFC Geometric Model Resource.
The parametrically modeled IfcMiterFeatureType of β1 was deleted in favor of the
more versatile IfcShapeAspectCutoutProperties. IfcShapeAspectCutoutProperties
uses explicit shape a priori but also allows for parametric modeling. Requirements of
different use cases—e.g. conventional joinery versus light timber frame structures—
are thus better integrated at the model level.
32
6.2 Processing features: Property sets
6.2.1 IfcShapeAspect21
Definition from ISO/IS 10303-41:1994: The shape aspect is an identifiable element of
the shape of a product.
Definition from IAI: The IfcShapeAspect allows for grouping of shape representation
items that represent aspects (or components) of the shape of a product. Thereby shape
representations of components of the product shape represent a distinctive part to a
product that can be explicitly addressed.
NOTE: The definition of this class relates to the STEP entity shape_aspect.
Please refer to ISO/IS 10303-41:1994 for the final definition of the formal
standard.
HISTORY: New Entity in IFC Release 2.0. PartOfProductDefinitionShape
attribute changed to OPTIONAL and informal proposition added by ST-5.
IFC2x2 PLATFORM CHANGE: Attribute PartOfProductDefinitionShape
declared OPTIONAL with upward compatibility for file based exchange.
Informal propositions:
1. If ShapeRepresentations points to shape representations that are part of an
IfcProductDefinitionShape, PartOfProductDefinitionShape must refer to this
instance of IfcProductDefinitionShape.
NOTE: PartOfProductDefinitionShape is only omitted if the shape representations are attached to an IfcRepresentationMap.
ENTITY IfcShapeAspect
ShapeRepresentations : LIST [1:?] OF IfcShapeRepresentation;
Name
Description
: OPTIONAL IfcText;
ProductDefinitional
: LOGICAL;
PartOfProductDefinitionShape : OPTIONAL IfcProductDefinitionShape;
END_ENTITY;
See [2] for attribute definitions and inheritance graph.
Discussion
The change proposed above enables IfcShapeAspect to be used with representation
maps. This way, aspects of shapes that are associated with a type object like
IfcMemberType can be addressed now.
21
defined in IfcRepresentationResource schema; part of IFC 2x2 Platform.
Though while IfcShapeAspect itself is not a property set, it is included in this section since it is used by
the following property set definitions.
33
6.2.2 IfcShapeAspectProperties22
Definition from IAI: Shape aspect properties include geometrical and nongeometrical parameters of shape features and processing features. Applicable objects
for such property sets are subtypes of IfcElementType or, through IfcRelDefinesByProperties, subtypes of IfcElement.
HISTORY: New entity proposed by ST-5.
ENTITY IfcShapeAspectProperties
ABSTRACT SUPERTYPE OF (ONEOF(
IfcShapeAspectBendingProperties,
IfcShapeAspectCutoutProperties,
IfcShapeAspectHoleProperties,
IfcShapeAspectSignatureProperties,
IfcShapeAspectSurfaceProperties))
SUBTYPE OF (IfcPropertySetDefinition);
FeatureType
Shape
: OPTIONAL IfcShapeAspect;
ExtendedProperties : OPTIONAL SET [1:?] OF IfcProperty;
END_ENTITY;
Attribute definitions:
FeatureType:
the kind of feature that is manifest as a shape aspect. Standard
values are given by use definition of subtypes of IfcShapeAspectProperties.
Shape:
one or more representations of the feature’s shape, addressed as
a shape aspect. The feature’s shape representation is part of the
representation of the overall product.
NOTE: IfcShapeAspectProperties.Shape.ShapeRepresentations shall point to
IfcShapeRepresentation(s) that are held in representation maps of
IfcShapeAspectProperties.DefinesType.RepresentationMaps or that are part of
IfcShapeAspectProperties.PropertyDefinitionOf.RelatedObjects.Representation.
ExtendedProperties: type dependent and custom properties of the shape feature, e.g.
shape parameters or manufacturing specific properties
Definition from IAI: Provides properties for curvatures or edges of bent elements
such as sheet metal, steel profiles, or plywood.
Geometry Use Definitions
Only bending with constant radius is supported by direct attributes and by the shape
representations described below. Bending with varying radius may be resolved
22
IfcShapeAspectProperties and all its subtypes are proposed for the new IfcTimberConstructionDomain schema or IfcStructuralElementsDomain schema (IFC 2x2 non-platform part).
34
through more complex shape representations and/or custom properties attached
through the inherited attribute ExtendedProperties.
The name of the IfcShapeRepresentation(s) referenced through the shape aspect in the
inherited Shape attribute shall be ‘Bending’. It shall contain one representation item
that is a subtype of IfcCurve and one representation item that is a subtype of IfcPoint.
Usually, an IfcPolyLine with only one line segment is used as the curve. The line is
the center line of the curvature. Its start and end point, projected onto the workpiece,
mark the start and end of the curvature or edge. The sense of direction of the center
line is significant for the sense of the bending angle. The bending occurs in the
mathematical positive sense about the center line if the Angle attribute is positive. The
part of the workpiece that is moved is indicated by the IfcPoint.
If the bent member possesses further processing features, the order of creation of the
features is of importance. The order of creation may be indicated by the order of
representations in the product representation (list IfcProductRepresentation.Representations), or by the order of representation maps in the product type (list IfcTypeProduct.RepresentationMaps), or by custom extended properties.
fig. 6-4
Representation of a component with bendings
st
nd
2 ‘Bending’ +90°
rd
z
y
z
y
x
‘Blank’
‘Body’
x
ENTITY IfcShapeAspectBendingProperties
Angle : OPTIONAL IfcPlaneAngleMeasure;
Radius : OPTIONAL IfcPositiveLengthMeasure;
END_ENTITY;
Angle:
amount of which the workpiece is bent
Radius:
radius of the curved inner surface of the workpiece; 0 for sharply bent
edges
Definition from IAI: Provides properties for machined recesses, holes, or cuts. The
inherited attribute FeatureType denotes the kind of cutout by the following standard
values:
• ‘Cut’: a single cut plane, or several combined cut planes near the end of the
member
• ‘Internal’: a cutout that creates an opening; a hole that is more complex than
IfcShapeAspectHoleProperties could describe
• ‘External’: a peripheral cutout, a recess
35
• ‘WeldPreparation’: a preparation for a weldseam
The inherited attribute Shape may refer to a shape aspect with one or more IfcRepresentation(s) whose RepresentationIdentifier is set to ‘Cutout’ and which contain the
explicit shape of the cutout. Custom shape parameters and non-geometric parameters
may be attached through the inherited attribute ExtendedProperties.
The product representation of the member that possesses one or more cutouts may
hold the following representations (among others):
rep. identifier representation type
‘Blank’
‘SweptSolid’
‘Cutout’
‘Body’
fig. 6-5
‘HalfSpace’
‘Clipping’
content
body without shape
features
‘SweptSolid’ ‘SurfaceModel’ cutouts
‘CSG’
‘Brep’
body with all shape
features
Representation of a member with cutout using CSG
‘Blank’
‘Cutout’
y
x
‘Body’
y
–
z
x
extruded
area solid
y
z
= x
z
extruded
area solid
constructive solid
geometry (CSG)
CSG: The volume of the feature is meant to be subtracted from the gross volume of
the member; i.e. the IfcSweptAreaSolid of the cutout is a void, not a solid body. The
instances of representation items within ‘Blank’ and ‘Cutout’ may also be used as
operand instances for the Boolean result of the ‘Body’. Implementation agreements
may impose geometric restrictions on the representations of cutouts.
fig. 6-6
Representation of a member with cutout using B-Rep
‘Blank’
‘Cutout’
y
x
‘Body’
y
x
z
extruded
area solid
y
z
surface model
(open B-Rep)
x
z
boundary representation (B-Rep)
B-rep: The sense of the shell normal of the cutout’s surface model shall agree with
the shell normal of the body’s B-rep. That is, the shell normal shall point away from
the interior of the solid. The instances of IfcFace within ‘Cutout’ may also be used
within the boundary representation of the ‘Body’.
36
Use definition for features of steel members23
Among others, the following standard subtypes exist, denoted by the inherited
attribute Name:
• Name=‘Miter’ and FeatureType=‘Cut’: One or two mitered ends of a beamlike member. Shape refers to one IfcShapeRepresentation whose
RepresentationType is set to ‘HalfSpace’ and contains one or two
IfcHalfSpaceSolid.
• Name=‘Coping’ and FeatureType=‘External’: A recess at the end face of a
member.
Use definition for features of timber members
For cutouts with FeatureType=‘Cut’, the following standard values for the inherited
Name attribute should be used:
• ‘DividingCut’: a cut that splits a raw member into two pieces
• ‘Miter’: one or two cuts that create mitered ends
• ‘EndCut’: one or more cuts at the end of the member
• ‘EdgeCut’: one or more cuts along the member
• ‘Shoulder’: two or more cuts at the end of the member, used in a stepped
joint
For cutouts with FeatureType=‘External’, the following standard values should be
used as Name:
• ‘BirdsMouth’: two faces that are perpendicularly located to each other; used
e.g. as a seating of a rafter on a purlin
• ‘Lap’: two faces adjacent to the end of the member; used e.g. for halved
joints
• ‘Rabbet’: a lengthwise recess consisting of two faces (or three or four if the
rabbet is not running along the whole length of the member)
• ‘Notch’: a recess with a ground face (parallel to an original surface of the
member) and two side faces; e.g. used for a T lap joint
• ‘Groove’: a slot
• ‘Mortise’: a recess for a mortise and tenon joint
• ‘Tenon’: a protrusion with two cheeks
• ‘StubTenon’: a tenon with four cheeks
• ‘Scarf’: a feature similar to a lap used e.g. as a hinge between segments of a
purlin
• ‘Seating’: a gain for a stepped joint
23
Use definitions for steel members are subject to change according to the deliverables of the IAI
ST4-2 project (steel detailing).
37
A ‘Mortise’ may also be of FeatureType=‘Internal’ when used in a through-mortiseand-tenon joint.
ENTITY IfcShapeAspectCutoutProperties
EdgeRadius
: OPTIONAL IfcLengthMeasure;
MiterAngles
: OPTIONAL LIST [1:?] OF IfcPlaneAngleMeasure;
END_ENTITY;
EdgeRadius: radius of edges between feature faces (i.e. not adjacent to faces of the
original shape of the member). If 0, the shape feature shall be sharpedged. If >0, edges shall be manufactured with a radius less than or
equal to the given value. If <0, denotes that the tool cuts into surfaces
beyond the edges; the tool’s radius is less than or equal to the given
absolute value.
MiterAngles: If the feature represents miters, the angles should be given by this list.
The method of measurement is subject to implementation agreements.
The primary purpose of this attribute is the easy extraction of miter
angles for lists of parts.
Definition from IAI: Provides properties for cylindrical holes or oblong holes. The
inherited attribute FeatureType denotes the kind of hole by the following standard
values:
• ‘Hole’: The holes are bored, milled, or punched through the whole element.
• ‘BlindHole’: The holes are bored or milled with a limited depth.
• ‘Center’: Small spots are punched or drilled as guidance.
• ‘Countersink’: The holes are conically widened.
• ‘Thread’: The holes are tapped with right-hand threads. The thread profile
type may be specified by association with a standards document.
• ‘LeftHandThread’: The holes are tapped with left-hand threads.
• ‘RingKeyway’: Ring keyways are milled as preparation for ring or shear
plate connectors.
The inherited attribute Shape should refer to a shape aspect with one IfcShapeRepresentation whose RepresentationIdentifier is set to ‘Hole’ and which contains
locations of the holes. Custom shape parameters and non-geometric parameters may
be attached through the inherited attribute ExtendedProperties.
Standard representation
The representation referred by the shape aspect contains one instance of IfcDirection
which is aligned in parallel with the bore axes. (All holes represented by one instance
of IfcShapeAspectHoleProperties run in parallel with each other.) It contains
38
furthermore one or more instances of subtypes of IfcPoint which represent the entry
points of the holes.
Representation of oblong holes
The representation contains one IfcDirection as alignment of the bore axes. It
contains furthermore one or more instances of subtypes of IfcCurve which represent
the paths of oblong holes (i.e. the center lines).
fig. 6-7
Round and oblong holes
entry points
direction
center line
direction
ENTITY IfcShapeAspectHoleProperties
Diameter : OPTIONAL IfcPositiveLengthMeasure;
Depth
Angle
: OPTIONAL IfcPositivePlaneAngleMeasure;
END_ENTITY;
Diameter: nominal diameter
Depth:
nominal depth in case of a blind hole, countersink, or thread
Angle:
angle of a countersink or of the beginning of the thread
Definition from IAI: Provides properties for markings or tags. The inherited attribute
FeatureType denotes the kind of signature by the following standard values:
• ‘Mark’: A graphic signature is applied, e.g. a marker line.
• ‘Tag’: A textual signature is applied.
The inherited attribute Shape should refer to a shape aspect with one IfcShapeRepresentation whose RepresentationIdentifier is set to ‘Signature’ and which contains
locations and, if applicable, the shape of the signature(s). Custom shape parameters
and non-geometric parameters may be attached through the inherited attribute
ExtendedProperties.
Representation of marks
The representation referred by the shape aspect contains one or more instances of
subtypes of IfcCurve.
Representation of tags
The representation contains one or more IfcAxis2Placement3D that indicates the
lower left corner of the text. The text is placed in the xy plane of the placement. The
39
content of the text is either provided by the inherited Name attribute or, if the Name is
not set, by the Tag attribute of the member object to which the signature is applied to.
fig. 6-8
A textual signature
placement
y
3x4
2
1
P
tag
z
ENTITY IfcShapeAspectSignatureProperties
Height : OPTIONAL IfcPositiveLengthMeasure;
Width : OPTIONAL IfcPositiveLengthMeasure;
END_ENTITY;
Height:
in case of a tag, height of the text
Width:
in case of a tag, width of the text
Definition from IAI: Provides properties for treated surfaces, machined surfaces, or
otherwise special surface areas.
The substance used as treatment or coating may be given through IfcMaterialSelect
which is associated with the treated member or member type. In this case, the
inherited Name attributes of IfcShapeAspectSurfaceProperties and of the respective
instance of IfcRelAssociatesMaterial shall match.
There are basically three ways to specify the amount of surface to be treated:
• All surfaces of the member are to be treated. The attribute EntireBody is set
to True. The inherited attribute Shape may additionally refer to one or more
representations with identifier ‘Body’.
• Only parts of the member are to be treated. The attribute EntireBody is set to
False. The quantity of the treated area is given in the attribute Area. No
further specification of the location of this area is provided.
• Only parts of the member are to be treated. The attribute EntireBody is set to
False. The treated parts are given by explicit geometry: The inherited
attribute Shape refers to a shape aspect with one or more IfcShapeRepresentation whose RepresentationIdentifier is set to ‘Surface’ and which contain
the location(s) and shape(s) of the surface feature.
40
The representation type is usually set to ‘SurfaceModel’, except for ‘Body’
representations.
Custom shape parameters and non-geometric parameters may be attached through the
inherited attribute ExtendedProperties.
Use definition for features of steel members24
The following standard subtypes exist, denoted by the inherited attribute
FeatureType: ‘Painting’, ‘Spraying’, ‘Powder’, ‘GritBlasting’, ‘FlameDescaling’,
‘Etching’, ‘Galvanizing’, ‘MechanicalTreatment’.
Use definition for features of timber members
The following standard subtypes exist, denoted by the inherited attribute FeatureType:
• ‘Painting’, ‘Spraying’, ‘Dipping’, ‘Tank’, ‘Pressure’, ‘AlternatingPressure’,
‘Vacuum’, ‘Bandage’, ‘Injection’ for coatings and preservative treatments;
• ‘Visible’, ‘Decor’ for visible parts of a member;
• ‘Planing’, ‘RoughPlaning’ for mechanical surface treatments;
• ‘Lock’ for areas that are not to be processed, e.g. where nail rows are to be
interrupted.
ENTITY IfcShapeAspectSurfaceProperties
Purpose
: OPTIONAL SET [1:?] OF IfcLabel;
EntireBody : OPTIONAL IfcBoolean;
Area
: OPTIONAL IfcAreaMeasure;
Depth
END_ENTITY;
Purpose:
the function(s) of the treatment, e.g. ‘Preparation’, ‘Primer’, ‘Finish’25,
‘CorrosionProtection’, ‘FireProtection’, ‘Aesthetic’26
EntireBody: true if the whole surface of the member is to be treated
Area:
quantity of the total area to be treated
Depth:
thickness of a coating, depth of penetration, or depth of the removed
surface material
24
Use definitions for steel members are subject to change according to the deliverables of the IAI
ST4-2 project (steel detailing). The suggested standard designations are based on PSS. Alternative or
additional standard designations may be derived from CIS/2 LPM, e.g. ‘ChemicalWash’, ‘BlastClean’,
‘SprayedCoat’, ‘BrushedCoat’, ‘DippedCoat’, ‘ElectroplatedCoat’, ‘Grind’, ‘Thermal’.
25
labels based on PSS
26
labels based CIS/2 LPM
41
6.3 Processing features: Extended properties
6.3.1 Subtypes of IfcShapeAspectProperties
The following extended properties may be attached to the attribute ExtendedProperties of instances of subtypes of IfcShapeAspectProperties:
Name
OrderOf\
Creation
IfcProperty\
IfcLabel
SingleValue
Place
IfcProperty\
SingleValue
IfcLabel
Machine
IfcProperty\
SingleValue
IfcLabel
Tool
IfcProperty\
SingleValue
IfcLabel
ToolMaterial IfcProperty\
SingleValue
ToolSpeed
IfcProperty\
SingleValue
IfcLabel
Tolerance27
Quality
IfcLinear\
VelocityMe
asure
IfcProperty\
IfcLength\
BoundedValue Measure
IfcProperty\
IfcLabel
SingleValue
Definition
hint on the order of creation of features,
may be an ordinal or a keyword.
Possible values are subject to
implementation agreements.
denotes where the processing feature
shall be manufactured: ‘supplier’,
‘shop’, or ‘site’
assigns the processing steps that are
needed to manufacture the feature to a
particular machine
assigns the processing steps that are
needed to manufacture the feature to a
particular tool
type of tool to be used
feed rate of the tool or of the workpiece
allowance; upper and lower limit of
fabrication tolerance
quality of the processing result, e.g.
‘visible’ for features that will be exposed
Name
Method
IfcProperty\
IfcLabel
SingleValue
Definition
technology used to deform the member, e.g.
‘cold’, ‘hot’
Name
CutWidth
27
IfcProperty\
IfcLength\
SingleValue
Measure
Definition
width of the gap that is created by the saw
or milling machine
Tolerances could also be related to building elements or to particular dimensions. But this is difficult
to model because the present IFC model does not support tolerances and dimensional constraints at all.
In order to avoid extensive changes to the IFC model which would need much more time to become
tested and accepted, it is proposed to assign tolerances only to machining feature objects for now.
42
Tool\
IfcProperty\
Alignment SingleValue
IfcLabel
Face\
IfcProperty\
28
Integrity
SingleValue
IfcLabel
Method
IfcLabel
IfcProperty\
SingleValue
position of the tool relative to cut plane:
‘before’ = in front of the defined cut plane,
‘behind’ = behind the plane and therefore
eroding the member by CutWidth,
‘centered’ = centered on the cut plane and
therefore eroding the member by ½
CutWidth
‘whole’ = the faces must be left intact;
‘inner’ = the tool may cut into the faces
near the feature’s edges; ‘none’ = the tool
may be driven into the faces at any place
technology used to create the cutout:
‘sawn’, ‘flame cut’, ‘sheared’, ‘punched’,
‘drilled’, ‘milled’, ‘laser’, ‘abrasion’
Name
Entry
Exit
Fit
IfcProperty\
IfcLabel
SingleValue
IfcProperty\
IfcLabel
SingleValue
IfcProperty\
SingleValue
Method
IfcProperty\
SingleValue
Number\ IfcProperty\
OfThreads SingleValue
Definition
‘splinterfree’ if the entry of the hole must
be manufactured with a splinter free finish
‘splinterfree’ if the exit of the hole must be
manufactured with a splinter free finish, or
‘manually’ if it shall be finished manually
IfcBoolean denotes whether the hole must be manufactured to tight fit for a fitting bolt or dowel
technology used to create the hole:
IfcLabel
‘drilled’, ‘milled’, ‘punched’, ‘laser’
IfcInteger count of threads
Name
Color
IfcProperty\
IfcLabel
SingleValue
Definition
color of a printed or stamped signature
Name
Irregula\
rity
Duration
28
IfcProperty\
IfcPositive\
SingleValue
Length\
Measure
IfcProperty\
IfcTime\
SingleValue
Measure
Definition
irregularity of the finished surface after a
mechanical treatment
total duration of the application process
This property is global for all faces of a cutout. Finer propositions for the tool path are possible by
splitting one feature into several IfcFeatureCutoutProperties.
Time\
Spec
IfcProperty\
ListValue
Tempera\
tureSpec
IfcProperty\
ListValue
43
for a thermal treatment (in steel construction): time from initial to maximum temperature, duration of maximum temperature,
time from maximum to final temperature
IfcThermo\ for a thermal treatment (in steel construction): initial, maximum, and final
dynamic\
Temperatu\ temperature
reMeasure
IfcTime\
Measure
6.4 Connections: Occurrence objects29
6.4.1 IfcFastener
Definition from IAI: Representations of fixing parts which are used as fasteners to
connect or join elements with other elements.
HISTORY: New entity in IFC 2x2.
Changed use definition proposed by ST-5.
General usage
The exact type information of the IfcFastener is given in the ObjectType attribute
inherited from IfcObject or through an attached IfcFastenerType or subclasses of
IfcFastenerType. Standard type designations are provided for guideline below. Note
that mechanical fasteners are represented by instances of the subtype IfcMechanicalFastener.30
[delete IFC 2x2 table of standard fastener type designations] 31
Geometry Use Definitions:
See [2] for local placement and standard geometric representation.
Geometric Representation of Fastener Groups
One instance of IfcFastener may represent a group of several or many actual fixing
parts. Examples are arrays of bolts or lines of nails. The layout of such groups and the
amount of used parts may be provided parametrically through attached property sets
which are subject to implementation agreements.
A representation of a group of cylindrical mechanical fasteners may be provided with
IfcRepresentation.RepresentationIdentifier set to ‘Group’, containing one or more
items that are subtypes of IfcPoint or IfcCurve. These items locate the centers of the
fasteners’ heads. The fasteners’ axes are directed in the local z axis of the
representation.
29
IfcFastener, IfcMechanicalFastener, IfcDiscreteAccessory are defined in IfcSharedComponentElements schema (IFC 2x2 non-platform part).
30
IfcMechanicalFastener should be deleted.
31
Type designation via IfcFastenerType or its subtypes is preferred.
44
If a curve representation is used, quantity and/ or spacing of the fasteners shall be
defined by a property set. Multiple curves may form an array. If point representation
is used, quantity and spacing of the fasteners can be determined from the
representation without further parameter properties.
NOTE: Based on implementation agreements, a fastener group may also be
modeled by multiple instances of IfcFastener and one instance of IfcGroup and
IfcRelAssignsToGroup. The IfcGroup may be further defined by property sets.
See [2] for EXPRESS specification and inheritance graph.
Discussion
Modeling of fastener groups through IfcGroup is not feasible for large fastener groups
in modern timber structures, especially rows of nails or staples. This modeling
method will therefore not be used in timber applications.
A third method to model fastener groups could be by means of a new subclass of
IfcFastener, for instance IfcFastenerArray, defined in IfcStructuralElementsDomain
schema or IfcSharedComponentElements schema. This entity could carry optional
attributes that describe spacing and quantity of grouped fasteners.
DtH, PSS, and apparently also CIMsteel LPM/5 represent groups of mechanical
fasteners only as lists of layout points, using the same occurrence entity for single
fasteners as for grouped fasteners. Single fasteners are just a border case of a fastener
group. No parametric descriptions of fastener groups are exchanged.
Note that a load carrying mechanical joint in structural steelwork always consists of
more than one fastener. This is mostly (but not always) also true for timber structures.
6.4.2 IfcMechanicalFastener (to be deleted)
Definition from IAI: Fasteners connecting building elements mechanically.
HISTORY New entity in IFC Release 2x2
Deletion of entity proposed by ST-5
Discussion
IfcFastener shall be used instead. Mechanical fasteners may be modeled by a pairing
of IfcFastener with IfcMechanicalFastenerType.
6.4.3 IfcDiscreteAccessory
Definition from IAI: Representations of different kinds of accessories included in or
added to elements. — See [2] for complete definition.
Discussion
IfcDiscreteAccessory is used for intermediate components in connections of timber
structures, like beam hangers, straps, or nailed plates.
45
6.5 Connections: Type objects32
6.5.1 IfcFastenerType
Definition from IAI: The element type (IfcFastenerType) defines a list of commonly
shared property set definitions of a fastener and an optional set of product
representations. It is used to define fasteners mainly within structural and building
services domains (i.e. the specific type information common to all occurrences of that
type). — See [2] for complete definition.
6.5.2 IfcMechanicalFastenerType
Definition from IAI: The element type (IfcMechanicalFastenerType) defines a list of
commonly shared property set definitions of a fastener and an optional set of product
representations. It is used to define mechanical fasteners mainly within structural and
building services domains (i.e. the specific type information common to all occurrences of that type).
The occurrences of the IfcMechanicalFastenerType are represented by instances of
IfcMechanicalFastener IfcFastener.
HISTORY New entity in IFC 2x2.
Additional attributes and extended use definition proposed by ST-5.
General usage33
The exact type information of the IfcMechanicalFastenerType is given in the
ElementType attribute inherited from IfcElementType. Standard type designations are
provided for guideline below.
Object Type Description
'Bolt'
A threaded cylindrical rod that engages with a similarly threaded hole
in a nut or any other part to form a fastener.
'Nut'
A small square or hexagonal metal block with internal screw thread to
be fitted onto a bolt.
'Washer'
A disk, as of metal, plastic, rubber, or other material, placed beneath a
nut or at an axle bearing or a joint to relieve friction, prevent leakage, or
distribute pressure.
'Set'
A set comprised of one bolt, and one or more of nuts and washers. The
exact configuration of the set may be described by the inherited
attribute Name or by an attached property set.
'Screw'
A fastener with a tapered threaded shank and a slotted head.
'Nail'
A thin pointed piece of metal that is hammered into materials as a
fastener.
'Staple'
A doubly pointed piece of metal that is hammered into materials as a
fastener.
32
IfcFastenerType, IfcMechanicalFastenerType, IfcDiscreteAccessoryType are defined in IfcSharedComponentElements schema (IFC 2x2 non-platform part).
33
Use definitions for fasteners in steel structures are subject to change according to the deliverables of
the IAI ST4-2 project (steel detailing).
46
'Dowel'
'Shear\
Connector'
'NailPlate'
'Rivet'
A cylindrical rod that is accepted by tightly fitting holes in the
connected pieces.
A ring connector that is accepted by ring keyways in the connected
pieces; or a toothed circular or square connector that is pressed into the
connected pieces.
A piece of sheet metal with punched points that overlaps the connected
pieces and is pressed into their material.
A fastening part having a head at one end and the other end being
hammered flat after being passed through holes in the pieces that are
fastened together.
The exact configuration of a mechanical fastener type should be indicated through an
association with a document (e.g. a product standard), through an association with a
classification, or through an association with a library. Associations are resolved
through subtypes of IfcRelAssociates. Furthermore, a standardized short name may be
given by the inherited attribute Name.
ENTITY IfcMechanicalFastenerType
SUBTYPE OF (IfcFastenerType);
NominalDiameter : OPTIONAL IfcPositiveLengthMeasure;
NominalLength
Strength
FinishOrGrade
END_ENTITY;
NominalDiameter: nominal diameter of a cylindrical fastener
NominalLength:
nominal length
Strength:
strength rating of the fastener. This is called “property class”
for bolts. Examples of common property classes of metric steel
bolts are ‘4.6’, ‘8.8’, ‘10.9’. An example for a property class of
stainless steel bolts is ‘70’.
FinishOrGrade:
short name of surface finish or of the material grade of the
fastener. Examples of common finishes of steel bolts are
‘black’ (blackened), ‘ZP’ (zinc-plated), ‘ZY’ (zinc plating and
yellow passivation). An example for a grade of stainless steel
bolts is ‘A4’.
Discussion
The four proposed attributes, combined with a referenced product standard, determine
the complete configuration of common bolts, nuts, washers, and screws. This includes
geometric parameters like thread length (which is specified in the product standard)
or mechanical parameters like shear strength (which is specified in design codes and
is derived from the fastener’s size and property class).
For example, a reference to ISO 7412:1984 specifies “Hexagon bolts for highstrength structural bolting with large width across flats (short thread length) – Product
grade C – Property classes 8.8 and 10.9”.
Designations for property class, grade, and finish are specifications of fasteners, not
material designations. Different materials may result in the same grade. Therefore
these attributes are proposed as attributes of the fastener, not as properties for an
47
IfcMaterial. An IfcMaterial like ‘5140’, ‘316’, ‘41 Cr 4’, or ‘1.4571’ can additionally
be attached to an IfcMechanicalFastenerType through IfcRelAssociatesMaterial.
Note that even though the examples given for the Strength of metric steel bolts look
like floating point numbers, they are actually not numbers used in calculations.
Therefore—and in order to accommodate other classification systems for all kinds of
mechanical fasteners—the attribute’s data type was chosen as IfcLabel.
6.5.3 IfcDiscreteAccessoryType
Definition from IAI: The element type (IfcDiscreteAccessoryType) defines a list of
commonly shared property set definitions of a discrete accessory and an optional set
of product representations. It is used to define a supporting element mainly within
structural and building services domains (i.e. the specific type information common
to all occurrences of that type). — See [2] for complete definition.
Discussion
IfcDiscreteAccessoryType is used for intermediate components in connections of
timber structures, like beam hangers, straps, or nailed plates.
6.6 Connections: Property sets34
6.6.1 Pset_ElementComponentCommon
Applicability
Applicable classes
General property set
subtypes of IfcElementComponent or
IfcElementComponentType
Definition
Definition from IAI: Properties common to different types of
fasteners and discrete accessories
Project Code
ST5
Name
IfcLabel
Place
SingleValue
Sunken
34
IfcProperty\
SingleValue
Definition
denotes where the fastener or accessory is
mounted: ‘Site’ = at the building site,
‘Shop’ = in the contractor’s shop,
‘Supplier’ = by the building materials
supplier
IfcBoolean denotes whether the fastener or accessory
must not protrude, i.e. must be driven
beneath the building elements’ surface
proposed for IfcSharedComponentElements schema (IFC 2x2 non-platform part)
The property sets may change in order to synchronize with the IAI project ST4-2 deliverables
(steel detailing).
48
6.6.2 Pset_FastenerGlue
Applicability
Entity specific property set
Applicable classes
IfcFastener, IfcFastenerType
Applicable type value SELF\IfcObject.ObjectType = 'Glue',
SELF\IfcElementType.ElementType = 'Glue'
Definition
Definition from IAI: Properties related to glued connections
Project Code
ST5
Name
IfcLabel
Place
SingleValue
CuringTime IfcProperty\
SingleValue
IfcTime\
Measure
Definition
denotes where the glue is applied and
cured: ‘Site’ = at the building site, ‘Shop’
= in the contractor’s shop, ‘Supplier’ = by
the building materials supplier
duration of the curing process, the time
during which the connected pieces are
pressed together
6.6.3 Pset_FastenerGroup
Applicability
Entity common property set
Applicable classes
IfcFastener
Definition
Definition from IAI: Parameters for fasteners that are
grouped in lines, e.g. rows of nails
Project Code
ST5
Name
Property Type
Spacing
IfcProperty\
SingleValue
Quantity
IfcProperty\
SingleValue
Data Type
IfcPositive\
LengthMeasure
IfcInteger
Control\
Parameter
IfcProperty\
SingleValue
IfcLabel
Mounting\
Place
IfcProperty\
SingleValue
IfcLabel
Sunken
IfcProperty\
SingleValue
IfcBoolean
Definition
the maximum gap between adjacent
fasteners
the total number of individual
fasteners used in the defined
connection
the property which governs the
group’s geometry; either ‘Spacing’
or ‘Quantity’
denotes where the fasteners are
mounted: ‘Site’ = at the building
site, ‘Shop’ = in the contractor’s
shop, ‘Supplier’ = by the building
materials supplier
denotes whether the fasteners must
be driven beneath the building
elements’ surface
49
6.6.4 Pset_MechanicalFastenerBolt
Applicability
Applicable classes
Applicable type value SELF\IfcElementType.ElementType = 'Bolt',
SELF\IfcElementType.ElementType = 'Nut',
SELF\IfcElementType.ElementType = 'Washer',
SELF\IfcElementType.ElementType = 'Set'
Definition
Definition from IAI: Properties related to bolt-type fasteners.
The properties of a whole set with bolt, washers and nut may
be provided.
It is usually not necessary to transmit these properties for
standardized bolts.
Project Code
ST5
Name
Property Type
Thread\
IfcProperty\
Length
SingleValue
HeadForm
IfcProperty\
SingleValue
KeyForm
IfcProperty\
SingleValue
KeySize
IfcProperty\
SingleValue
NutForm
IfcProperty\
SingleValue
WasherForm IfcProperty\
SingleValue
SingleValue
PartsAtHead IfcProperty\
ListValue
PartsAtMid
IfcProperty\
ListValue
PartsAtEnd
IfcProperty\
ListValue
Fit
IfcProperty\
SingleValue
IfcProperty\
SingleValue
Friction
Preload
Friction\
Coefficient
IfcProperty\
SingleValue
IfcProperty\
SingleValue
Data Type
IfcPositive\
LengthMeasure
IfcLabel
IfcLabel
IfcLabel
IfcLabel
IfcLabel
Definition
length of the threaded portion of the
bolt
shape of the head, e.g. ‘Hexagon’,
‘Countersunk’, ‘Cheese’
if applicable, shape of the head’s
slot, e.g. ‘Slot’, ‘Allen’
nominal size of the key
shape of the nut, e.g. ‘Hexagon’,
‘Cap’, ‘Castle’, ‘Wing’
shape of the washers, e.g.
‘Standard’, ‘Square’
diameter or width of the washers
IfcPositive\
LengthMeasure
parts of the bolt fitting which are
IfcLabel
assembled at the head’s side; e.g.
‘Head’, ‘Washer’
designations of those parts
IfcLabel
assembled between the connected
elements; e.g. ‘Shim’ or ‘Washer’
designations of those parts
IfcLabel
assembled at the nut’s side; e.g.
‘Washer’, ‘Lock Ring’, ‘Nut’,
‘Splint’
denotes whether the shaft’s diameter
IfcBoolean
matches that of the hole
denotes whether the connection
IfcBoolean
must be manufactured to provide
frictional resistance; requires
prestressing and prepared surfaces
prestressing force that is to applied
IfcForce\
on the bolt connection
Measure
friction coefficient of a preloaded
IfcPositive\
RatioMeasure connection
50
StressArea
IfcProperty\
SingleValue
IfcAreaMeasure area value used in strength
verification
6.6.5 Pset_MechanicalFastenerScrew
Applicability
Applicable classes
Applicable type value SELF\IfcElementType.ElementType = 'Screw',
SELF\IfcElementType.ElementType = 'Set'
Definition
Definition from IAI: Properties related to screw-type
fasteners, especially lag screws. The properties of a whole set
with screw and washer may be provided.
standardized screws.
Project Code
ST5
Name
Property Type
Thread\
IfcProperty\
Length
SingleValue
HeadForm IfcProperty\
SingleValue
KeyForm
IfcProperty\
SingleValue
KeySize
IfcProperty\
SingleValue
Washer\
IfcProperty\
Form
SingleValue
SingleValue
PartsAt\
IfcProperty\
Head
ListValue
PartsAtMid IfcProperty\
ListValue
Data Type
IfcPositive\
LengthMeasure
IfcLabel
IfcLabel
IfcLabel
Definition
length of the threaded portion of the
screw
shape of the head, e.g. ‘Hexagon’,
‘Countersunk’, ‘Raised’
if applicable, shape of the head’s slot,
e.g. ‘Slot’, ‘Allen’, ‘Phillips’
nominal size of the key
shape of the washers, e.g. ‘Standard’,
‘Square’
diameter of the washer, if a washer is
IfcPositive\
LengthMeasure required
parts of the screw fitting which are
IfcLabel
assembled at the head’s side; e.g.
‘Head’, ‘Washer’
designations of those parts assembled
IfcLabel
between the connected elements; e.g.
‘Shim’ or ‘Washer’
IfcLabel
6.6.6 Pset_MechanicalFastenerNail
Applicability
Applicable classes
Definition
Project Code
SELF\IfcElementType.ElementType = 'Nail'
Definition from IAI: Properties related to nail-type fasteners.
standardized nails.
ST5
51
Name
Shank
IfcProperty\
IfcLabel
SingleValue
HeadForm
Coated
Sunken
IfcProperty\
SingleValue
IfcProperty\
SingleValue
IfcProperty\
SingleValue
IfcLabel
IfcBoolean
IfcBoolean
Definition
type of shank, e.g. ‘Smooth’ for
common nails, ‘Ring’ for annular
ringed shank nails, ‘Screw’ for
helically threaded nails
shape of the head
denotes whether the shank is resincoated
denotes whether the head must be
driven beneath the surface
6.6.7 Pset_MechanicalFastenerStaple
Applicability
Applicable classes
Definition
Project Code
SELF\IfcElementType.ElementType = 'Staple'
Definition from IAI: Properties related to staple-type
fasteners.
standardized staples.
ST5
Name
Property Type
Width
IfcProperty\
SingleValue
Coated
IfcProperty\
SingleValue
Sunken
IfcProperty\
SingleValue
Data Type
Definition
nominal width of the staple’s back
IfcPositive\
LengthMeasure
denotes whether the points are resinIfcBoolean
coated
denotes whether the back must be
IfcBoolean
driven beneath the surface
6.6.8 Pset_MechanicalFastenerNailPlate
Applicability
Applicable classes
Definition
Project Code
SELF\IfcElementType.ElementType = 'NailPlate'
Definition from IAI: Properties related to nail plates
ST5
Name
Property Type
Gauge
IfcProperty\
SingleValue
Length
IfcProperty\
SingleValue
Width
IfcProperty\
SingleValue
Data Type
IfcLabel
Definition
gauge or thickness
length in case of a rectangular plate
IfcPositive\
LengthMeasure
width in case of a rectangular plate
IfcPositive\
LengthMeasure
52
6.7 Connections: Relationship objects
Discussion
All connections in timber structures involve realizing elements. That is, there are
usually two main members that are joined using assisting parts. Assisting parts may
be mechanical fasteners or glue (and perhaps processing features such as tenons).
Connections between two main members, realized by intermediary elements, may be
modeled by the IFC 2x2 entity IfcRelConnectsWithRealizingElements.
There are however connections between more than two main members at once.
Example 1: One horizontal row of staples on a wall section might cross several OSB
panels, connecting them with several blockings (short horizontal members between
studs). Example 2: In a node of a truss, two or sometimes three webs may meet with
the chord; all are held together by a nail plate at each side of the truss. The plates
cover all timbers that meet in the node.
Some alternatives exist to model such connections:
• Use as much instances of IfcRelConnectsWithRealizingElements as direct
load paths exist.
• Aggregate members into two superordinate elements. Connect the two
elements by one instance of IfcRelConnectsWithRealizingElements.
Connection semantics, e.g. information about load paths, might however be
difficult to retrieve.
• Assign all members and fasteners to a group using IfcRelAssignsToGroup.
Establish the meaning of the group at the application level. Part of the
connection semantics could be lost. The semantics were unavailable to
applications that are unaware of the group type.
• Assign members and fasteners to objects of the structural analysis domain
using IfcRelAssignsToProduct and instances of subtypes of
IfcStructuralMember and IfcStructuralConnection. Connection semantics
would be available to applications in the structural analysis domain.
• Simply aggregate all members and fasteners in one assembly using IfcRelAggregates and an instance of IfcElementAssembly. Connection semantics
would however be lost.
The last variant will be sufficient in most use cases.
53
7.1 Materials35
7.1.1 IfcMechanicalMaterialProperties
Definition from IAI: This is a collection of mechanical material properties normally
used for structural analysis purpose. It contains all properties which are independent
of the actual material type.
HISTORY: New Entity in IFC 2x.
Additional immediate subtype proposed by ST-5.
See [2] for complete definition.
7.1.2 IfcMechanicalTimberMaterialProperties
Definition from IAI: This is a collection of mechanical properties related to solid
wood and similar materials. Anisotropy is taken into account by different properties
according to grain direction and load types.
Use definition
Stresses may be given either as characteristic values (for use in limit state design
method or in load and resistance factor design method) or as allowable values (for use
in allowable stress design method). Characteristic and allowable values must not be
mixed in the same instance of IfcMechanicalTimberMaterialProperties. IfcExtendedMaterialProperties provides a means to determine the applicable design method.
All values shall be given for a standardized service condition, a standardized load
duration and a standardized reference size of the member according to local design
codes.
NOTE: In cases where mechanical material properties are graduated for
different given reference sizes, separate instances of IfcMechanicalTimberMaterialProperties and IfcMaterial have to be used for each required
graduation. Mechanically differing versions of a material are treated as different
materials. This is expressed by a uniqueness rule in IfcMechanicalMaterialProperties.
References to the orientation of grain or layup correspond to material orientation
given by geometrical or topological representation of element entities. α denotes the
angle between strain and fiber.
35
The following entities are defined in or proposed for IfcMaterialPropertyResource schema (IFC 2x2
non-platform part).
54
The inherited attributes have the following meaning:
YoungModulus: elastic modulus, mean value, α=0°
ShearModulus: shear modulus, mean value
Informal propositions:
1. Any given attribute of type IfcModulusOfElasticityMeasure shall be greater
than zero.
2. Any given attribute of type IfcPressureMeasure shall be greater than zero.
ENTITY IfcMechanicalTimberMaterialProperties
SUBTYPE OF (IfcMechanicalMaterialProperties);
YoungModulusMin
YoungModulusPerp
YoungModulusPerpMin : OPTIONAL IfcModulusOfElasticityMeasure;
ShearModulusMin
BendingStrength
TensileStrength
TensileStrengthPerp
CompStrength
CompStrengthPerp
RaisedCompStrengthPerp : OPTIONAL IfcPressureMeasure;
ShearStrength
TorsionalStrength
END_ENTITY;
YoungModulusMin:
YoungModulusPerp:
YoungModulusPerpMin:
ShearModulusMin:
BendingStrength:
TensileStrength:
TensileStrengthPerp:
CompStrength:
CompStrengthPerp:
RaisedCompStrengthPerp:
ShearStrength:
TorsionalStrength:
elastic modulus, minimal value, α=0°
elastic modulus, mean value, α=90°
elastic modulus, minimal value, α=90°
shear modulus, minimal value
bending strength
tensile strength, α=0°
compressive strength, α=0°
raised value for compressive strength, α=90°, which can
be used under material and code dependent conditions
(e.g. if deformation is tolerable)
shear strength
shear strength in torsion
55
7.1.3 IfcExtendedMaterialProperties
[see also subsection 4.1.3]
Use definition for mechanical properties of wood-based materials
Mechanical properties of wood-based beam materials
This is a collection of mechanical properties applicable to wood-based materials for
beam-like products, especially laminated materials like glulam and LVL. These
properties cover a wider variety of materials than IfcMechanicalTimberMaterialProperties. Anisotropy of such materials is taken into account by different properties
according to grain direction and load types.
All values shall be given for a standardized service condition, a standardized load
duration and a standardized reference size of the member according to local design
codes.
NOTE: In cases where mechanical material properties are graduated for
different given reference sizes, separate instances of IfcExtendedMaterialProperties and IfcMaterial have to be used for each required graduation.
Mechanically differing versions of a material are treated as different materials.
References to the orientation of grain or layup correspond to material orientation
given by geometrical or topological representation of element objects or types,
especially IfcMemberType and IfcStructuralMember.
Name
Applicable\
Structural\
Design\
Method
InPlane
InPlane\
Negative
OutOfPlane
Property Type Data Type; or
Definition
Usage Name resp.
determines whether mechanical
IfcProperty\
IfcLabel
material properties are applicable
SingleValue
to ‘ASD’ = allowable stress
design (working stress design),
‘LSD’ = limit state design, or
‘LRFD’ = load and resistance
factor design
‘Mechanical’
mechanical properties with
IfcComplex\
respect to in-plane load, i.e.
Property
bending about the strong axis;
tension zone of unbalanced
layups is stressed in tension
‘Mechanical’
IfcComplex\
respect to in-plane load, i.e.
Property
bending about the strong axis;
compression zone of unbalanced
‘Mechanical’
IfcComplex\
respect to out-of-plane load, i.e.
Property
bending about the weak axis
56
Each of the complex ‘Mechanical’ properties may consist of the following simple
properties. Any property of type IfcModulusOfElasticityMeasure or IfcPressureMeasure shall be greater than zero. α denotes the angle between strain and fiber.
Name
Young\
Modulus
Young\
Modulus\
Min
Young\
Modulus\
Perp
Young\
Modulus\
PerpMin
Shear\
Modulus
Shear\
Modulus\
Min
Bending\
Strength
Tensile\
Strength
Tensile\
Strength\
Perp
Comp\
Strength
Comp\
StrengthPerp
RaisedComp\
StrengthPerp
Property Type
IfcProperty\
SingleValue
IfcProperty\
SingleValue
Data Type
IfcModulusOf\
ElasticityMeasure
IfcModulusOf\
ElasticityMeasure
Definition
elastic modulus, mean value,
α=0°
elastic modulus, minimal value,
α=0°
IfcProperty\
SingleValue
elastic modulus, mean value,
IfcModulusOf\
IfcProperty\
SingleValue
elastic modulus, minimal value,
IfcModulusOf\
IfcProperty\
SingleValue
IfcProperty\
SingleValue
shear modulus, mean value
IfcModulusOf\
ElasticityMeasure
shear modulus, minimal value
IfcModulusOf\
ElasticityMeasure
IfcProperty\
SingleValue
IfcProperty\
SingleValue
IfcProperty\
SingleValue
IfcPressure\
Measure
IfcPressure\
Measure
IfcPressure\
Measure
bending strength
IfcProperty\
SingleValue
IfcProperty\
SingleValue
IfcProperty\
SingleValue
IfcPressure\
Measure
IfcPressure\
Measure
IfcPressure\
Measure
Shear\
Strength
Torsional\
Strength
Reference\
Depth
IfcProperty\
SingleValue
IfcProperty\
SingleValue
IfcProperty\
SingleValue
IfcPressure\
Measure
IfcPressure\
Measure
IfcPositive\
LengthMeasure
alternative value for compressive
strength, α=90°, which may be
used under material and code
dependent conditions (e.g. if
deformation is tolerable, or far
from ends of the member);
conditions should be stated in
shear strength
shear strength in torsion
depth in bending for which the
mechanical properties are valid;
provided as a means to check the
integrity of material assignment
Instability\
Factors
IfcProperty\
TableValue
57
defining values:
IfcPositiveRatio\
Measure
defined values:
IfcPositiveRatio\
Measure
defining values: slenderness
ratios;
defined values: either factors or
divisors of the strength,
depending on the design method
(if <1: factors, if >1: divisors)
Mechanical properties of wood-based panel materials
This is a collection of mechanical properties related to wood-based materials for
panel-like products like plywood or OSB. The propositions given above for woodbased beam materials with respect to anisotropy, strength graduation according to
element sizes (especially panel thickness) apply accordingly.
Name
Applicable\
Structural\
Design\
Method
InPlane
OutOfPlane
OutOf\
Plane\
Negative
Property Type Data Type; or
Definition
Usage Name resp.
determines whether mechanical
IfcProperty\
IfcLabel
material properties are applicable
SingleValue
to ‘ASD’ = allowable stress
design (working stress design),
‘LSD’ = limit state design, or
‘LRFD’ = load and resistance
factor design
‘Mechanical’
IfcComplex\
respect to in-plane load, i.e. for
Property
function as a membrane
‘Mechanical’
IfcComplex\
respect to out-of-plane load, i.e.
Property
for function as a plate; tension
zone of unbalanced layups is
stressed in tension
‘Mechanical’
IfcComplex\
respect to out-of-plane load i.e.
Property
for function as a plate;
compression zone of unbalanced
Each of the complex ‘Mechanical’ properties may consist of the following simple
properties. Any property of type IfcModulusOfElasticityMeasure or IfcPressureMeasure shall be greater than zero. Any property of type IfcPositivePlaneAngleMeasure shall be lower than or equal to 90°. α denotes the angle between strain and
strength axis or face grain.
Name
Young\
Modulus\
Bending
Young\
Modulus\
Tension
Young\
Modulus\
Comp
defining values:
IfcProperty\
TableValue
IfcPositivePlane\
AngleMeasure
defined values:
IfcProperty\
IfcModulusOf\
TableValue
ElasticityMeasure
IfcProperty\
IfcModulusOf\
SingleValue
ElasticityMeasure
Definition
defining values: α; defined
values: elastic modulus in
bending
values: elastic modulus in tension
elastic modulus in compression
58
Shear\
Modulus
Bending\
Strength
Comp\
Strength
Tensile\
Strength
Shear\
Strength
Bearing\
Strength
IfcProperty\
SingleValue
IfcProperty\
TableValue
IfcProperty\
TableValue
IfcProperty\
TableValue
IfcProperty\
TableValue
IfcProperty\
TableValue
IfcModulusOf\
ElasticityMeasure
defining values:
IfcPositivePlane\
AngleMeasure
defined values:
IfcPressure\
Measure
Raised\
Comp\
Strength
IfcProperty\
SingleValue
IfcPressure\
Measure
Reference\
Depth
IfcProperty\
SingleValue
IfcPositive\
LengthMeasure
Reference\
Thickness
IfcProperty\
SingleValue
IfcPositive\
LengthMeasure
shear modulus
values: bending strength
values: compressive strength
values: tensile strength
values: shear strength
values: bearing strength of bolt
holes, i.e. intrados pressure
alternative value for compressive
strength which may be used
under material and code
dependent conditions (e.g. if
deformation is tolerable, or far
from ends of the member);
conditions should be stated in
depth in bending for which the
panel thickness for which the
7.2 Cross sections
7.2.1 IfcStructuralProfileProperties36
Definition from IAI: This is a collection of structural properties applicable to all
linear structural members having a profile definition. For the structural profile
properties a further material dependent specialization is given for taking into account
specific profile properties applicable only in the context of a specific building
material. — See [2] for complete definition.
Discussion
There is a subtype IfcStructuralSteelProfileProperties that adds shear area attributes
and plastic shape factors. An additional subtype for timber profiles is not required.
The shear area of typical timber profile types (rectangular sections, circular sections,
36
defined in IfcProfilePropertyResource schema (IFC 2x2 non-platform part)
59
I sections) can be easily calculated from the profile dimensions, taking the profile
type into account.
According to local design practice, IfcStructuralProfileProperties may be used to
represent effective values instead of pure geometric values. Applications have to
maintain consistency between IfcStructuralProfileProperties and IfcMechanicalMaterialProperties or subtypes.
7.3 Mechanical elements
7.3.1 IfcStructuralMember37
Definition from IAI: The abstract entity IfcStructuralMember is the superclass of all
structural elements representing the structural behavior of building elements. A
further differentiation is made for structural curve members and structural face
members (see IfcStructuralCurveMember and IfcStructuralFaceMember). […]
Additional use definition for timber members and wood-based panels proposed
by ST-5.
Use Definition
See [2] for assignment of material and of profile properties.
Orientation of anisotropic materials
Currently only wood-based materials are covered by the anisotropic materials model
of IFC. The orientation of material may be indicated by shape representations
analogous to the use definition of IFCSHAREDBLDGELEMENTS.IfcMemberType.
Material orientation may also be determined from that of building element objects
that are assigned to structural member entities via IfcRelAssignsToProduct.
See [2] for EXPRESS specification, attribute definitions, and inheritance graph.
7.4 Loads, systems, strength verification
All data types necessary to model structural systems and loads that are typical for
timber structures are already defined in IFC 2x2 as a result of the ST-4 project [4].
These data types are mainly defined in IfcStructuralAnalysisDomain schema (IFC
2x2 non-platform part) [2].
Exceptions:
• There is no provision to store internal forces that would be required for
strength verification. When the model was developed it has been agreed
upon that there is no need for such provisions by the IFC model for the time
being.
37
defined in IfcStructuralAnalysisDomain schema (IFC 2x2 non-platform part)
60
• There is no way to describe the load carrying capacity of fasteners or
generally of connections. Strength verification of timber connections
depends heavily on the type of connection and its geometric parameters.
Hence there is no universally valid formalism for such descriptions
available for integration into the IFC model.
• The service conditions that govern the design of structural members — e.g.
humidity of surrounding air, or exposure to rain — may be difficult to
retrieve from the current architectural model items in the interoperability
layer. There might be need to enhance respective model capabilities after
extensive practical experience is gathered from use of IFC 2x Coordination
View enabled applications.
8 Appendix
61
8 Appendix
8.1 References
[1]
[2]
ISO 10303: Industrial Automation Systems and Integration – Product Data
TC184/SC4
[3]
Support Group; 2000
[4]
Christoph Hörenbaum, Peter Katranuschkov, Thomas Liebich, Matthias Weise,
et al: IAI ST-4 Released Drafts. iCSS project; 2001–2002
[5]
Universität Cottbus, Germany; 2000; ISSN 1615-3952
[6]
Standard Description Product Interface Steel Construction – Part 2: Data Model.
Deutscher Stahlbau-Verband; Düsseldorf; 2004
8.2 List of figures
fig. 3-1 Graph of added, changed, and interfaced schemas ......................................16
fig. 5-1
Extruded area solids for simple beams and panels ......................................24
fig. 5-2
Material orientation implied by IfcExtrudedAreaSolid ...............................25
fig. 5-3
Examples of ‘Fiber’ and ‘Layup’ representations .......................................25
fig. 6-1
Relationships between members and features in ST-5 β1 ...........................29
fig. 6-2
Relationships between members and features in ST-5 β3 ...........................30
fig. 6-3 Alternative relationships in ST-5 β3 (used with assemblies) ......................30
fig. 6-4
Representation of a component with bendings ............................................34
fig. 6-5 Representation of a member with cutout using CSG...................................35
fig. 6-6
Representation of a member with cutout using B-Rep ................................35
fig. 6-7
Round and oblong holes...............................................................................38
fig. 6-8
A textual signature .......................................................................................39
IAI Project ST-5
Part III
Implementation Guide
by
document rev.: 1.β2
document status: draft
14 February 2005
Acknowledgement
was carried out by the Brandenburg Technical University Cottbus, Germany, Chair
for Structural Analysis under guidance of the German Association for Wood
Research (Deutsche Gesellschaft für Holzforschung, DGfH) with funding by the
German Federal Ministry of Education and Research between July 2003 and
December 2004 under project number 0330424.
Table of Contents
3
Table of Contents
1 Abstract
5
Current status ...........................................................................................................................5
Abbreviations...........................................................................................................................6
2 General notes
7
2.1 IFC interface implementation ..........................................................................7
2.1.1
2.1.2
2.1.3
2.1.4
2.1.5
Types of IFC usage......................................................................................................7
Types of application interfaces to IFC.......................................................................10
Functional units of IFC interfaces .............................................................................12
Basic rules for writing to IFC ....................................................................................13
Performance and Usability ........................................................................................14
2.2 Basics of the IFC model.................................................................................15
2.2.1
2.2.2
The IFC model architecture .......................................................................................15
The exchange context/ project context ......................................................................18
2.3 The geometric model .....................................................................................19
2.3.1
2.3.2
2.3.3
2.3.4
2.3.5
2.3.6
2.3.7
Basic concepts ...........................................................................................................19
Extruded area solid ....................................................................................................20
Clippings and CSG ....................................................................................................21
Faceted B-rep.............................................................................................................22
Face based surface model ..........................................................................................23
Bounding box ............................................................................................................24
Mapped item..............................................................................................................24
2.4 Systems in buildings (Partial models)............................................................26
2.4.1
2.4.2
2.4.3
2.4.4
2.4.5
2.4.6
2.4.7
Spatial structure .........................................................................................................27
Shared building elements...........................................................................................27
The architectural model .............................................................................................28
Building services systems..........................................................................................28
Structural analysis models .........................................................................................28
Structural detailing model .........................................................................................29
Other systems and models .........................................................................................30
2.5 Type objects versus Occurrence objects ........................................................30
2.5.1
2.5.2
2.5.3
3 Examples
What is a Type? What is an Occurrence? ..................................................................30
Excursus on Types and Occurrences in IFC ..............................................................30
Types and Occurrences in the Structural Timber Model ...........................................31
33
3.1 A simple roof structure ..................................................................................33
3.1.1
3.1.2
3.1.3
3.1.4
3.1.5
3.1.6
3.1.7
Member objects .........................................................................................................33
Relationship objects, connections, materials .............................................................34
Relationships across different partial models ............................................................36
Placement and shapes of member occurrences..........................................................37
Shape of the post type................................................................................................39
Shape of the eaves purlin type ...................................................................................41
Shape of the ridge purlin type: CSG and features......................................................41
4
IAI Project ST-5 — Structural Timber Model — Part III: Implementation Guide
3.1.8
Shape of the rafter type: B-rep and features ..............................................................46
3.2 A roof truss ....................................................................................................49
3.3 A wall frame ..................................................................................................50
3.4 Special applications .......................................................................................51
3.4.1
3.4.2
Advanced modeling of Engineered Wood structures ................................................51
IFC use in components fabrication ............................................................................51
4 View definitions
52
4.1 Purpose and administration of View definitions............................................52
4.2 Relevant views outside of the timber construction domain ...........................52
4.2.1
4.2.2
IFC 2x Coordination View ........................................................................................52
IFC 2x2 Structural Views ..........................................................................................53
4.3 Timber Construction View (proposal) ...........................................................54
4.3.1
4.3.2
4.3.3
4.3.4
Targeted scenarios .....................................................................................................54
Supported entities and attributes................................................................................54
Supported representations..........................................................................................54
Further propositions...................................................................................................54
4.4 Timber Frame View (proposal) .....................................................................54
4.4.1
4.4.2
4.4.3
4.4.4
Supported entities and attributes................................................................................55
Supported representations..........................................................................................55
Further propositions...................................................................................................56
4.5 Product Library View/ Parts Library View (conception)...............................56
4.5.1
4.5.2
5 Appendix
Supported entities, attributes, representations ...........................................................56
57
5.1 References......................................................................................................57
5.2 List of figures .................................................................................................58
1 Abstract
5
1 Abstract
for Interoperability (IAI). Overall objectives of the Structural Timber Model are
discussed in the accompanying document “Structural Timber Model – Part I: Requirements”. Proposed IFC model extensions are defined in “Part II: Schema
Reference”.
Chapter 2 of this document provides basic guidelines for implementation of IFC and
the Structural Timber Model in CAD/CAE tools. The structure of the whole model
and sub-models is discussed, as well as how objects relate to each other and how they
are geometrically represented.
Chapter 3 explains the modeling of timber structures by means of simple examples.
Chapter 4 proposes minimal requirements on implementations of the Structural
Timber Model for selected application scenarios. These sets of requirements may
form the basis of so-called View definitions for timber construction. The Views will
limit implementation efforts and, at the same time, ensure interoperation between
heterogeneous implementations.
Current status
This document reflects implementation recommendations for model extensions
that are not yet integrated by IAI Model Support Group. Therefore all propositions
are subject to change.
The document also proposes possible IFC View definitions for timber construction. The actual development of view definitions will be the task of IAI Implementation Support Group and associated IAI workgroups.
6
Document history
rev 1.β2
14 February 2005
section 2.1.5 added;
additions to section 2.2.1;
clarification in sections 3.1.4 and 3.1.5;
minor corrections
rev 1.β1
15 November 2004
sections 2.1.4, 3.1.4 – 3.3 added;
sections 2.5, 4.4 extended;
IfcRelAssociatesProfileProperties removed
22 October 2004
geometric model, partial models, types vs. occurrences, example added
08 October 2004
minor edits
rev 1.α
08 September 2004
early draft
Abbreviations
B-rep
boundary representation, geometric model of a solid by specification
of its shell
CSG
constructive solid geometry, geometric model of a solid by Boolean
combination of primitive solids
GUID
globally unique identifier, also known as universally unique identifier
(UUID), a 128 bit number that is unique across space and time, can be
computed without involvement of a registrar
SDAI
Standard Data Access Interface, an API for product model access [2]
SPF
STEP physical file, the file format defined by [1]
STEP
Standard for the Exchange of Product Data, the ISO 10303 series of
specifications
2 General notes
7
2 General notes
2.1 IFC interface implementation
2.1.1 Types of IFC usage
Summary
IFC may be used in basically two ways: Like traditional exchange files or as a central
product model (in a file archive or on a model server). In both cases, application
programs read or write only a subset of the IFC model which must comply to an IFC
View definition if certification is desired.
Compared to traditional import/export filters, an interface to a central product model
imposes additional requirements on implementations. For example, object identities
need to be maintained and change history must be traced. When modifying the model,
data that are out of the scope of an application must be left intact. Moreover,
application specific data that are not in scope of IFC need to be coupled with the IFC
model.
Usage as exchange files
For now, the most common use of IFC is as a replacement of conventional exchange
file formats, especially geometry focused file formats such as DWG and DXF.
Typically, actor ‘A’ creates an IFC exchange file using application program ‘X’ and
sends the file to actor ‘B’, who imports the file into application program ‘Y’.
fig. 2-1
native file
Using IFC as format of exchange files
application
X
IFC
application
X
Y
native file
Y
DXF
exchange files, documents
actor
A
actor
B
The file structure of IFC exchange files is defined by ISO 10303-21 [1]. An XML
representation is also possible (see ifcXML documentation) but less relevant for use
as physical file format.
The content of an IFC file does not necessarily reflect the complete information that
has been input into ‘X’ by ‘A’ (whereas the native file format of ‘X’ covers the
complete information requirements of ‘X’). The importing application program ‘Y’ is
not required to interpret the entire information contained in an IFC file. Minimal
requirements on certified exporting and importing programs are defined by IFC View
Definitions (see chapter 3.1). When actor ‘B’ saves the imported data into a native
8
file of program ‘Y’, every information from the IFC exchange file that is not in scope
of ‘Y’ will be lost.
The use of IFC as an exchange file format befits the present communication practice
in the AEC/FM industries: Actors exchange documents. The documents reflect only
selected aspects of a project at a defined point in time.
Usage as central product model
A product model like IFC may also be used to overcome the drawbacks of document
based communication. The product model becomes a central point for storing and
retrieving project information. Documents play, at the most, a supplementary role in
communication. They are merely used for input into the model or to represent a
“snapshot” of the model.
fig. 2-2
Using IFC as central product model
IFC
model
application
X
native file
X
application
application
Y
documents
actor
A
Z
native file
Y
Z
documents
actor
actor
native file
C
B
ISO 10303-21 files can also be used as central model data archive. An IFC file is
made available to all participating actors/ applications for read access and is
successively updated by each actor/ application. (The file takes a “round trip”.) It is
also possible to break the model archive into separate IFC files for weakly coupled
partial models, e.g. building elements of different storeys, or service elements of
different service networks.
A more promising approach is the deployment of a data base server for the central
model repository. Some model server products are already available, however there
are still R&D efforts, API development, and pilot projects required before widespread
deployment of such servers can be expected.
An application programming interface (API) for access to a model repository is
standardized by the SDAI [2]. ISO 10303-23, -24, and -27 define programming
language specific bindings to SDAI for C++, C, and Java respectively. SDAI
implementations are freely or commercially available as libraries or toolboxes. At the
moment such toolboxes interoperate only with selected model server products. I.e. a
client that shall support several different model servers may need to be linked against
several different toolboxes.1
1
The SABLE project (briefly discussed in a following section) aims to unify model server access.
2 General notes
9
The content of the central model is the sum of information provided by each actor.2
Actor ‘A’ generates input using application program ‘X’. The input information can
be read by all other actors.3 Again, application programs are required to interpret only
a subset of information available in the repository, according to IFC View definitions.
Other actors contribute further input, and actor ‘A’ may read the updated model back
into his application program ‘X’.
In order to allow actor ‘A’ continue his work with the updated model — without
losing previously generated information — program ‘X’ has to store not only information that is relevant to other actors in the IFC model. It should also store every
information which is relevant only to actor ‘A’ himself. In fact, the complete information content of native ‘X’ files should be either directly stored in the model or be
somehow synchronized with the model. As illustrated by fig. 2-3, this can be
achieved by several ways and means: Custom objects can be added to IFC using
general-purpose classes provided by IFC (IfcProxy, IfcBuildingElementProxy,
IfcGroup). It is also possible to add custom attributes to standard IFC objects by
means of custom property sets (IfcPropertySet). Furthermore, IFC objects may be
associated with external documents and libraries. This may help to combine globally
available IFC data with locally required application-specific data.
fig. 2-3
Supplementing IFC with proxy objects, property sets, and associations
native object model
native file
IFC object
association
proxy object
X
IFC property set
mapping between X and IFC
custom property set
library
tion
associa
application X
document
IFC model
The organization shown in fig. 2-2 is therefore flexible enough with respect to the
model’s scope. But it is still not flexible enough with respect to the dynamic
development of the model. Usually, several actors work concurrently and develop
diverging model data. It appears sensible to maintain local model repositories which
are synchronized with a global model only at a few, appointed times during the
project’s lifecycle (fig. 2-4). The global model must be based on an open standard
like IFC. The local models may also be based on IFC (thus easing the task to
synchronize the models) or may be based on proprietary information models.
2
Strictly spoken, it is more than the sum of the contributions — it is the combination of all contributed
information.
3
Access rights may be restricted in future model server applications.
10
fig. 2-4
Distributed, concurrent engineering with separate model repositories
global
model
local
model
coor.
app.
A
local
model
project
coordinator
local
model
local
model
app.
app.
V
app.
W
actor
B
Z
app. app.
X
Y
actor
actor
C D
actor
E
F
The local models may be partial models (domain models) that are merged back into
the global model (base model) by mapping, matching, and merging (fig. 2-5, [8]).
fig. 2-5
Merging concurrently developed models
base model, mapped into
a domain model schema
modified domain model
base
model
domain model, mapped
into base model schema
matching
merging
mapping
design progress
mapping
2.1.2 Types of application interfaces to IFC
Summary
IFC interface implementations may be able to write to the IFC model, or read from
the model, or both. Full read/write capability requires further consideration.
Application programs with Write-only interface
Write-only implementations are the simplest variant. The implementer has to create a
one-way mapping from the internal object model to the IFC model. A possible
example of an application with write-only interface could be an analysis software for
nailplate trusses which exports generated truss designs into IFC.
Application programs with Read-only interface
This is a more demanding type of implementation. The complex IFC model has to be
interpreted and mapped to the internal object model of the application program.
Agreements between IFC implementers may be useful to eliminate some complexity
of the IFC model, especially agreements about a preferred way of modeling where
2 General notes
11
different ways are allowed by the IFC specification. Furthermore, view definitions
reduce some of the model’s complexity.
A model viewer is an example of applications that require only a read interface.
Another example is an interface to a machine control program for numerically controlled fabrication of building components.
fig. 2-6
Types of application interfaces to IFC
IFC
model
IFC
model
IFC
IFC
model model
IFC
model
application
application
application
application
write-only
implementation
read-only
implementation
read + write
implementation
read/write
implementation
mapping from native object model to IFC model
mapping from IFC model to native object model
Application programs with separate Read and Write interfaces
The above mentioned read and write interfaces may of course be combined. But the
different mappings used in the two interfaces will almost always result in big
differences in the IFC model before it was read and after it was written. For instance,
any unsupported classes and attributes will be lost.
An example for an application of this type is a CAD program that is able to import
and export IFC exchange files but is not meant to work directly with a central product
model. Still, it can access a central product model indirectly through a coordinating
application as shown in fig. 2-4.
Application programs with a coordinated Read/Write interface
An additional functional layer on top of the read and write interfaces (a layer that
coordinates the mappings to and from the native object model) is necessary for direct
access to a central product model. Basically, this layer has to ensure the model’s
integrity after a rewrite. It has for instance to provide backing store for unsupported
IFC objects and to maintain entity relationships between unsupported and supported
entities.
Examples for applications with such coordinated interfaces are
• CAD programs for distributed design (they receive a base design and add
further design details);
• CAE programs for distributed engineering (they receive a design and/ or
basic analysis models and add further analysis models and analysis results);
• model checkers that are used to optimize or correct a model;
• plot programs that derive documents—e.g. drawings—from the product
model (and write certain information back to the model which help to
update the drawings later after external changes to the model);
12
• an interface to a machine control program for NC fabrication of building
components (it reads building components data and may write back production status information).
2.1.3 Functional units of IFC interfaces
A read interface
As an example, a read interface for IFC files is considered. The following layer
structure may be applied:
fig. 2-7
Possible functional units of an IFC read interface
EXPRESS schema
IFC
STEP p21 file
file scanner
file parser
mapping 1
} STEP toolbox
mapping 2
application program
• The file scanner breaks an STEP p21 formatted file (SPF) into tokens.
Each record in an SPF contains a record number, an entity name, and a list
of attribute values. The scanner may also recode string tokens from SPF
encoding into a native character encoding.
• The file parser creates the objects. Each SPF record is matched to the entity
definitions of the EXPRESS specification of IFC. Direct attributes are filled
in from the record’s parameter list and are type-cast according to the specification. Inverse and derived attributes are generated.
• A 1st mapping layer (graph arrangement layer) may provide functions to
reduce complexity of the initial IFC data structure. It may for example
condense trees and other graphs of resource objects into fewer, compact
objects. Property sets and the geometric model are candidates for such
procedures. Memory management structures like index tables and reference
counters may be created to prepare for later operations on objects.
• A 2nd mapping layer translates from the IFC model to the native model
(the object model used internally by the application). This may be the most
complex part of the interface.
The first two layers are provided by STEP toolboxes. Most implementations will use
such a toolbox together with a static representation of the IFC EXPRESS definition.
Some toolboxes are able to include an EXPRESS schema dynamically.
If model server access is implemented, the file scanner and parser layers are of course
replaced by a transaction management layer. The interface may be streamlined to
fetch only relevant parts from the product model repository.
A write interface
In case of a write interface, layers similar to a read interface are required. A mapping
layer translates from the native model to the IFC model. A graph arrangement layer
2 General notes
13
may expand high-level objects into property sets and other resource object graphs and
may optimize the model globally4.
Then the objects are mapped to their SPF representation by removing inverse and
derived attributes and ordering attributes according to the EXPRESS schema. All
objects are serially numbered as records, entity references are replaced by record
numbers, strings are recoded into SPF encoding, and the SPF is written.
Again, all functionality below graph arrangement is available from STEP toolboxes.
In case of access to a model server instead of file output, the lower interface layers
are replaced by a transaction management layer. The data representation and protocol
to be used in transactions is usually hidden behind a server access API, e.g. the SDAI
and its language bindings.
Abstractions
Although some of the required functionality is provided by STEP toolboxes, much
more of IFC access functionality can be implemented in an application independent
fashion and made available as a library. This is what the SABLE project aims at. Its
proposed APIs replace functionality up to the mapping layer. These APIs will
simplify IFC access by hiding the complexity of the IFC data model through straightforward interfaces. The SABLE APIs also assist in use of model servers through
simplified and unified access to different model server products.
2.1.4 Basic rules for writing to IFC
Your IFC writing program is a modeler.
Let your users know that they create a project model, not just an electronic drawing.
Provide meaning.
Example: If the user designed a roof structure with assistance of a macro routine,
export “rafters” and “purlins” instead of just “beams”.
Do not guess.
Example: If the user did not select a material for a member, do not write arbitrary
material information.
Avoid redundancy.
Do not write data that can be derived from other project data by receiving applications. Example: if width, depth, length of a beam are available as parameters of its
geometric model, do not add extra property information about the size of the member.
Be (not too much) concerned about model size and file size.
The complex IFC model naturally results in big exchange files for big models. Try to
keep the ratio of file size versus model size low.5 However, do not try to compress
4
For example, resource objects that are not used by objects that are subclasses of IfcRoot can be
deleted (with a few exceptions). Some resource objects may be condensed as shared resources. See
“The role of resource objects” in the next section.
5
Note that XML is not suited for file-based exchange of complete building models; use SPF instead.
14
files by means of modeling decisions. Compression of files is better left to dedicated
compression utilities like Zip.
2.1.5 Performance and Usability
Performance requirements on IFC interfaces
IFC is a tool for interdisciplinary communication. Architects, engineers, and contractors need to exchange project information frequently. Costs of communication and
especially time required for communication must be minimized, including time spent
exporting, importing, and checking the data.
In order for the IFC standard in general and for IFC interfaces in particular to be able
to work as communication tool in the AEC industry—and to be accepted as such—,
IFC export/import interfaces have to be reasonably fast. If you, as a software vendor,
invested in an IFC implementation and it turns out to perform poorly, it will only be
of limited benefit to your users.
How to achieve reasonable performance
Only some very general hints can be given here, since software design, profiling and
tuning are by far out of scope of this document. The order of the following ideas does
not imply any order of preference or effectiveness. Also note that the explanations
given in section 2.1.3 did not take performance considerations into account.
As stated before, your IFC-enabled application program is a modeling program, and
your users should know that. It is therefore perfectly valid to ask users to deploy
appropriate hardware, e.g. with reasonable amounts of RAM.
Your program or toolbox should use time when it is available. I/O on mass storage
like harddisks as well as user interactive tasks provide time for housekeeping tasks
like maintenance of lookup tables or search trees. Such supplementary data structures
may accelerate various queries of the model which are necessary during insertion or
removal of objects or generally during evaluation of all kinds of entity relationships.
Question the effectiveness of an underlying OS or programming environment, e.g.
with respect to its memory management. If you use a STEP or IFC toolbox from a 3rd
party (as an application programmer, you should generally use one), demand performance optimization from the toolbox’s vendor.
Usability requirements on IFC interfaces
The statements above about performance requirements apply to usability too. Your
program’s users want to use your IFC export/import filter for communication with
business partners. The filters have to work not only quickly, but also predictably and
reliably. Your customers have to be able to use the filters without being experts in
IFC technology or in product modeling in general.
Ideally, IFC import and export work as easily as loading and saving your program’s
native files. Of course, reality of interdisciplinary information sharing is not that
simple, which is why IFC filters tend to feature a number of user-configurable
options. If you provide such options, ask yourself: Are these options necessary? Do
users understand these options? Do you present IFC import/export in a well-explained
or, better yet, self-explaining manner?
2 General notes
15
Import: Does your import filter assist users in acquiring the relevant information
from an IFC model as quickly as possible? Real-time feedback on the effect of import
options will often be desirable. That is, unlike import of traditional exchange files, an
import of a project model like IFC will almost always be an interactive task.
Export: Your program should assist users in modeling during design, not after design.
The model-quality of the created data should therefore enable exporting applications
to keep any export options to a minimum.
2.2 Basics of the IFC model
2.2.1 The IFC model architecture
Required reading
The most important documentation for IFC implementers is the IFC Model Implementation Guide [4] along with the IFC model reference [3].
Abstract classes
This document sometimes refers to entities that are defined as “abstract supertype” in
the EXPRESS definition of IFC. Such classes must not be instantiated, i.e. they
cannot appear in exchange files or model repositories. Only subtypes that are not
declared abstract may be instantiated.
Implementers may chose to create a mapping to the exact inheritance hierarchy of
IFC, or they may “short-cut” through some or all of abstract supertypes, provided that
all inherited attributes and local rules are observed.
IFC model layers
The model layers—and in fact all schema boundaries—are not important for implementations at all. That is why most toolboxes are using the “long-form distribution”
of the IFC EXPRESS schema definition. The long-form specification combines all
definitions into a single, large EXPRESS schema. The short-form EXPRESS
specification contains the individual EXPRESS schemas of IFC.
The layered IFC architecture (IFC 2x2 short-form distribution)
Interoperability
Layer
Core
Layer
Resource
Layer
Plumbing
FireProtection
Domain
Electrical
Domain
Architecture
Domain
Construction
Mgmt
Domain
Facilities
Mgmt
Domain
Shared
BldgService
Elements
Shared
Component
Elements
Shared
Bldg
Elements
Shared
Mgmt
Elements
Shared
Facilities
Elements
Control
Extension
Actor
Resource
Presentation
Appearance
Resource
specific concrete
concepts
Product Process
Kernel
non-platform part
Presentation
Dimensioning
Resource
Structural
Analysis
Domain
HVAC
Domain
IFC 2x2 platform
ISO/PAS 16739
Material
Property
Resource
Structural
Elements
Domain
DateTime
Resource
External
Reference
Resource
Geometric
Constraint
Resource
Geometric
Model
Resource
Geometry
Resource
Material
Resource
Profile
Resource
Property
Resource
Quantity
Resource
Representation
Resource
Topology
Resource
Utility
Resource
Presentation
Definition
Resource
Presentation
Organization
Resource
Presentation
Resource
Time
Series
Resource
Constraint
Resource
Approval
Resource
Measure
Resource
Cost
Resource
Structural
Load
Resource
Profile
Property
Resource
(GUID, owner history)
Building
Controls
Domain
Domain
Layer
inheritance from
IfcRoot
fig. 2-8
common concrete
concepts
common abstract
concepts
supplementary classes:
common concepts and
specific concepts
16
Only the boundary between Resource Layer and all other layers is of certain importance to implementations:
• All classes in the IFC Core Layer, Interoperability Layer, and Domain Layer
are subtypes of IfcRoot. These classes represent all kinds of products,
product definitions, processes, groups, and actors. All subtypes of IfcRoot
possess an object identity—expressed by a GUID—and are subject to owner
history tracking. (An example of owner history is shown in fig. 3-3 on page
34. For more information about GUID and owner history see [5] sections
2.1.1 and 2.1.3 and [4] chapter 5.)
• On the other hand, none of the classes in the IFC Resource Layer is subtype
of IfcRoot. None of them possesses a GUID, making it ultimately
impossible to track their identity after modifications to the model.
The role of resource objects
Resource objects include geometric objects (e.g. points, lines, B-Reps), profiles,
materials, various properties, presentation items, and some relationship objects.
Although they are defined as entities, they are considered to be mere properties of
“real” objects that are descendants of IfcRoot.
There are several consequences:
• Resource objects can be shared, i.e. referenced by multiple other objects.6
• Any resource object that is not referenced from any other object can and
should be deleted.7
• If attributes of a resource object are modified, the owner history of each
descendant-of-IfcRoot that refers to the resource object directly or through
other resource objects has to be updated, generally. The change of the
resource object means that a property of the descendant-of-IfcRoot was
changed.
• Graphs of IFC resource objects can be transformed to and from differently
structured native objects. (Examples of such graphs are property sets which
are trees of property objects, or a B-Rep which is a complex graph of
vertices, edges, and faces.) As long as the transformation is reversible, it is
not a change of a descendant-of-IfcRoot that points to the graph of resource
objects and is not to be recorded in the owner history.
6
There is a single exception with respect to sharing by descendants of IfcRoot: The global rule
IFCKERNEL.IfcPlacementNotShared forbids that any instance of IfcObjectPlacement is referenced
from more than one IfcProduct.
There are furthermore some exceptions with respect to sharing by other resource objects. Such
exceptions are enforced by the cardinality of inverse attributes. An example is the attribute
IfcMaterialLayer.ToMaterialLayerSet which enforces that a material layer belongs to exactly one
layer set.
Applications that are modifying a model have to pay special attention to proper management of shared
resources.
7
Exceptions: material properties, relationships. These are resource objects that only point to other
objects but are not referenced from other objects.
2 General notes
17
• A resource object that is shared between descendants-of-IfcRoot can be
replaced by copies that are not shared by descendants-of-IfcRoot. This is
also not a change of the descendants-of-IfcRoot that point to the copied
resource objects.
• If two descendants-of-IfcRoot reference the same resource object instance,
they do not necessarily have an identical property—just an equal property.
In other words: Do not imply a relationship between descendants-of-IfcRoot
that happen to refer to the same instance of a resource object.
If for example the shape representations of two building elements meet in one or
more points, they are not necessarily connected in these points, nor is a geometric
constraint implied. A modification of points of one building element does not imply
that points of the other building element have to be modified as well. A connection
between building elements is modeled as a relationship object directly between the
building elements objects, not between their representation resources.
On the other hand, a relationship is sometimes implied if two resource objects refer to
the same resource object. This may happen if all these objects are part of a complex
resource object. For example, if two faces of a B-Rep point to a common edge, they
are connected.
Logical part of IFC, Geometric part of IFC
Above, the IFC layer architecture and the subordinate role of resource objects were
discussed. We will now look at the same topic from a slightly different perspective. It
is possible to distinguish a “logical” and a “geometric” part of the IFC model. These
parts could also be called “semantic” part and “representation” part, respectively.
The semantic part describes the meaning of things, expressed as IFC objects. This
part also describes how things relate to each other. These relationships are almost
always separate IFC objects on their own (objectified relationships). The classes of all
of these objects reside in IFC Domain, Interoperability, or Core Layer. They use
classes from Resource Layer as helper objects.
fig. 2-9
Semantics versus representation
process
actor
relationship
product
placement
representation
product
relationship
product
placement
representation
relationship
product
placement
representation
product
logic part
(semantics)
geometric part
(representation)
The geometric part merely describes shapes and location of things. As mentioned
above, the geometric part does not reflect any relationships between things except for
relative spatial placement. Further information like whether the body of one thing
provides boundaries of another thing is provided by the logical (semantic) part of the
model. All classes of objects of the geometric (representation) part of the model
reside in the Resource Layer.
18
2.2.2 The exchange context/ project context
Each IFC file or IFC model repository contains data of one (or none) project.8 The
IfcProject establishes standard units of measurement, and representation contexts.
Units
IFC does not prescribe a fixed set of units to be used for measures. Instead, preferred
units may be defined for a project and even separately for several entities. Metric
units as well as imperial units may be used. For each measure used in a project (e.g.
lengths, volumes, forces, mass densities, thermal resistances, currency…) a respective
unit is declared as a property of the project. See IfcMeasureResource schema description in [3].
Most entities possess attributes where only an attribute value may be given. The unit
of such attribute is the unit in the project’s global unit assignment. Some entities
possess value attributes with associated unit attributes. Unit attributes override global
unit assignment. Reading applications have to be aware of such unit overrides.
Writing applications should avoid unnecessary unit overrides.
When an application re-exports an imported IFC model repository, it should keep the
original global unit assignment. Otherwise it had to recalculate all affected attribute
values which is only possible if all IFC schemas are supported by the application.
Product representations; Representation contexts
Products that occur in a model can have one, none, or multiple representations. The
concept of a representation in IFC is based on similar concepts in ISO 10303-41 and
-43. A representation in IFC may be
• a shape representation, i.e. a more or less exact model of the geometric
form of the product;
• a topology representation, i.e. a model that combines geometric
information with topologic information (relations between vertices, edges,
paths etc.) — this is especially used in IFC 2x2 for structural analysis
models;
• a styled representation, i.e. a graphic representation symbolizing not only
the form but also non-geometric information (such as function or material)
by means of human-interpretable symbols (such as colored lines and
hatching).9
A product may be described by multiple representations in order to separately
represent different aspects of the product. For example, a window may be defined by
separate representations of the window panels and of the window lining. Multiple
representations of a product may also serve to represent the same aspect of a product
8
This is enforced by the global rule IFCKERNEL.IfcSingleProjectInstance.
9
There is no direct connection between such symbols and the product properties they represent. Thus a
styled representation is predominantly used to visualize a product — whereas a shape representation is,
first of all, used to define a product.
Without styled representations, all visualizations had to be derived from the shape representations by
each application reading the model. It is now possible to write the result of the visualization back into
the model by means of a styled representation.
2 General notes
19
in different representation contexts. For example, a product may be represented in a
geometry-only 3D context and additionally in a styled 2D context.
fig. 2-10
A product with representations in different contexts (example)
IfcProject
(ABS) IfcProduct
ContextType=’Outline’
IfcBoundingBox
IfcStyledRepresentation
IfcStyledItem
IfcStyledItem
Representation contexts in a project and their optional sub-contexts may differ with
respect to
• the degree of detail provided by the geometric models used in the context
(e.g. fully detailed shape, or simplifications like bounding boxes);
• the dimensionality (3D or 2D);
• the projection type in case of a 2D representation (plan, section,
elevation…);
• the target scale of representations, especially of styled representations;
• the numeric precision of the geometric models, i.e. the diameter wherein
two points are considered identical.
Each representation context establishes a world coordinate system and the North
direction. All representation contexts within a project have to refer to the same world
coordinate system and have the xy plane in common. This is necessary because a
product (subtypes of IfcProduct) has only a single spatial placement that is valid for
all representation contexts.
2.3 The geometric model
This section discusses some of IFC’s means for geometric modeling of solid bodies
and surfaces—those which are most important for modeling of members in timber
structures—as well as two special geometric modeling items, the bounding box and
the mapped item.
Styled representations are not considered here. Topologic representation items are
only mentioned as far as they are used in solid modeling.
2.3.1 Basic concepts
A product representation (IfcProductRepresentation or IfcProductDefinitionShape)
may contain one or more representations (subtypes of IfcRepresentation). Each
representation may be a model of the whole shape of the product or it may represent
only a part of the shape. For example, a timber beam with a tenon may be represented
20
by a lowly detailed model of the overall shape, by a highly detailed model of the
overall shape, and by an additional model of the tenon’s surface. Each of the shape
representations can be addressed as a shape aspect (IfcShapeAspect), for example for
the purpose to attach product properties directly to this aspect of the shape.
Each representation contains one or more representation items. In case of models of
solid bodies, there is usually only one item that in itself is comprised of further
subordinate items.
2.3.2 Extruded area solid
An IfcExtrudedAreaSolid describes a 3D body by sweeping a profile along a straight
axis. Examples:
• A simple timber beam may be modeled by a rectangular profile (with the
parameters width and depth) that is swept along the beam’s longitudinal axis
(by the parameter length).
• An OSB panel may be modeled by a rectangular profile that represents
width and depth of the panel; the profile is swept along the length of the
panel. The panel may alternatively be modeled by a polygonal profile that
represents the panel’s outline which is swept by the amount of the panel’s
thickness.
fig. 2-11
Examples of bodies modeled as extruded area solids
a beam
a lengthwise extruded panel
extrusion direction, extrusion depth
a depthwise extruded panel
profile
The following restrictions are imposed by the EXPRESS definitions of IfcExtrudedAreaSolid and its supertype: The profile has to be an area. The profile must not be a
derived profile (a profile that is created by transformation of a basic profile). The
extrusion direction must not be in parallel with the profile’s plane.
A 4th restriction is informally given for members in timber structures (IfcMemberType), i.e. beams or wood-based panels: The extrusion direction shall be perpendicular to the profile’s plane. This ensures that the profile parameters are identical to
actual cross sections like they are listed in bills of material.
The final placement of the extruded body is influenced by the following Cartesian
transformations given by the placement objects shown in fig. 2-12 and fig. 2-13:
• 2D translation and rotation of the profile definition in its plane, given by
IfcExtrudedAreaSolid.SweptArea.Position (only in case of parameterized
profiles, not in case of arbitrarily bounded profiles);
• 3D translation and rotation of the profile definition — and at the same time
a respective rotation of the extrusion direction —, given by IfcExtrudedAreaSolid.Position;
2 General notes
21
• 3D translation and rotation of this representation and all other
representations of the product, given by IfcProduct.ObjectPlacement.
There are further IFC classes that allow for sweeping along a curve or for alternating
profiles along the axis or curve.
fig. 2-12
Object graph of a product represented as extruded area solid
(ABS) IfcProduct
IfcProject
IfcProfileDef
ProfileType=AREA
ProfileName=...
Depth=...
IfcDirection
IfcAxis2Placement3D
IfcCartesianPoint
IfcDirection
IfcDirection
fig. 2-13
Object graphs of profile definitions (examples)
IfcIShapeProfileDef
XDim=...
YDim=...
OverallWidth=...
OverallDepth=...
WebThickness=...
FlangeThickness=...
FilletRadius=...
IfcPolyline (or other IfcCurve),
curve must be closed
IfcAxis2Placement2D
IfcAxis2Placement2D
IfcCartesianPoint
IfcDirection
IfcCartesianPoint
IfcDirection
IfcCartesianPoint
IfcCartesianPoint
IfcCartesianPoint
IfcCartesianPoint
2.3.3 Clippings and CSG
As stated above, extruded area solids shall only be orthogonally extruded when used
to model timber members. This allows for beams with square ends only. A beam with
mitered ends may be modeled by clipping (IfcBooleanClippingResult). Another
example for the use of clippings is a gable wall. The gable wall may be modeled as an
extruded area solid where the footprint = the profile is extruded along the height of
the wall. The parts of the extruded area solid that extend into the roof are then
removed by clipping.
A clipping result can again be clipped by another surface. Other types of surfaces
than IfcPlane can be used for complex clipped shapes.
As an extension of the concept of clipping — which is the subtraction of a halfspace
from a solid — IFC supports also subtractions of another solid from a solid, the union
of two solids, or intersection of two solids. This is achieved by IfcBooleanResult (the
superclass of IfcBooleanClippingResult). Possible operands for a Boolean result are
all solid models (currently supported by IFC: B-rep, swept area solid, swept disk
22
solid, and IfcCsgSolid10), half space solids, and IfcBooleanResult. Note that most IFC
implementations currently do not support full CSG, but many support clipping.
fig. 2-14
Object graph of a product represented as clipping
IfcProject
(ABS) IfcProduct
RepresentationType=’Clipping’
(ABS) IfcSweptAreaSolid or
Operator=DIFFERENCE
IfcHalfSpaceSolid
(ABS) IfcSurface - e.g. IfcPlane
IfcAxis2Placement3D
IfcCartesianPoint
IfcDirection
IfcDirection
See also [4] section 3.5.1.4.3.
2.3.4 Faceted B-rep
A B-rep represents a body by its surfaces. IFC currently supports only faceted B-reps,
that is, bodies with planar surfaces (and consequently only with straight edges). If
exact modeling of curved edges and surfaces is desired, extruded area solids or CSG
should be used. There are two types of B-Reps in IFC: without and with voids11.
A faceted B-rep is hierarchically structured. At the lowest level, vertices are given
with Cartesian coordinates.12 Above that, only topologic information is provided:
which edge loops connect which vertices, and which faces are bound by which edges.
The set of faces is the shell that bounds the body.
The Cartesian coordinates relate to the IfcObjectPlacement of the product.
Two edges that meet in one vertex should reference the same instance of IfcCartesianPoint.13 Different to the IfcPolyline shown in fig. 2-13, the IfcPolyLoop
references all its vertex points only once. The first point is implicitly also the last
point of the edge loop. Note that each face is oriented. Its surface normal points to the
outside of the body. The orientation of the face normal depends on the order of
vertices in the edge loop that bounds the face: If the face is looked upon from the
outside of the body, the outer edge loop runs counter-clockwise around the face.
10
IfcCsgSolid is simply a container of one IfcBooleanResult.
11
voids which are unconnected to the space surrounding the body (less relevant for timber structures)
12
By informal definition of IAI, IfcPolyLoop is currently the only type of loops allowed for face
bounds. All vertices in an IfcPolyLoop are of the type IfcCartesianPoint.
13
This is not a strict requirement. Each edge could also reference its own copies of Cartesian points,
but this is not encouraged.
2 General notes
fig. 2-15
23
Object graph of a B-rep of a product (example: a tetrahedron)
(ABS) IfcProduct
IfcProject
Precision=...
1
IfcFacetedBrep
c
2
a
IfcClosedShell
IfcFace
a
b
I
4
3
b
IfcFace
II
d
c
IfcFace
III
IfcCartesianPoint
IfcCartesianPoint
d
IV
1
1-2-3(-1)
1-3-4(-1)
1-4-2(-1)
2-4-3(-2)
IfcFaceOuterBound
IfcPolyLoop
2
IfcCartesianPoint
IfcFace
IfcFaceOuterBound I:
IfcFaceOuterBound II:
IfcFaceOuterBound III:
IfcFaceOuterBound IV:
3
IfcCartesianPoint
4
A face can have more than one bound: one outer bound, and further bounds for holes
in the face. At most one of the bounds of a face shall be an instance of IfcFaceOuterBound, the other instances shall be of the type IfcFaceBound.
A sending application has to ensure that no bound crosses itself or other bounds, that
no bound touches another bound of the same face, that all bounds are correctly
ordered, and that all vertices of a face are located within the same plane. Whether a
point coincides with a plane, line, or other point is influenced by IfcGeometricRepresentationContext.Precision. See also [4] section 3.5.1.4, and [3].
2.3.5 Face based surface model
Two types of surface models exist in IFC: IfcShellBasedSurfaceModel and
IfcFaceBasedSurfaceModel. See [4] section 3.5.1.3 for more information.
Each face based surface model consists of one or more sets of connected faces. The
faces have to be planar and bounded by IfcPolyLoop, just like a B-rep. Different to a
B-rep, each set of faces may be either one of IfcOpenShell or IfcClosedShell.14
A surface model with an open shell is sometimes also called “open B-rep”. Again, the
order of points in a face’s bounding loop governs the direction of the surface normal.
All vertex coordinates used in the face bounds are given in a local coordinate system
that is established by the IfcObjectPlacement of the respective product.
Open surface models are used in IFC e.g. as the shape of a construction site (so-called
facetation representation of IfcSite) or as surface partitions of building elements
(surfaces of sawn or milled features of timber members; painted or otherwise treated
surfaces of elements).
14
Alternatively, IfcFaceBasedSurfaceModel allows the supertype of open and closed shells
(IfcConnectedFaceSet) to be used as a face set. Unlike its subtypes, IfcConnectedFaceSet does not
enforce the various topological requirements on open and closed shells.
24
fig. 2-16
Example of a product represented as surface model
(ABS) IfcProduct
IfcProject
Precision=...
1
2
a
b
RepresentationType=
’SurfaceModel’
IfcOpenShell
4
I
IfcCartesianPoint
IfcCartesianPoint
b
II
1
IfcFace
IfcFaceOuterBound
IfcPolyLoop
2
IfcCartesianPoint
IfcFaceOuterBound I: 1-2-3(-1)
IfcFaceOuterBound II: 1-3-4(-1)
IfcFace
a
3
3
IfcCartesianPoint
4
2.3.6 Bounding box
A bounding box can be provided in addition to, or instead of, a more detailed
geometric model. The orthogonal box is given by a Cartesian corner point and three
edge lengths; see fig. 2-17. Its coordinates refer to the IfcObjectPlacement of the
respective product.
fig. 2-17
Object graph of a product represented as bounding box
IfcProject
(ABS) IfcProduct
RepresentationType=
’BoundingBox’
IfcBoundingBox
IfcCartesianPoint
XDim=... YDim=... ZDim=...
2.3.7 Mapped item
Representation sharing by mapping
A mapped representation does not contain any geometric or topologic information. It
only refers to another geometric or topologic representation, the so-called mapping
source or representation map. This way, many instances of IfcProduct can explicitly
share identical representation data.
The representation map is usually attached to a type object, i.e. an instance of a
subclass of IfcTypeProduct. It is at the same time the defining type of all IfcProduct
occurrences that use the representation map.15
15
It is also possible to instantiate representation maps without an enclosing IfcTypeProduct, though
this is deprecated in the structural timber domain.
2 General notes
fig. 2-18
25
Multiply mapped representation
IfcRelDefinesByType
(ABS) IfcProduct
(ABS) IfcProduct
(ABS) IfcProduct
IfcMappedItem
IfcMappedItem
IfcMappedItem
fig. 2-19
Example of a product and its type, using mapped representation
IfcRelDefinesByType
IfcProject
(ABS) IfcProduct
RepresentationType=
IfcMappedItem
IfcCartesianTransformationOperator
mapping target
mapping origin
IfcAxis2Placement
IfcCartesianPoint
Scale=...
IfcCartesianPoint
IfcDirection
IfcDirection
+ further attributes for 3D mapping
targets and non-uniform scaling
IfcDirection + another direction for 3D mapping origins
representation to be mapped
Mapping transformation
The representation map contains not only representation items but also an
IfcAxis2Placement (2D or 3D; a Cartesian point relative to the representation items,
and optional directions) which is the mapping origin to be used in the mapping
transformation. — The mapped item contains the reference to the source and a
Cartesian transformation operator, the mapping target. The shape representation
undergoes affine transformations when mapped from origin to target.
The transformation operator provides attributes for all kinds of affine transformations:
translation, rotation, reflection, shear, uniform scale, and non-uniform scale. Transformation parameters derived from the transformation operator and the transformation origin are: a local origin vector A, a scale matrix S, and a rotation and shear
matrix T.16 Points P are transformed by the operator as such: P* = S T P + A.
16
While computation of T is well documented in [3], computation of S or how to non-uniformly scale
curves and surfaces are not. S is obviously a diagonal matrix populated with the attributes Scl, Scl2,
Scl3 of the transformation operator. In case of uniform scaling, S is only a scalar factor (attribute Scl).
26
All in all, the representation items in the mapping source are subject to the following
transformations, in that order:
• affine transformation as described above,
• translation and rotation given by the IfcObjectPlacement of the product
whose representation contains the mapped item.
The simplest transformation occurs if both the origin in the representation map and
the Cartesian transformation operator refer to the same point and omit the optional
direction and scale attributes (no translation and rotation other than that given by
IfcProduct.ObjectPlacement, no mirroring, no shear, no scaling).
fig. 2-20
The simplest case of Cartesian transformation: Identity transformation
RepresentationType=
IfcMappedItem
mapping target Scale=$
IfcAxis2Placement3D
mapping origin
IfcCartesianPoint
Note: In the proposed View definitions for the timber construction domain,
mapped representations will only use identity transformation.
See also [4] sections 3.5.2, 4.4, and 12.1.1, and the documentation of IfcGeometryResource schema [3] for more information about mapped representation.
Roles of type objects (subtypes of IfcTypeProduct) and occurrence objects (subtypes
of IfcProduct) within the structural timber domain are discussed in the following
section 2.5.3 of this document.
2.4 Systems in buildings (Partial models)
An IFC model may contain more or less complete and diverse aspects of a construction project. Depending on the type of project, the following sub-models can be
identified. Not all of these partial models are always clearly distinguishable from each
other. Partial models reflect various systems in buildings, such as the load-carrying
structures or heating systems.
Between sub-models, relationships are established by relationship objects (subtypes
of IfcRelationship). One of the advantages of these relationship objects — compared
to direct relationship attributes — is the possibility to easily take partial models out of
the whole model, e.g. for the purpose of local editing of the partial model concurrently to other partial models. Only the relationship objects that comprise the interfaces between partial models need to be adapted to removed or added model parts.
2 General notes
27
2.4.1 Spatial structure
The spatial structure of buildings is modeled by the following entities:
main entities
IfcSite
IfcBuilding
IfcBuildingStorey
IfcSpace
IfcZone
internal relationships
hierarchical decomposition:
IfcRelAggregates
external relationships
containment:
zoning:
IfcRelGroups
connection of a servicing system:
property sets
definition:
provision of space boundaries:
IfcRelSpaceBoundary
See [4] chapter 10 for more information about the spatial structure.
For the structural timber model, IfcSite, IfcBuilding, IfcBuildingStorey, IfcRelAggregates are the most relevant entities of the spatial structure, and IfcRelContainedInSpatialStructure is the most relevant interfacing relationship.
Note the conventions for object placement of products (spatial structure elements,
building elements, etc.):
• If product A is part of product B, or is an opening or filling of B, or covers
B, the placement of A shall be relative to the placement of B.
• If product B is contained within spatial structure element C, the placement
of B shall be relative to the placement of C.
Alternatively, products can be placed relative to intersections of grid axes. Grids
consist of instances of IfcGrid, IfcGridAxis, and accompanying resource objects.
2.4.2 Shared building elements
Among others, the following entities symbolize the “carcass” of the building, i.e. the
basic load-carrying or space-separating elements:
main entities
IfcRoof
IfcSlab
IfcWall
IfcWallStandardCase
IfcColumn
IfcBeam
material association:
IfcOpeningElement
creation of voids:
IfcRelVoidsElement
IfcStair
IfcStairFlight
IfcRamp
classification:
property sets,
materials,
material layers
element connectivity:
IfcRelConnectsPathElements
containment:
provision of space boundaries:
IfcRelSpaceBoundary
assignment to products
in different contexts
(e.g. structural):
definition:
See [4] chapter 11 on how to implement shared building elements. An example of
relationships between building elements in structural context and in “shared” context
is given in [5] section 3.8.
28
The union of spatial structure and shared building elements is also sometimes called
“coordination model”.
2.4.3 The architectural model
is a superset of the spatial structure and the shared building elements. Additional
entities are IfcDoor, IfcWindow, IfcCovering, IfcCurtainWall (all of which may also
count as shared building elements), IfcSpaceProgram, IfcVirtualElement, various
property sets, and relationship entities such as IfcRelFillsElement, IfcRelCoversBldgElements, IfcRelInteractionRequirements. They are complemented by numerous
resource entities related to usage of spaces, quantities, fire compartment and escape
routes, appearance and presentation, and so forth.
2.4.4 Building services systems
such as electrical networks, heating and ventilation are modeled by the numerous
subtypes of IfcDistributionElement, IfcDistributionElementType, etc.:
main entities
subtypes of
IfcDistributionElement(Type)
IfcDistributionPort
IfcTransportElement(Type)
IfcElementComponent(Type)
IfcRelConnectsPortToElement
IfcRelConnectsPorts
property sets
assignment of performance data:
IfcRelAssignsToControl
decomposition, grouping:
IfcRelAggregates
IfcRelNests
IfcPerformanceHistory IfcRelAssignsToGroup
containment:
provision of service
to a spatial system:
classification:
definition:
IfcRelDefinesByType
See [4] chapter 12 on implementation details of building service systems models.
2.4.5 Structural analysis models
Two basic concepts exist for the mapping of structural analysis models into IFC:
• exclusive use of entities in IfcStructuralAnalysisDomain schema and
respective resource schemas, or
• mixed use of shared building elements together with entities from the
structural analysis domain.
The former way is the way anticipated by the authors of the structural analysis
extensions of IFC and is reflected by the table below. The latter way has been
introduced as an alternative during the first implementation efforts of structural
2 General notes
29
IFC interfacing applications. This way is only applicable to very simple structures in
controlled engineering environments.
main entities
subtypes of
IfcStructural~
~Member
~Connection
~Action
~Reaction
material and profile association:
IfcRelAssociatesProfileProperties
IfcStructural~
~AnalysisModel
~LoadGroup
~ResultGroup
load application:
IfcRelConnectsStructuralAction
property sets,
materials
definition:
IfcRelConnectsStructuralMember
(e.g. shared building
elements):
provision of “service”
to a spatial system:
grouping:
See [6] for implementation details of structural analysis models.
2.4.6 Structural detailing model
Only the point of view on timber structures is discussed here. Very similar concepts
are used for modeling of steel structures and concrete structures.
Again, two subtly different modeling concepts have been proposed by the participants
in the IAI ST-5 project:
• extensive re-use of shared building elements entities — such as IfcBeam,
IfcColumn, IfcWall, IfcSlab, IfcCovering — in addition to entities from
structural domains, or
• exclusive use of entities from structural domains, such as IfcMember and
IfcElementAssembly.
The former way is the way anticipated by the authors of the structural IFC extensions
for concrete construction. It is reflected by the table below.
The latter way was proposed with the intention of easily distinguishable partial
models. That is, IFC import interfaces should be able to read elements of the coordinating design or of the detailing design selectively. This is for example a requirement for automated model checks (e.g. for clashes of building elements’ volumes),
quantity take-off, tracking of design changes and so on. Note however that this way
will not work for projects where no such distinction is possible or desired. Furthermore, partial models may also be distinguishable by other means, e.g. by checking for
the creator of objects.
Another motivation of using IfcMember as a replacement for IfcBeam and IfcColumn
is the fact that a CAD application is not always able to determine whether a member
object, which has been created through manipulation of a geometric shape, is actually
beam-like or plate-like.
The question whether to use IfcWall and IfcSlab or to use IfcElementAssembly arises
only when prefabricated components are designed. Walls and slabs that are assembled
on-site in traditional fashion will be modeled as IfcWall and IfcSlab.
30
main entities
single members:
IfcColumn
IfcBeam
IfcMember(Type)
assemblies:
IfcSlab
IfcWall(StandardCase)
IfcCovering(Type)
IfcElementAssembly
material association:
IfcRelConnects(WithRealizing)Elements
(IfcRelAggregates)
hierarchical decomposition:
IfcRelAggregates
accessories:
Ifc(Mechanical)Fastener(Type)
IfcDiscreteAccessory(Type)
grouping:
property sets,
materials
definition:
IfcRelDefinesByType
classification:
IfcRelAssociatesDocument
containment:
(e.g. shared building
elements):
decomposition of shared
building elements (in simple
cases of on-site assembled
structures):
IfcRelAggregates
See the following sections of this document for more information about detailing of
timber structures. An implementation guide for models of steel structures does not
exist yet. Modeling of concrete structures is explained in [5].
2.4.7 Other systems and models
are e.g. the scheduling of construction processes, fabrication and erection planning,
costs models, and the facilities management model.
2.5 Type objects versus Occurrence objects
2.5.1 What is a Type? What is an Occurrence?
Short explanations of the terms “type object” and “occurrence object” have been
given in “Part II: Schema Reference”, section 2.2.3. Here is an alternative description:
• A type is “what a thing is like”, its appearance. It is its shape, material,
weight, color and so on.
• An occurrence is “what a thing does”. A building element for example does
the following: It sits somewhere in the building, holds connections with
other elements, carries loads, bounds spaces.
2.5.2 Excursus on Types and Occurrences in IFC
The concept of type objects was added to IFC in Release 2x. It is not an original—but
now fundamental—concept of the IFC platform. One remaining limitation in IFC 2x
is that types as well as occurrences are only described at practically one point in time.
An IFC building model usually reflects the point after the building has been erected,
i.e. put into place, maybe put into service. The Structural Timber Model loosens this
2 General notes
31
limitation somewhat. It allows for different shapes from different points in time at
least in type objects (shapes before and after processing).
Type classes (subtypes of IfcTypeProduct) are defined by IFC as counterparts to
nearly all occurrence classes of products (subtypes of IfcProduct). Information about
a product may thus be split into information provided by the occurrence and
information provided by the type. Sometimes occurrences hold much information that
could go into a type; sometimes types are used differently from the principle stated in
section 2.5.1. (A type may for example express the function of a thing.) Moreover,
the IFC 2x Coordination View (the current implementation and certification rules for
exchange of spatial structure and shared building elements) does not even use type
objects at all. Likewise, the IfcStructuralAnalysisDomain schema of IFC 2x2 does not
use the concept of types.
The first domain to put type objects into extensive use was the building services
domain. This domain even provides by far more specialized type entities than
occurrence entities. For explanation on how types and occurrences are used in
building services models, see [4] chapter 12. In the concrete construction domain,
type objects are assigned a supplementary role only. For example, decomposition of
building element shapes by means of feature elements is solved by means of occurrence objects [3], [5]. Such shape features are therefore able to “do something”—
unlike shape features of timber elements which merely are parts of a type.
2.5.3 Types and Occurrences in the Structural Timber Model
The structural timber model uses type objects extensively and systematically. The
following simple rules apply:
• All built-up products (aggregated products) such as wall assemblies or
trusses use only occurrence objects.
• All one-piece products such as timber beams, OSB panels, metal
components and fasteners use type objects + occurrence objects.
• The roles of types and occurrences are given in fig. 2-21.
In short: A type object provides full information about a product’s configuration,
especially shape and material. An occurrence object provides information about
placement of a product in a building and all other location-dependent information like
connectivity. Only occurrence objects engage in relationships to objects of other
partial models.
Some further rules are proposed with respect to those occurrence objects which are
listed in fig. 2-21 (occurrences of one-piece products):
• Definition by a respective type object is mandatory.
• The only supported type of shape representation is mapped representation.
The Cartesian transformation operator of IfcMappedItem shall resolve to
identity transformation.
• If a type object carries several representation maps for different shape
aspects, it often suffices to map only a ‘body’ representation to the shape
representation of each occurrence object. Implementations in the structural
timber domain should imply the applicability of other shape aspects in a
type to its occurrences due to their definition relationship.
32
fig. 2-21
Roles of Types and Occurrences in the Structural Timber Model
entities
tasks
types
full configuration, especially
IfcMemberType
IfcFastenerType
IfcDiscreteAccessoryType
• full shape and other geometric aspects
through attached IfcRepresentationMap instances
• material association
through IfcRelAssociatesMaterial
• manufacturing position identifier (position number)
through Tag attribute
• type designation
through ElementType or PredefinedType attribute
• type classification
through IfcRelAssociatesClassification
• attachment of property sets which are shared by all
occurrences, e.g. weight per piece, quality requirements,
through HasPropertySets attribute
occurrences
IfcMember
IfcBeam
IfcColumn
location and connectivity, especially
• location
through ObjectPlacement attribute
• physical connectivity
through IfcRelConnects(WithRealizing)Elements
IfcFastener
• logical connectivity, decomposition
through IfcRelAggregates
IfcDiscreteAccessory
• grouping
through IfcRelAssignsToGroup
• location-dependent classification
through IfcRelAssociatesClassification
• attachment of property sets which are not shared by all
occurrences (i.e. location-dependent properties like
service conditions) through IfcRelDefinesByProperties
external relationships to other partial models, especially
• containment
through IfcRelContainedInSpatialStructure
• assignment to products in different contexts (e.g. shared
building elements) through IfcRelAssignsToProduct
• assignment to processes, actors, controls
through IfcRelAssignsToProcess, ~Actor, ~Control
3 Examples
33
3 Examples
3.1 A simple roof structure
3.1.1 Member objects
The following example shows the main members of a symmetric gable roof. The
structure consists of 30 rafters, 2 eaves purlins (mud sills), 1 ridge purlin, and 1 post.
The eaves purlins are made of 3 beams each, the ridge purlin of 2 beams. The ridge
purlin P1 rests on the post C1.
fig. 3-1
Example of a roof: Plan and section
P2 120x120
P2
R1 80x200
800 o.c.
P1 120x240
hinge
P2
C1
C1 120x120
P2 120x120
R1
P2
All of these members could be instantiated as IfcMember + IfcMemberType, however
we chose the more meaningful IfcBeam/ IfcColumn + IfcMemberType. There will be
in total 30 + 6 + 2 = 38 instances of IfcBeam, and 1 instance of IfcColumn. These
objects contain the exact placement of each member.
The shapes and materials of the members will be modeled by instances of IfcMemberType which will be attached to the respective IfcBeam and IfcColumn objects through
IfcRelDefinesByType. There will be 1 instance of IfcMemberType with PredefinedType = RAFTER (because all rafters have the same shape and material), 3 instances
of IfcMemberType with PredefinedType = PURLIN (1 for the smaller eaves purlins,
2 for the two different pieces of the ridge purlin), and 1 instance of IfcMemberType
with PredefinedType = POST. The 5 type objects require 5 instances of IfcRelDefinesByType.
34
fig. 3-2
Member occurrences and types in the model of a roof17
IfcBeam
IfcBeam
IfcLocalPlcmt.
IfcBeam
IfcBeam
IfcLocalPlacement
IfcLocalPlcmt.
IfcLocalPlcmt.
IfcBeam
IfcLocalPlcmt.
...30 IfcBeam
in total
IfcBeam
IfcRelDefinesByType
IfcLocalPlacement
IfcBeam
IfcMemberType
IfcLocalPlacement
Tag=’P1a’
...6 IfcBeam in total
...
...
IfcBeam
IfcColumn
IfcLocalPlcmt.
IfcLocalPlcmt.
IfcRelDefinesByType
IfcRelDefinesByType
IfcRelDefinesByType
IfcRelDefinesByType
IfcMemberType
IfcMemberType
IfcMemberType
IfcMemberType
PredefinedType=RAFTER
Tag=’R1’
Tag=’P1b’
Tag=’P2’
PredefinedType=POST
Tag=’C1’
Note that all objects in the figure above — except IfcLocalPlacement — possess
GlobalID and OwnerHistory attributes. GlobalID resolve to unique string-encoded
numbers, while OwnerHistory point to instances of IfcOwnerHistory objects. If all
objects were created or modified at the same time, they should all refer to the same
IfcOwnerHistory.
fig. 3-3
Owner history18
IfcOwnerHistory
CreationDate=1098352702
IfcApplication
IfcOrganization
IfcPersonAndOrganization
IfcOrganization
IfcPerson
IfcBeam
IfcLocalPlacement
IfcBeam
IfcLocalPlacement
IfcRelDefinesByType
IfcMemberType
3.1.2 Relationship objects, connections, materials
The entity IfcRelDefinesByType has already been introduced as a relationship object
that relates occurrences to types. Relationship objects are also used for attachment of
materials and other properties as well as for connection relationships.
Connections
Basic information about connections may be provided by IfcRelConnectsElements.
Each instance of this class connects exactly two member objects. There could be
• 1 connection between ridge purlin and post,
• 1 connection between the two parts of the ridge purlin (a Gerber hinge),
• 2 connections between each rafter and purlins, i.e. 60 connections.
17
18
Alternatively, IfcMember could be used instead of IfcBeam and IfcColumn.
Only mandatory attributes of IfcOwnerHistory concerning the creation of objects are shown. Additional optional attributes of IfcOwnerHistory are to be set after modifications of objects.
3 Examples
35
If the model contained objects for fasteners, the entity IfcRelConnectsWithRealizingElements would be used instead of IfcRelConnectsElements. This entity points to
elements that are required in the physical connection, like IfcFastener. Occurrences
of fasteners are defined by type objects like IfcMechanicalFastenerType, again via
IfcRelDefinesByType.
fig. 3-4
Connection relationships (optional)19
IfcBeam P1b
IfcBeam R1
IfcBeam R1
IfcBeam P1a
IfcFastener
IfcRelCon.El.
IfcRelDefinesByType
IfcBeam P2
IfcBeam P2
IfcColumn C1
The structure presented here hardly justifies to model the connections. Modeling of
member connectivity may be useful especially in one of the following situations:
• An analysis model is to be created from an existing structural design.
• Connections have to be prefabricated.
Materials association
Another required relationship is IfcRelAssociatesMaterial. All members will be made
of the same material, so we need one instance of IfcMaterial and IfcRelAssociatesMaterial each. The association relationship points to the IfcMemberType instances.20
fig. 3-5
Materials association
IfcMaterial
IfcExtendedMaterialProperties
Name=’quality’
Name=’Species’
NominalValue=IfcLabel(’spruce’)
Name=’StrengthGrade’
NominalValue=IfcLabel(’S 10’)
either
Name=’timber’
material specification
by properties
IfcMaterialClassificationRelationship
IfcClassificationReference
ItemReference=
’BTK=03.VHKASR;HZA=FI;SKL=10’
IfcClassification
Source=’DGfH’
Name=’BTK’ Edition=’1.0’
or
IfcMemberType
Tag=’R1’
IfcMemberType
Tag=’P1a’
IfcMemberType
Tag=’P1b’
IfcMemberType
Tag=’P2’
IfcMemberType
Tag=’C1’
material specification
by classification
The figure above also shows how further properties can be attached to a material or
how a material can alternatively be classified. Note that the IFC model allows several
property sets per material, but at most one classification reference per material. Yet in
the simplest case, only IfcMaterial with its name is attached. But this is problematic
because different material designations are used dependent on practical use cases.
19
20
Only two occurrences of R1 and P2 are shown.
The material could also be associated to IfcBeam and IfcColumn. However the convention introduced in section 2.5.3 states that all products in timber structures (except assembled products) shall
carry their material information at their type object.
36
Attachment of further member properties
Finally, another relationship used throughout the IFC model is shown: Definition by
property sets. While property sets can be directly attached to a type object like
IfcMemberType as an attribute, they can also be attached to occurrence objects like
IfcBeam via the relationship IfcRelDefinesByProperties.
fig. 3-6
Indication of load carrying members by a property set
IfcPropertySet
...
Name=’LoadBearing’
NominalValue=IfcBoolean(.T.)
IfcBeam R1
IfcBeam P2
IfcColumn C1
IfcBeam R1
IfcBeam P2
IfcBeam P1a
IfcBeam R1
IfcBeam P2
IfcBeam P1b
...
...
Name=’Pset_MemberCommon’
In the example above, the property ‘LoadBearing’ is attached to occurrence objects
rather than to type objects for two reasons:
• Property sets attached to a type object must not be shared with another type
object. That is, 4 instances of the same property set were required for the
same effect, if attached to type objects.
• Occurrences of one and the same type could be used both as load bearing or
non-load bearing, depending on their placement in the building. It is therefore a property of occurrences, not of types.21
Note that relationship objects as well as property sets are subject to GUID identification and owner history tracking.
3.1.3 Relationships across different partial models
Containment of elements in spatial structure, Local relative placement
IfcProject
IfcRelAggregates
IfcBeam
IfcLocalPlacement
IfcRelAggregates
IfcBeam
IfcLocalPlacement
(world coordinates)
IfcLocalPlacement
IfcBeam
IfcBuilding
IfcRelAggregates
IfcLocalPlacement
IfcLocalPlacement
...
partial model: spatial structure
IfcSite
IfcColumn
IfcBuildingStorey
IfcLocalPlacement
Name=’ground floor’
IfcBuildingStorey
partial model: structural detailing
fig. 3-7
Name=’attic’
IfcLocalPlacement
If the IFC model is populated by a model of the spatial structure, elements in the
structural detailing model will refer to it through IfcRelContainedInSpatialStructure.
The containment will usually be provided by instances of IfcBuildingStorey.
21
Although in this simple example of roof members, all occurrences are load carrying.
3 Examples
37
The local placement of each element relates to the placement of its spatial container.22
In other words, the coordinates of elements refer to a local coordinate system of the
spatial structure element. See also “Local placements” in the following subsection,
and [4] section 3.2.1.
IfcBeam R1
IfcBeam R1
IfcBeam P1a
IfcBeam R1
IfcBeam R1
IfcBeam P1b
IfcBeam P2
IfcBeam P2
IfcColumn C1
IfcRoof
IfcRelAggregates
partial model:
structural detailing
partial model:
shared bldg. elements
IfcRelCont.InSpatialStr.
...
Name=’attic’
...
IfcBuildingStorey
...
Relationships between structural and architectural elements (optional)
...
spatial
structure
fig. 3-8
Name=’View’
IfcSlab
Name=’View’
IfcSlab
Name=’View’
In addition, relationships to the “shared building elements model” (architectural
model: walls, slabs, roofs and so on) may be established. The appropriate relationship
may be IfcRelAggregates for some structures. But in most cases such relationships
should be resolved through IfcRelAssignsToProduct. See also [5] sections 2.4.1 and
3.8.
Relationships between members in the detailing model and members in the structural
analysis model can be expressed by IfcRelAssignsToProduct with Name = ‘Context’.
See also [6] section 3.1.
3.1.4 Placement and shapes of member occurrences
Shape representations of occurrences
All beams and the post are given a representation of their body. As a convention, only
mapped representation with a few restrictions is used (compare section 2.3.7). The
mapped item points to the actual shape representation via a representation map.
The actual shape representations with complete geometric models of each beam and
column type are attached to member types. Since there are 39 member occurrences
but only 5 member types in our example, the mapped representation helps to avoid
many redundant geometry objects.
The mapped items in the product definition shapes are actually not important for
applications in the structural timber domain. These applications are aware of the
defining relationship between member occurrence and member type. It is expected in
the structural timber domain that the members’ shapes are provided along with type
objects. The mapped items merely help “foreign” applications to render the shapes
without need to examine the type objects.
22
An exception are members which are part of an assembly (an aggregate). The placements of parts
relate to the placement of the aggregate.
38
fig. 3-9
Product definition shape of members (optional, recommended)
IfcRelDefinesByType
IfcProject
IfcBeam, IfcColumn
IfcMemberType
IfcLocalPlacement
Rep.Type=’MappedRepresentation’
Rep.Identifier=’Body’
IfcMappedItem
IfcAxis2Placement3D
IfcCartesianPoint
Coordinates=(0,0,0)
... (geometric model)
Scale=$
It is also allowed to instantiate product objects with placement but without product
definition shape23. Thus the mapped representation shown here is purely optional, but
highly recommended for better interoperability.
Local placements of occurrences
1.) Local coordinates of members:
As explained later for the shape representations of the various member types, the
geometric models should be oriented as such:
• Local xy plane contains the cross section of the member. The local z
coordinate runs along the length of the body.
• The local z axis is centered in the body. z=0 is located at one end and z=l is
located at the other end of the body. l is the gross length. If a is the width
and b is the depth of the cross section, the volume of the body is contained
within ( –a/2 ≤ x ≤ +a/2, –b/2 ≤ y ≤ +b/2, 0 ≤ z ≤ +l ).
An example is shown in fig. 3-11.
Note: By convention for simple beam-like members, the z axis of the local member
coordinates is the members’ longitudinal axis.
2.) Global coordinates:
The global xy plane is the plan view. The global z axis points upwards.
3.) Local coordinates of the spatial structure:
Some or all of IfcSite, IfcBuilding, IfcBuildingStorey may be present in the project. If
present, the IfcSite is placed in global project coordinates.24 The local coordinates of
an IfcBuilding may be translated relative to IfcSite, if present. The local coordinates
of an IfcBuildingStorey may be translated relative to IfcBuilding.
The local xy plane of each spatial structure element is the plan view of the element.
Its local z axis points upwards. That is, local coordinates of spatial containers are
usually not rotated relative to the superordinate coordinate system.
23
or product objects without both of placement and product definition shape
24
except for aggregated sites which use local relative placement
3 Examples
39
4.) Local placements of members:
By convention, the local placements refer to the local origin of the containing
IfcSpatialStructureElement. 25 The instances of IfcLocalPlacement contain
• a reference to the placement of the spatial container, and an
IfcAxis2Placement3D with
• an IfcCartesianPoint denoting the translation from the container’s origin to
the member’s origin,
• an IfcDirection attribute (IfcAxis2Placement3D.Axis) showing the alignment
of the member’s z axis,
• an IfcDirection attribute (IfcAxis2Placement3D.RefDirection) showing the
alignment of the member’s x axis.
fig. 3-10
Local relative placements: example of common practice
IfcAxis2Placement3D.Axis
= orientation of member’s z axis
z
storey coordinates
y
relative to building, translated in z
building coordinates
relative to site, not translated
x
z
site coordinates
relative to world, not translated
“world” coordinates
y
x
y
x
z
member coordinates
relative to storey
translated in x,y,z and rotated
IfcAxis2Placement3D.RefDirection
= orientation of member’s x axis
IfcAxis2Placement3D.Location
= storey coordinates of member’s coordinate origin
building coordinates of storey’s coordinate origin
In our example, the local placements of the members look like this:
• The IfcLocalPlacement of the post (IfcColumn) consists only of a
translation.
• The IfcLocalPlacement instances of the various purlins (IfcBeam) need an
additional rotation by ±90°. The local z axes of the purlins point into the x
direction of the spatial container: IfcAxis2Placement3D.Axis = (±1., 0., 0.).
• The rafters (IfcBeam) need to be rotated by ±60°: IfcAxis2Placement3D.Axis
= (0., ±1., 0.57735).
The optional attribute IfcAxis2Placement3D.RefDirection is used for additional rotation about the member’s local z axis.
3.1.5 Shape of the post type
The body of the post is just a cuboid of the size 120mm × 120mm × 3470mm. We use
an extruded area solid as its geometric model. The extruded area solid is created from
a profile (which is at the same time the post’s cross section: 120mm squared) that is
extruded at a certain length (which is identical to the length i.e. height of the post:
3470mm). Thus, the geometric model not only allows to render an image of the post
but also to obtain the measures needed for parts lists.
25
except for aggregated structures where parts are placed relative to the whole
40
As shown in the picture below, the geometric model contains unitless measures. The
unit of each length has to be determined from the LENGTHUNIT that is associated
with the IfcProject. We chose mm in this example. But a timber design application
usually imports an existing project and should keep the present LENGTHUNIT.
Representation map of post type C1
IfcProject
IfcSIUnit
Tag=’C1’ PredefinedType=POST
IfcAxis2Placement3D
UnitType=LENGTHUNIT
Prefix=MILLI
Name=METRE
IfcUnit
IfcCartesianPoint
length
...
IfcUnit
origin for
identity mapping
(mandatory for
timber members)
ProfileType=AREA
XDim=120.
cross
sectionYDim=120.
IfcAxis2Placement2D
RefDirection=$
IfcCartesianPoint
IfcDirection
identity placement of the
profile’s position coordinates
(highly recommended)
Depth=3470.
Direc.Ratios=(0.,0.,1.)
IfcAxis2Placement3D
IfcCartesianPoint
Depth=3470
IfcUnitAssignment
IfcMemberType
IfcGeom.Rep.Context
orthogonal
extrusion
(mandatory for
timber members)
z
X
= Dim
12
0
fig. 3-11
identity placement
of the solid’s
position coordinates
(recommended)
Y
=1 Dim
20
x
y
The picture above also shows that the geometric model is contained in an IfcShapeRepresentation called ‘Body’.26 This representation is in turn contained in an
IfcRepresentationMap which can be referenced by the IfcMappedItem of the product
definition shape of the IfcColumn occurrence. There is a placement attached to the
IfcRepresentationMap which is the mapping origin. We keep the mapping as simple
as possible and leave the two directions in the mapping origin unset and its location in
the local origin (0.,0.,0.). See also section 2.3.7.
Furthermore, the IfcExtrudedAreaSolid contains various other directions and coordinates. They are used to create slanted extrusions and to rotate and translate the
model relative to its local coordinate system. Again, we keep it simple:
• The IfcAxis2Placement2D of the IfcRectangleProfileDef.Position does not
rotate or translate the profile. The profile remains in local x/y directions and
centered.
• The IfcDirection of the IfcExtrudedAreaSolid.ExtrudedDirection points into
the local z direction. Thus the extrusion is created exactly orthogonal to the
profile. This ensures that the profile is identical to the cross section.
• The IfcAxis2Placement3D of the IfcExtrudedAreaSolid.Position does not
rotate or translate the body. The body remains directed into and centered
around the local z axis.
The bottom line is a rectangular solid with the coordinates centered at the lower end
face as shown in the picture.
26
Other representations for different purposes besides the ‘Body’ representation are discussed later.
3 Examples
41
3.1.6 Shape of the eaves purlin type
In our example, the eaves purlins P2 are made of beams with cross section 120mm ×
120mm and lengths of 3780mm. This member type is geometrically modeled exactly
like the post type C1, except for IfcExtrudedAreaSolid.Depth = 3780.
Since this creates a shape that is “upwards” directed (in terms of member coordinates), the shape will be rotated into horizontal direction through the IfcLocalPlacement of each occurrence of the purlins P2 as explained before.
3.1.7 Shape of the ridge purlin type: CSG and features
The ridge purlin is divided into two parts which are connected by a hinge which is
designed as a splayed scarf joint. The external ends are beveled. The shape of P1b is
alike P1a, except for a shorter body and a complementary orientation of the scarf
feature.
fig. 3-12
Possible geometric models of ridge purlin P1a
y
minuend: rectangular IfcExtrudedAreaSolid 140x240x6830
modeling variant:
CSG
subtrahend:
z
subtrahend: IfcExtrudedAreaSolid
y
minuend: rectangular IfcExtrudedAreaSolid 140x240x6830
modeling variant:
clipping
subtrahend:
IfcHalfSpaceSolid or
IfcBoxedHalfSpace
z
subtrahend: IfcPolygonalBoundedHalfSpace
y
modeling variant:
B-rep
(±70,120,0)
(±70,80,0)
face b
(±70,120,6830)
face e
z
face f
face a (face c)
(±70,-80,320)
face g
face i
(±70,0,6830)
face h
(±70,-120,320)
face d
(±70,-120,6710)
Possible geometric models
Several alternative geometric models can be used:
• CSG: The raw member is a square IfcExtrudedAreaSolid. Two other
IfcExtrudedAreaSolids with IfcArbitraryClosedProfileDef are subtracted
from the raw shape. The resulting model is an IfcBooleanResult.
• Clipping: The raw member is a square IfcExtrudedAreaSolid. Two
IfcHalfspaceSolids are subtracted from the raw shape. The half space used
for the scarf is a polygonal bounded half space. The half space used for the
bevel may be an unbounded or a boxed half space. The resulting model is an
IfcBooleanClippingResult. Clipping is actually a special kind of CSG.
• B-rep: The resulting shape is given by faceted boundary representation
(IfcFacetedBrep). Additionally, the features may be given as surface models
42
(IfcShellBasedSurfaceModel) and the original raw member as IfcExtrudedAreaSolid.
• Sideward extrusion of an IfcArbitaryProfileDef.
Sideward extrusion will not be discussed here. B-rep will be explained in section
3.1.8. An example of bounded clipping can be seen in [4] section 11.2.1.3. We will
chose CSG here.
Note: Mandatory or preferred variants of geometric modeling will be identified in
View definitions or implementers’ agreements.
fig. 3-13
Representation map of purlin type P1a using CSG
IfcProject
IfcUnitAssignment
IfcSIUnit
UnitType=LENGTHUNIT
Prefix=MILLI
Name=METRE
IfcMemberType
IfcGeom.Rep.Context
IfcAxis2Placement3D
IfcCartesianPoint
IfcUnit
IfcBooleanResult
Seco
ndO
pera
nd
Operator=DIFFERENCE
Op
era
...
nd
IfcUnit
Firs
t
Depth=150.
IfcDirection
IfcPolyline
IfcAxis2Placement3D
IfcDirection
IfcCartesianPoint
Axis
Dir.Ratios=(1.,0,.0.)
Coordinates=(0.,0.)
IfcDirection
IfcCartesianPoint
RefDir.
IfcCartesianPoint
IfcCartesianPoint
Coord.s=(-75.,-125.,6705.)
IfcBooleanResult
Seco
ndO
pera
nd
y
x
profile
coordinates
FirstOpe
rand
Operator=DIFFERENCE
lower left corner of
coordinates of the
the voiding body
z
y
ProfileType=AREA
XDim=140.
YDim=240.
IfcAxis2Placement2D
RefDirection=$
IfcCartesianPoint
IfcDirection
IfcPolyline
Depth=6830.
IfcDirection
Depth=150.
IfcAxis2Placement3D
IfcDirection
IfcCartesianPoint
Axis
Coordinates=(0.,0.)
IfcAxis2Placement3D IfcCartesianPoint
IfcCartesianPoint
profile and extrusion coordinates are identical to
the coordinates of the IfcShapeRepresentation
IfcDirection
RefDir.
IfcCartesianPoint
IfcCartesianPoint
Coord.s=(-75.,-125.,-5.)
IfcCartesianPoint
Coordinates=(207.5,0.)
y
x
profile
coordinates
lower left corner of
the voiding body
coordinates of the
y
z
3 Examples
43
CSG model of the type object for the ridge purlin
The CSG is split into two operations—subtraction of the scarf which results in an
intermediary IfcBooleanResult, and subtraction of the bevel which results in the final
IfcBooleanResult. The following solid models appear in the shape representation:
• An IfcExtrudedAreaSolid of the raw body. The profile is a rectangle of
140mm × 240mm. It is extruded orthogonally by 6830mm. No further
translation or rotation occurs. This ensures that (a) the geometric parameters
can be directly used for lists of parts and (b) that the local z axis of the
IfcExtrudedAreaSolid is at the same time the longitudinal axis of the
member.
• An IfcExtrudedAreaSolid of the scarf. It consists of an IfcArbitraryClosedProfileDef which is orthogonally extruded. Unlike the extruded solids
discussed before, this solid has to be translated and rotated into a proper
position relative to the raw body.
• An IfcBooleanResult with the previous two solids as operands and
DIFFERENCE as operator.
• An IfcExtrudedAreaSolid of the bevel. Again, this solid is created from an
IfcArbitraryClosedProfileDef and translated and rotated locally.
• Finally, an IfcBooleanResult with the previous IfcBooleanResult and the
bevel’s solid as operands and DIFFERENCE as operator.
It is usually recommendable to size voiding solids slightly bigger than the actual
voided. This averts artifacts due to rounding errors in graphic renderings. But more
importantly, NC front-ends of woodworking machines may determine unmistakably
which faces of a voiding solid are actually intruding into the member. It also ensures
that the machine removes all voided material completely.
Here is how a machine control program may interpret the model:
• Check for a shape representation with identifier ‘Blank’. (This is explained
in section 3.1.8.) If not present, check for a shape representation with
identifier ‘Body’.
• If this representation is of type ‘SweptSolid’, take the member sizes from
the contained representation items. Saw a square beam.
• If this representation is of type ‘CSG’, transverse the Boolean tree
expression down to the first minuend (IfcBooleanResult.FirstOperand).
Take the gross member sizes from the extruded area solid within this first
minuend.
• Transverse the Boolean tree expression upwards and check all subtrahends
(IfcBooleanResult.SecondOperand).
• Mill or saw the shape features (which are expressed by the subtrahends) and
saw the end cuts (which are located according to the previously checked
first minuend).
Adding manufacturing information
It may be necessary to attach further information related to manufacturing: Should a
feature be sawn or milled? Is an especially effective NC macro preferable? Should the
machined faces be especially precise, e.g. free of splinters? Should the faces be over-
44
cut or undercut?27 Such information cannot be put into the geometric model. Instead,
fabrication-related property sets have to be added to the IfcMemberType.
The property sets that are used for this purpose are subtypes of IfcShapeAspectProperties. “Shape aspect” is another term for “shape feature”. The purlin P1a
possesses two shape features—scarf and bevel—of which each can be supplemented
by an instance of IfcShapeAspectCutoutProperties.
But before such a property set can be connected with a shape aspect, the geometric
model of the shape aspect has to be separated out into an IfcShapeRepresentation on
its own: In addition to the ‘Body’ representation, two representations called ‘Cutout’
are attached to the IfcMemberType. These representations share geometric objects
with the CSG tree of the ‘Body’ representation.28
Purlin type P1a with feature information29
IfcShapeAspect
IfcBooleanResult
Operator=DIFFERENCE
IfcBooleanResult
Operator=DIFFERENCE
IfcShapeAspect
Name=’EndCut’
(ABS) IfcProperty
(ABS) IfcProperty
...
IfcMemberType
Name=’Scarf’
EdgeRadius=0
(ABS) IfcProperty
(ABS) IfcProperty
...
fig. 3-14
The two instances of IfcRepresentationMap that point to the cutouts in the figure
above could be omitted. The occurrence object of the purlin (IfcBeam) will probably
only map the ‘Body’ representation.
Now the previously shown recipe for a machine control program has to be adapted in
the 4th step:
• Check for IfcShapeAspectCutoutProperties in IfcMemberType.HasPropertySets. Evaluate their shape aspects and non-geometric parameters. If no such
property sets are present, check the Boolean tree expression for subtrahends.
27
I.e. should the tool be driven into adjacent faces or should it leave intact faces but rounded edges?
28
Instead of sharing the geometric resources, they could also be duplicated. This would of course
result in a lot more objects but also in a simpler graph structure of the geometric model.
29
Geometric details, mapping source, and project context are omitted. Refer to the previous figure.
3 Examples
45
A final remark: Not only CAM profits from feature information. It is also valuable for
plot applications (programs that read the model and generate drawings from it) and
for engineering applications for strength verification.
A bore hole
The scarf joint shall be completed by a bolt which is accepted by a bored or milled
hole. The hole feature could be represented by cylindrical IfcExtrudedAreaSolid
which is subtracted from the member’s body just like the cutouts. There is however a
light-weight method to define cylindrical and oblong holes: Only the hole’s entry and
direction are represented. Non-geometric and geometric parameters, especially the
hole’s diameter, are attached by IfcShapeAspectHoleProperties.
fig. 3-15
Hole through the Gerber joint
entry point
y
z
direction
Multiple holes with the same diameter and direction can be described by one instance
of this property set. There are just as many entry points put into the shape representation as holes exist. A hole attached to a type object results in the following objects:
Purlin type P1a with hole feature (standard method)
IfcMemberType
IfcShapeAspect
...
...
IfcDirection
IfcBooleanResult
Diameter=13.
(ABS) IfcProperty
...
fig. 3-16
IfcCartesianPoint
It is sometimes necessary to attach features to occurrence entities like IfcBeam,
IfcElementAssembly, or IfcWall. This may happen if only some occurrences of a type
receive additional processing, e.g. on-site treatments, or if there is no type object
available (especially with IfcElementAssembly). Example with IfcBeam:
fig. 3-17
Occurrence of purlin P1a with hole feature (alternative method)
IfcBeam
IfcShapeAspect
...
RepresentationType=’MappedRepresentation’
IfcMappedItem
IfcDirection
Diameter=13.
(ABS) IfcProperty
...
IfcLocalPlacement
IfcCartesianPoint
46
3.1.8 Shape of the rafter type: B-rep and features
The rafter type possesses four shape features: a mitered end at the ridge, bird’s
mouths at the two supports on the purlins, an end cut at the fascia. Just like with the
purlins, available geometric models are CSG, (bounded) clipping, and B-rep. Only Brep is discussed here.
fig. 3-18
Raw shape and processed shape of rafter type R1
y
‘Blank’ representation: parametric
z
1...20 = vertices
y
1,2
‘Body’ representation: B-rep
face e
z
3,4
face f
rectangular IfcExtrudedAreaSolid
5,6
face b
9,10
7,8
face a (face c)
11,12
face h face i
face g
19,20
15,16
13,14
face k
face d
face j
face l
17,18
‘Body’ and ‘Blank’ representation
If a B-rep was provided alone, it would be rather difficult to extract information about
the raw shape of the member, i.e. before creation of the cutouts. A second shape representation is therefore attached to the IfcMemberType. This representation is called
‘Blank’ and contains an IfcExtrudedAreaSolid.
Object graph of ‘Body’ B-rep and ‘Blank’ extrusion of rafter R130
fig. 3-19
IfcMemberType
IfcProject
Precision=...
IfcFacetedBrep
IfcClosedShell
IfcFace
a
IfcFaceOuterBound
IfcPolyLoop
IfcFace
b
IfcPolyLoop
...
IfcCartesianPoint
2
IfcCartesianPoint
3
IfcCartesianPoint
4
IfcCartesianPoint
20
IfcCartesianPoint
...
IfcFaceOuterBound
IfcFace
1
l
...
IfcFaceOuterBound
IfcPolyLoop
30
Some objects, e.g. mapping sources, are omitted.
3 Examples
47
Why another shape representation instead of e.g. a property set with parameters of the
members’ raw size? Because a variety of receiving applications may need additional
information beyond raw size parameters:
• Applications like analysis programs require the spatial orientation of the
member’s axis and profile.
• Machine control interfaces require the location of the original unprocessed
shape relative to processing features.
• If the members were part of an automatically assembled structure, the
control program would also require information about axis and outline of
the member relative to the assembly.
• Applications that are incapable of rendering B-reps may show the simpler
extruded area solid instead.
• Automatic plotting routines, including automated dimensioning and
annotating, require information about the spatial orientation of the
unprocessed shape too.
Note that a sending application in the structural domain has to ensure that the local
coordinate systems of the ‘Blank’ and ‘Body’ match. That is, ‘Blank’ and ‘Body’ are
spatially superimposed. It is recommended that receiving applications in the structural
domain implement the following integrity checks:31
• The z coordinates of all vertices in the ‘Body’ should fulfill 0 S z S Depth.
Depth is obtained from the IfcExtrudedAreaSolid of the ‘Blank’.
• There should be at least one vertex with z ≈ 0 and at least one vertex with
z ≈ Depth.
• The x and y coordinates of all vertices in the ‘Body’ should be enclosed in
the profile of the IfcExtrudedAreaSolid of the ‘Blank’.
How precisely the vertex coordinates of the B-rep coincide with the boundaries of the
extruded area solid is governed by the Precision attribute of the IfcGeometricRepresentationContext.
Adding manufacturing information
As explained earlier, CAM applications, plot programs, CAE and other applications
usually require feature-oriented information beyond the plain geometry information
contained in the shape representation. This is again accomplished by additional shape
representations, shape aspects, and shape aspect properties.
The following figure shows how four IfcShapeAspectCutoutProperties and respective
‘Cutout’ shape aspects are added to the member type. It was chosen to represent the
cutouts as surface models and to share instances of IfcFace between them and the
‘Body’ B-rep.
It is not really necessary to insert extra IfcRepresentationMaps for the cutouts since
the occurrences of the rafter (IfcBeam) will probably map only the ‘Body’ representation.
31
Here we expect IfcExtrudedAreaSolid.Position in the ‘Blank’ representation to be an identity
placement. Compare the example of the column C1.
Rafter type R1 with feature information32
IfcMemberType
IfcShapeAspect
Name=’EndCut’
(ABS) IfcProperty
IfcOpenShell
IfcFacetedBrep
IfcShapeAspect
IfcClosedShell
IfcFace
a
IfcFace
b
IfcFace
c
IfcFace
d
IfcFace
e
IfcFace
f
IfcFace
g
IfcFace
h
IfcFace
i
IfcFace
j
IfcFace
k
IfcFace
l
EdgeRadius=-5.
(ABS) IfcProperty
IfcOpenShell
IfcShapeAspect
IfcOpenShell
IfcShapeAspect
IfcOpenShell
Some objects are omitted.
...
IfcShapeRep.tation
32
...
EdgeRadius=-5.
(ABS) IfcProperty
...
fig. 3-20
Name=’Miter’
MiterAngles=(0.5236)
(ABS) IfcProperty
...
48
3 Examples
49
3.2 A roof truss
Relevant classes
See [7] for objects and their relationships in a truss. Here is an overview:
element
truss
class
IfcElementAssembly
timber members
fasteners (nailplates, nails, dowels…)
accessories (straps, gusset plates…)
relationships within the structural
detailing model
IfcRelAggregates
IfcRelDefinesByType
relationships to spatial structure
relationships to analysis model
IfcRelAssignsToProduct (Name = ‘Context’)
Geometric model
Different to the examples in section 3.1, the member shapes are fairly simple and are
usually modeled with extruded area solids and clippings by (unbounded) half spaces.
Though sometimes the webs of a truss need two clippings at one end, i.e. up to four
clipping operations per member. Still, this seems to be more effective than B-rep.
Object placements of members and fasteners in a truss should always relate to the
placement of the truss.
33
IFC 2x2 contains an IfcMechanicalFastener which the ST-5 project proposed to delete.
50
3.3 A wall frame
Relevant classes
See [7] for objects and their relationships in a stud framed wall. Here is an overview:
element
wall
class
IfcWall34 or IfcWallStandardCase, perhaps
combined with IfcWallType
wall layers
timber members
IfcBeam, IfcColumn, IfcMember +
IfcMemberType
sheathing (wood-based panels)
(or IfcPlate + IfcPlateType)
siding, especially if site-assembled
IfcCovering + IfcCoveringType
insulating infills
fasteners (rows of nails or staples…)
accessories (braces, tie-downs…)
building services installations
see section 2.4.4
relationships within the structural
detailing model
IfcRelAggregates
IfcRelDefinesByType
relationships to spatial structure
relationships to wall objects from
architect
IfcRelAssignsToProduct (Name = ‘View’)
Geometric model
The member shapes are almost always modeled with extruded area solids, sometimes
with clippings by (unbounded) half spaces. Object placements of members and
fasteners in a wall should relate to the placement of the wall, especially if it is a
prefabricated wall assembly. In case of site-assembled structures, member objects
could be placed relative to a building storey instead.
34
Prefabricated wall assemblies may also be modeled as IfcElementAssembly if a distinction from
architectural wall objects is desired at the entity level.
35
IFC 2x2 contains an IfcMechanicalFastener which the ST-5 project proposed to delete.
3 Examples
3.4 Special applications
3.4.1 Advanced modeling of Engineered Wood structures
(to be done)
3.4.2 IFC use in components fabrication
(to be done)
51
52
4 View definitions
4.1 Purpose and administration of View
definitions
A View prescribes a subset of IFC classes, attributes, and geometric models which are
required in import/ export filters. Views are defined for specific use cases. Views ease
IFC implementation since they lower extent and complexity of the data model. But
most importantly, they constitute benchmarks for IFC conformance testing. Certificates are not granted for implementations conformant to an IFC Model release, but
for implementations conformant to an IFC View chosen by the implementer.
View definitions are developed within workgroups who are associated with the IAI
Implementation Support Group (ISG). The ISG finally distributes View specifications, serves as a forum for implementers’ feedback and implementation agreements,
and conducts conformance testing and certification.
Note: The proposals in section 4.3…4.5 serve only as a suggested starting point for
actual view definitions to be developed by or in cooperation with IAI ISG
after the ST-5 model extensions have been integrated and released by IAI.
The view proposals are not binding in any way.
4.2 Relevant views outside of the timber
construction domain
4.2.1 IFC 2x Coordination View
This IFC 2x based view is the most important view for design coordination. It is as
relevant in timber construction as in the overall AEC sector. This view is currently
fully defined and in focus of most IFC implementation activities. Numerous implementations are already available on the software market. The Coordination View
targets the following scenarios:
Basic clash detection
Business case is the spatial coordination between different disciplines. It handles the
clashes between the geometry of elements only. It provides the structure (like storeys)
and element classes (like walls, ducts, etc.). Geometry is reduced to explicit geometric representation, mainly B-rep, shell based representation and mapped items.
Voiding/ filling/ connecting relationships have to be maintained.
Functional coordination
Business case is the coordination between design disciplines which includes basic
(geometry based) clash detection and the exchange of property information.
4 View definitions
53
Advanced types of geometry are used. Also various relationships have to be maintained. A certain range of semantic (property) information is sent and understood.
4.2.2 IFC 2x2 Structural Views
These view definitions are currently being prepared by the IAI Structural workgroup.
Therefore there are no final implementations available yet. The Structural Views will
not only cover most of the requirements of general structural design (especially
structural design coordination) but also most of structural timber design. At the
moment, the following “sub-views” are planned:
Architecture to Structural system model,
i.e. the take-over of the architectural model (3D or BIM) into a 3D structural
modeling package to be used to extract the analysis model.
The import into the structural modeler is based on the Coordination View. The export
(feedback) from the structural modeler consists of an annotated architectural model
which is also based on the Coordination View.
Structural system model to Structural analysis,
i.e. sharing a single structural analysis model (as created by the structural modeler) by
many structural calculation packages (FEM or other).
The import and export contains objects from the IFC 2x2 Structural Analysis Domain
schema and associated resource schemas. The exchanged models may be qualified on
two levels: 1st, the mechanical system (profiles, materials, linear and planar structural
elements, connections, supports) and 2nd, the actions (loads, load groups, load cases,
results).
Structural system model and analysis to Member design,
i.e. the take-over of the structural system model with the analysis results for structural
member design.
The import from a structural modeler or analysis software into member design software contains grids and linear and planar structural elements with profiles and
materials. Some analysis results may also be provided.
The export from member design into a modeler or analysis software provides building
elements such as walls, beams and foundations including material, profiles, weight
and so forth, connections, eccentricities, shape features, and perhaps reinforcements.
Structural design to Structural design,
i.e. the exchange among various structural design and detailing packages, e.g. for
mixed material structures and for distributed design tasks (CAD to CAD). It is as of
yet unclear how this sub-view will relate to specialized reinforced concrete, precast
concrete, steel, or timber construction views.
54
4.3 Timber Construction View (proposal)
4.3.1 Targeted scenarios
The focused market is general timber construction, especially carpentry and, to a
degree, solid timber building systems and glulam structures. Use cases are
• incremental and distributed design of timber structures (structural
detailing) which involves horizontal information exchange,
• work preparation: information exchange from structural detailing to
production planning, placing of material orders, billing,
• fabrication: information exchange from structural detailing to numerically
controlled manufacturing.
Relevant implementations are for example:
exporting applications
importing applications
• timber CAD software
• timber CAD software
• timber CAE software for
member dimensioning
• managing software for lists of parts;
order/ warehouse/ delivery management
• viewers, plot software
• CAM interfaces, i.e. NC front-ends for
joinery machines
4.3.2 Supported entities and attributes
(to be done)
4.3.3 Supported representations
(to be done)
4.3.4 Further propositions
(to be done)
4.4 Timber Frame View (proposal)
The focused market is so-called light timber frame construction, i.e. workshop design
and fabrication of timber stud framed walls, timber framed floors and roofs, as well as
nailplate trusses. Use cases are
• work preparation: information exchange from detailed design of timber
frames to production planning, placing of material orders, billing,
• fabrication: information exchange from detailed design of timber frames to
numerically controlled manufacturing.
4 View definitions
55
Relevant implementations are for example:
exporting applications36
• timber frame
CAD software
• managing software for lists of parts;
order/ warehouse/ delivery management
• nailplate truss
CAD/CAE software
• viewers, plot software
• CAM interfaces, i.e. NC front-ends for
cutting machines, nailing bridges, and
complete fabrication lines
4.4.2 Supported entities and attributes
(to be done)
4.4.3 Supported representations
Shapes of member types
IfcExtrudedAreaSolid is supported as ‘Body’ representation. Restrictions:
• Extrusion shall be orthogonal to the profile,
• IfcExtrudedAreaSolid.Position shall be an identity placement,
• profile may be IfcRectangleProfileDef or IfcIShapeProfileDef.37
IfcBooleanClippingResult is supported as ‘Body’ representation. Restrictions:
• Up to two subsequent clippings may occur in a shape representation
(up to four clippings in case of truss members),
• subtrahends are IfcHalfSpaceSolid (unbounded half space),
• first minuend is an IfcExtrudedAreaSolid with restrictions as stated above.
Shapes and placements of member occurrences
One IfcMappedItem is supported as ‘Body’ representation. It is restricted to identity
transformation (see section 2.3.7). Object placements of members shall be relative
IfcLocalPlacements which refer to the object placement of the wall, slab, or truss
which the members aggregate.
Shapes and placements of fastener occurrences
Applications that cover design and manufacturing of rows of nails or staples shall
support the symbolic representation of nail rows as described in “Part II: Schema
Reference” section 6.4.1. One representation may contain several lines of the type
IfcPolyline. Each IfcPolyline shall contain only two points.
No particular ‘Body’ representation of nails and staples is required to be supported.
(To be done: representation of nailplates.)
36
Exporting software should also be enabled to import Timber Frame View data. This facilitates
incremental design and distributed design as additional use cases of this view.
37
only IfcRectangleProfileDef supported in trusses
56
Object placements of fasteners shall be relative IfcLocalPlacements which refer to the
object placement of the respective wall, slab, or truss.
4.4.4 Further propositions
(to be done)
4.5 Product Library View/ Parts Library View
(conception)
The focused market is the delivery of product information from suppliers to designers
and builders. Use cases are
• decision support during early design, i.e. evaluation of building systems
for feasibility and costs,
• design: extraction of building element information from libraries,
• analysis: extraction of input data like weight, thermal/ hygroscopic/
acoustic performance from libraries.
See also “Structural Timber Model – Part I: Requirements” section 3.4.4 for affected
project stages, participating actors, and information content. Relevant implementations are for example:
exporting applications
• product libraries
• early design applications
• general design applications (CAD)
• LCC, LCA, SLP applications
• thermal, acoustic, structural analysis
• detailed design:
concrete/ steel/ timber CAD
• viewers
This view is related to parts of the projects IAI XM-7: Harmonization of ISO 12006
Part 3 with IFC/ BARBi (ongoing projects) and to IAI P-7: Electronic catalogues
(proposed project).
4.5.2 Supported entities, attributes, representations
None defined yet.
5 Appendix
57
5 Appendix
5.1 References
[1]
[2]
[3]
representation and exchange – Part 21: Implementation methods: Clear text
encoding of the exchange structure. International Organization for Standardization, TC184/SC4
representation and exchange – Part 22: Implementation methods: Standard data
access interface. International Organization for Standardization, TC184/SC4
[4]
Thomas Liebich: IFC 2x Edition 2 Model Implementation Guide. IAI Modeling
Support Group; March 18, 2004
[5]
Kari Karstila, Kalle Serén: Implementation Guidelines for IFC 2x2 Concrete
Domain. Confederation of Finnish Construction Industries; February 2, 2004
[6]
Matthias Weise: IAI Project ST-4 — Implementation Guide for Structural
Analysis Domain. Technische Universität Dresden; November 4, 2003
[7]
Jeffrey Wix: ST-5 — Timber Structures. A white paper on IFC model requirements to support the design of timber frame structures. October 26, 2004
[8]
Raimar J. Scherer, Ulf Wagner: Ein Kooperationsmodell für die Kontrolle
divergierender Planungszustände — Identifikationsverfahren von Planungsdifferenzen. Technische Universität Dresden; 2002
58
5.2 List of figures
fig. 2-1
Using IFC as format of exchange files ..........................................................7
fig. 2-2
Using IFC as central product model ..............................................................8
fig. 2-3
Supplementing IFC with proxy objects, property sets, and associations.......9
fig. 2-4
Distributed, concurrent engineering with separate model repositories........10
fig. 2-5
Merging concurrently developed models.....................................................10
fig. 2-6
Types of application interfaces to IFC.........................................................11
fig. 2-7
Possible functional units of an IFC read interface .......................................12
fig. 2-8
The layered IFC architecture (IFC 2x2 short-form distribution) ................15
fig. 2-9
Semantics versus representation ..................................................................17
fig. 2-10
A product with representations in different contexts (example)................19
fig. 2-11
Examples of bodies modeled as extruded area solids................................20
fig. 2-12
Object graph of a product represented as extruded area solid ...................21
fig. 2-13
Object graphs of profile definitions (examples) ........................................21
fig. 2-14 Object graph of a product represented as clipping.....................................22
fig. 2-15
Object graph of a B-rep of a product (example: a tetrahedron).................23
fig. 2-16
Example of a product represented as surface model..................................24
fig. 2-17 Object graph of a product represented as bounding box............................24
fig. 2-18
Multiply mapped representation ................................................................25
fig. 2-19
Example of a product and its type, using mapped representation..............25
fig. 2-20 The simplest case of Cartesian transformation: Identity transformation ...26
fig. 2-21
Roles of Types and Occurrences in the Structural Timber Model.............32
fig. 3-1
Example of a roof: Plan and section ............................................................33
fig. 3-2 Member occurrences and types in the model of a roof................................34
fig. 3-3
Owner history...............................................................................................34
fig. 3-4 Connection relationships (optional).............................................................35
fig. 3-5
Materials association....................................................................................35
fig. 3-6
Indication of load carrying members by a property set ...............................36
fig. 3-7 Containment of elements in spatial structure, Local relative placement .....36
fig. 3-8
Relationships between structural and architectural elements (optional)......37
5 Appendix
59
fig. 3-9
Product definition shape of members (optional, recommended) .................38
fig. 3-10
Local relative placements: example of common practice..........................39
fig. 3-11 Representation map of post type C1 ..........................................................40
fig. 3-12
Possible geometric models of ridge purlin P1a..........................................41
fig. 3-13
Representation map of purlin type P1a using CSG ...................................42
fig. 3-14 Purlin type P1a with feature information...................................................44
fig. 3-15
Hole through the Gerber joint ....................................................................45
fig. 3-16 Purlin type P1a with hole feature (standard method).................................45
fig. 3-17 Occurrence of purlin P1a with hole feature (alternative method)..............45
fig. 3-18 Raw shape and processed shape of rafter type R1.....................................46
fig. 3-19
Object graph of ‘Body’ B-rep and ‘Blank’ extrusion of rafter R1 ............46
fig. 3-20
Rafter type R1 with feature information....................................................48

Verbundvorhaben "Innovativer Holzsystembau"

Transcription

Similar documents

Neues Seniorenwohnheim in Holzrahmenbauweise

Produktkatalog - schoen

Komei Jyuku Honbu Seishukai

der Publikation

präzision ist unser antrieb driven by precision

Links - Edition Axel Menges

Prospekt Sonderfassaden