Lektion 2.411 min Lesezeit

IFC in einem Satz

IFC beschreibt ein Datenmodell für den Austausch von Bauwerksinformationen. Wer seine Struktur kennt, kann Lieferungen gezielt prüfen. Diese Lektion zeigt, wie eine IFC-Datei von innen aussieht, was räumliche Struktur, Klassen und Property Sets leisten und warum die Version in jede Vereinbarung gehört.

KonstrukteureIngenieureBIM-KoordinatorenBIM-Manager

Lernziel

Nach dieser Lektion kannst du erklären, was IFC im Kern ist und warum es mehr ist als ein Dateiformat. Du kennst die Grundbausteine eines IFC-Modells: räumliche Struktur, Objekte, Typen und Property Sets. Du weisst, weshalb IFC-Version und Austauschzweck in jede Liefervereinbarung gehören und welche Rolle die Modellsicht dabei spielt.

Praxisproblem

Eine IFC-Datei sieht im Viewer aus wie ein 3D-Modell. Öffnest du eine übliche .ifc-Datei im Texteditor, findest du stattdessen Einträge wie diesen:

#412=IFCWALL('2O2Fr$t4X7Zf8NOew3FLKI',#41,'Wand-EG-014',$,$,#398,#405,$,.NOTDEFINED.);

Der Eintrag beschreibt eine Wand. Er enthält ihre Kennung, ihren Namen und Verweise auf weitere Einträge, etwa für Platzierung und Geometrie. Was zunächst unübersichtlich wirkt, folgt einer festgelegten Struktur.

Diese Struktur hilft dir beim Prüfen einer Lieferung. Eine Wand kann geometrisch korrekt aussehen, obwohl ihre Geschosszuordnung oder vereinbarte Eigenschaften fehlen. Um solche Lücken zu erkennen, musst du wissen, wie IFC die Informationen verknüpft.

1. Der eine Satz

IFC — Industry Foundation Classes — ist ein offenes, herstellerneutrales Datenmodell, das ein Bauwerk als Menge von Objekten mit Bedeutung, Eigenschaften und Beziehungen beschreibt.

Datenmodell: IFC legt fest, welche Objekte es gibt, welche Angaben sie tragen können und wie sie zusammenhängen. Die Datei speichert diese Informationen, meist als Textdatei mit der Endung .ifc. Daneben gibt es XML- und komprimierte Varianten. Die Dateiendung allein sagt deshalb wenig über den gelieferten Inhalt aus.

Objekte mit Bedeutung: Eine Wand wird als IfcWall, eine Decke als IfcSlab und eine Tür als IfcDoor beschrieben. Diese Zuordnung gibt dem Objekt eine Bedeutung, die unabhängig von Layer, Name oder Farbe auswertbar ist.

Eigenschaften: Angaben wie «tragend» oder «Feuerwiderstand» lassen sich in Property Sets bündeln. Weitere Informationen, etwa zur Materialzuordnung, werden über eigene Strukturen und Beziehungen abgebildet.

Beziehungen: Welche Wand in welchem Geschoss steht, welches Material sie hat, zu welchem Typ sie gehört. Diese Verknüpfungen machen aus einer Objektliste ein Modell.

buildingSMART International entwickelt und pflegt IFC. Der Standard ist als ISO 16739-1 international genormt und bildet eine gemeinsame Grundlage für den herstellerneutralen Datenaustausch.

2. Eine IFC-Datei von innen

Zurück zum Wandeintrag aus dem Praxisproblem. Drei Bestandteile helfen dir, ihn zu lesen.

Im Datenabschnitt steht jeder solche Eintrag für eine Entitätsinstanz. Seine Nummer dient als Verweisziel innerhalb der Datei; sie ist keine Zeilennummer. #412 bezeichnet hier die Wand. #41 verweist auf Herkunfts- und Änderungsangaben, #398 auf die Platzierung und #405 auf die Geometrie. Die Datei bildet ein Netz aus Verweisen.

Der erste Wert in Anführungszeichen ist die GlobalId, eine weltweit eindeutige Kennung aus 22 Zeichen. Bleibt sie für dasselbe Bauteil über Lieferungen hinweg stabil, können Prüfwerkzeuge es wiedererkennen und Änderungen zuordnen. Neue Kennungen bei jedem Export erschweren diesen Vergleich erheblich. Die Nummer #412 kann sich dagegen ändern, ohne dass die Wand ihre Identität verliert.

Am Ende des Beispiels steht der PredefinedType, hier .NOTDEFINED.. Für Wände gibt es vordefinierte Untertypen wie SOLIDWALL, PARTITIONING oder SHEAR. NOTDEFINED bedeutet, dass an dieser Stelle kein Untertyp angegeben ist. Das ist nicht automatisch ein Fehler; entscheidend sind die Anforderungen. Ist ein IfcWallType zugeordnet, wird der Untertyp dort angegeben und das Attribut an der einzelnen Wand bleibt ungesetzt.

Vor dem Datenabschnitt steht der Header. Unter FILE_SCHEMA findest du die IFC-Schemaversion; FILE_DESCRIPTION kann die verwendete Modellsicht nennen. Prüfe diese Angaben zu Beginn. Sie beschreiben, wie die Datei deklariert ist, belegen aber noch nicht, dass ihr Inhalt die Anforderungen erfüllt.

3. Die räumliche Struktur

Vereinfachtes Hochbaubeispiel. Der Untertyp steht hier am zugeordneten Wandtyp; Eigenschaften und Mengen sind mit der einzelnen Wand verknüpft.

Die räumliche Struktur ordnet die Objekte im Modell. Im Hochbau führt sie typischerweise vom Projekt über das Grundstück und das Gebäude bis zum Geschoss. Dort sind Bauteile und Räume zugeordnet. Vereinfacht sieht das so aus:

IfcProject
└── IfcSite
    └── IfcBuilding
        └── IfcBuildingStorey  (z. B. «EG»)
            ├── IfcWall
            ├── IfcSlab
            └── IfcSpace

Über diese Zuordnungen lassen sich etwa Wände oder Mengen pro Geschoss auswerten. Fehlt die Geschosszuordnung, muss der Empfänger sie anderweitig herleiten oder nachfordern. Die gezeigte Hierarchie ist allerdings keine starre Pflicht für jedes IFC-Modell: Je nach Bauwerk und Objekt sind andere räumliche Zuordnungen zulässig. Räume gehören selbst zur räumlichen Struktur; Bauteile werden dieser Struktur zugeordnet.

IFC 4.3 erweitert die Unterstützung für Infrastruktur, etwa Strassen, Bahntrassen, Brücken und Häfen. Auch dort werden Objekte räumlich gegliedert, mit Strukturen, die zum jeweiligen Bauwerk passen.

4. Objekte, Typen und Klassen

Klasse, Objekt und Typ beschreiben unterschiedliche Ebenen:

Die Klasse bezeichnet den IFC-Entitätstyp, zum Beispiel IfcWall, IfcColumn, IfcBeam. Sie sagt, was das Objekt grundsätzlich ist.

Das Objekt ist die konkrete Instanz im Modell — diese eine Wand, mit dieser GlobalId, an dieser Stelle.

Der Typ beschreibt gemeinsame Merkmale mehrerer Objekte. Ein IfcWallType kann beispielsweise die Wandart «Aussenwand Beton 25 cm» beschreiben. Mehrere Wände verweisen dann auf diesen Typ. Eigenschaften, die für alle gelten, lassen sich dort gemeinsam hinterlegen; objektspezifische Angaben bleiben an der einzelnen Wand.

Bei IfcBuildingElementProxy lohnt sich ein genauer Blick. Diese Klasse kann für Bauteile verwendet werden, für die keine passendere Klasse genutzt werden kann. Tauchen jedoch gewöhnliche Wände oder Stützen als Proxys auf, solltest du die Klassenzuordnung beim Export prüfen. Proxys können Geometrie und Eigenschaften tragen, lassen sich aber nicht ohne Weiteres als Wände oder Stützen auswerten. Ihre Anzahl allein entscheidet daher nicht über die Qualität eines Modells.

5. Eigenschaften und Mengen

Eigenschaften sind in Property Sets gruppiert. Zu den standardisierten Sets mit dem Präfix Pset_ gehört Pset_WallCommon. Es enthält unter anderem LoadBearing (tragend: ja oder nein), IsExternal (Aussenbauteil: ja oder nein) und FireRating (Angabe zum Feuerwiderstand). Die festgelegten Namen erleichtern die eindeutige Zuordnung in anderen Werkzeugen. Ob diese die Angaben tatsächlich übernehmen und auswerten, musst du beim Austausch prüfen.

Für Angaben, die der Standard nicht vorsieht, kann ein Projekt eigene Property Sets definieren. Ihre Namen, Eigenschaften und erwarteten Werte müssen vereinbart sein. Sonst entstehen für dieselbe Angabe unterschiedliche Schreibweisen, die ein Prüfwerkzeug nicht automatisch als gleichwertig erkennt.

Mengen liegen in Quantity Sets, bei standardisierten Sets mit dem Präfix Qto_. Ein Beispiel ist Qto_WallBaseQuantities mit Angaben zu Länge, Höhe, Fläche und Volumen. Solche Mengen können vom Autorenwerkzeug berechnet und mitgeliefert werden. Fehlen sie, muss der Empfänger sie gegebenenfalls aus der Geometrie ermitteln. Dabei können je nach Berechnungsregeln und Werkzeug unterschiedliche Ergebnisse entstehen.

Damit wird die Aussage aus Lektion 1.2 konkret: «Diese Wand weiss, dass sie eine Wand ist.» Ihre Klasse ist IfcWall. Über Beziehungen ist sie einem Geschoss und gegebenenfalls einem Typ zugeordnet. In Pset_WallCommon kann stehen, ob sie tragend ist. Welche dieser Informationen geliefert werden müssen, legt das Projekt fest.

6. Versionen und Modellsichten

Für den Austausch begegnen dir insbesondere diese drei Versionsfamilien:

IFC2x3 ist eine ältere Version, die weiterhin in Austauschprozessen verwendet wird. Ihr Schwerpunkt liegt im Hochbau; die späteren Erweiterungen für Infrastruktur fehlen.

IFC4 hat das Datenmodell deutlich erweitert und einige Schwächen der Vorgängerversion behoben.

IFC4.3 ist in der Fassung IFC 4.3 ADD2 als ISO 16739-1:2024 genormt und erweitert das Datenmodell insbesondere für Infrastruktur. Welche Version für ein Projekt passt, hängt vom Bauwerk, dem Austauschzweck und der Unterstützung durch die beteiligten Werkzeuge ab.

Eine Modellsicht (Model View Definition, MVD) legt fest, wie IFC für einen bestimmten Austauschzweck verwendet wird. Sie beschreibt dafür benötigte Inhalte und zulässige Darstellungen. Bei IFC4 zielt die Reference View auf die Nutzung als Referenzmodell, etwa für Koordination und Prüfung. Die Design Transfer View ist auf weiterbearbeitbare Inhalte ausgerichtet, garantiert aber keine verlustfreie Übernahme in ein anderes Autorenwerkzeug. Für IFC2x3 ist die Coordination View ein bekanntes Beispiel.

Vereinbare deshalb die IFC-Version und den Austauschzweck sowie die dafür vorgesehene Modellsicht mit ihrer genauen Bezeichnung, sofern eine eingesetzt wird. Hinzu kommen die benötigten Inhalte: Eine Modellsicht allein legt noch nicht fest, welche projektspezifischen Eigenschaften geliefert werden müssen. «Lieferung als IFC» reicht als Anforderung nicht aus.

7. Was beim Export typischerweise schiefgeht

Beim IFC-Export übersetzt das Autorenwerkzeug sein internes Datenmodell in IFC. Dabei können Zuordnungen und Informationen verloren gehen oder falsch übertragen werden:

Bauteile erscheinen als IfcBuildingElementProxy, weil ihre IFC-Klasse nicht passend zugeordnet wurde.
Property Sets fehlen oder bleiben leer, weil Angaben im Ausgangsmodell fehlen oder im Export nicht berücksichtigt werden.
Die Geschosszuordnung geht verloren, weil die Ebenenstruktur nicht passend übertragen wird.
Einheiten werden falsch deklariert oder interpretiert. Unterschiedliche Einheiten sind für sich genommen kein Fehler, solange sie korrekt angegeben und umgerechnet werden.
Eine falsche Georeferenzierung oder unterschiedliche Ursprünge führen dazu, dass Fachmodelle im Koordinationsmodell versetzt liegen.

Ein Versatz fällt in der 3D-Ansicht oft sofort auf. Fehlende Eigenschaften oder unpassende Klassen erkennst du dagegen erst, wenn du auch die Modellstruktur und die Objektinformationen prüfst. Viele Viewer bieten dafür entsprechende Ansichten; die reine Sichtkontrolle der Geometrie reicht nicht.

Deshalb gehört zu jeder Lieferung eine Prüfung gegen die vereinbarten Anforderungen. Dafür nutzt du Viewer und Prüfwerkzeuge. Anforderungen an alphanumerische Informationen lassen sich mit IDS beschreiben und automatisiert prüfen. Eine solche Prüfung ersetzt weder die geometrische noch die fachliche Beurteilung des Modells.

8. Beispiel: Zwei Exporte, dieselbe Wand

Das folgende vereinfachte Beispiel zeigt dieselbe Aussenwand im Erdgeschoss aus demselben Autorenwerkzeug. Für die Lieferung sind Geschoss- und Typzuordnung, die genannten Eigenschaften und Mengen vereinbart.

Export A, unvollständig. Die Wand kommt als IfcWall mit PredefinedType = NOTDEFINED. Sie hängt direkt am IfcBuilding, nicht am Geschoss. Pset_WallCommon ist vorhanden, aber LoadBearing und FireRating sind leer. Kein Typ, keine Mengen. In der 3D-Ansicht sieht die Wand korrekt aus.

Export B, nach Vereinbarung. Dieselbe Wand ist als IfcWall dem IfcBuildingStorey «EG» zugeordnet und verweist auf den IfcWallType «AW Beton 25». An diesem Typ steht PredefinedType = SOLIDWALL; an der einzelnen Wand bleibt das Attribut ungesetzt. Pset_WallCommon mit LoadBearing = TRUE, IsExternal = TRUE, FireRating = REI 90. Qto_WallBaseQuantities mit Länge, Fläche, Volumen. In der 3D-Ansicht sieht sie genauso aus wie in Export A.

Der Unterschied wird in der Modellstruktur und den Eigenschaften sichtbar. Export B liefert die hier vereinbarten Angaben für weitere Auswertungen. Ob Werte wie FireRating = REI 90 fachlich zutreffen, muss zusätzlich geprüft werden. Dafür müssen Ausgangsmodell, Exporteinstellungen und Softwareunterstützung zusammenpassen.

9. Typische Fehler

Nur die Dateiendung vereinbaren. Lege auch fest, welche Inhalte für welchen Zweck geliefert werden.
Version und Modellsicht ungeprüft übernehmen. Stimme die Exporteinstellungen mit den Empfängern ab.
Dem Header allein vertrauen. Seine Angaben müssen zum tatsächlichen Dateiinhalt passen.
Proxys pauschal akzeptieren oder ablehnen. Prüfe, weshalb sie verwendet wurden und ob eine passendere Klasse erforderlich ist.
Property Sets als selbstverständlich annehmen. Kontrolliere, ob die vereinbarten Angaben vorhanden und sinnvoll gefüllt sind.
GlobalIds bei jedem Export neu erzeugen. Das erschwert die Zuordnung zwischen Lieferständen.
Die 3D-Ansicht als vollständige Prüfung behandeln. Beziehe Struktur, Eigenschaften und fachliche Plausibilität ein.

10. Mini-Checkliste

Bei jeder IFC-Lieferung, bevor sie ins Koordinationsmodell geht:

Entspricht die Schemaversion im Header der Vereinbarung, und passt die deklarierte Modellsicht, sofern eine vereinbart ist?
Entspricht die räumliche Zuordnung den Projektanforderungen, etwa die Geschosszuordnung im Hochbau?
Ist die Verwendung von IfcBuildingElementProxy nachvollziehbar?
Ist der erforderliche PredefinedType am Objekt oder am zugeordneten Typ angegeben?
Sind die vereinbarten Property Sets und Eigenschaften mit passenden Werten vorhanden?
Sind die benötigten Mengen mitgeliefert?
Bleiben die GlobalIds für unveränderte Bauteile gegenüber der letzten Lieferung stabil?
Stimmen Einheiten und räumliche Lage beim Zusammenführen der Fachmodelle?

Kläre Abweichungen, bevor du die Lieferung weiterverwendest. Entscheidend ist, welche Anforderung verletzt wird und welche Folgen das für die geplante Nutzung hat. Schon eine einzelne fehlende Angabe kann eine Auswertung verhindern.

11. Reflexionsfrage

Öffne eine unkomprimierte .ifc-Datei aus deinem Projekt im Texteditor und lies den Header. Welche Schemaversion ist unter FILE_SCHEMA angegeben? Enthält FILE_DESCRIPTION eine Modellsicht, und passt sie zur Vereinbarung?

Suche anschliessend in der gesamten Datei nach IFCBUILDINGELEMENTPROXY(. Die Einträge beginnen mit einer Nummer wie #412=, nicht mit dem Klassennamen. Prüfe einen Treffer im Viewer: Welches Bauteil steckt dahinter, und ist die Zuordnung nachvollziehbar? Die Anzahl der Treffer allein ist noch kein Qualitätsurteil.

Merksätze

IFC beschreibt Objekte mit Bedeutung, Eigenschaften und Beziehungen. Die Datei speichert diese Informationen.

Die räumliche Zuordnung ermöglicht Auswertungen nach Gebäude oder Geschoss. Sie muss zum Bauwerk und zum vereinbarten Zweck passen.

Vereinbare IFC-Version, Austauschzweck, die gegebenenfalls verwendete Modellsicht und die benötigten Inhalte.

Ein geometrisch plausibles Modell kann unvollständige Informationen enthalten. Prüfe deshalb auch Struktur und Eigenschaften.

Quellen und weiterführende Literatur

buildingSMART — Industry Foundation Classes (IFC): technical.buildingsmart.org/standards/ifc
buildingSMART — Offizielle IFC 4.3.2.0 Dokumentation (ISO 16739-1:2024): standards.buildingsmart.org/IFC/RELEASE/IFC4_3
buildingSMART — Model View Definitions: technical.buildingsmart.org/standards/ifc/mvd
buildingSMART — Information Delivery Specification (IDS): buildingsmart.org/standards/bsi-standards/information-delivery-specification-ids

Die Erläuterungen zu Wandattributen, räumlicher Zuordnung, Eigenschaften und Mengen stützen sich insbesondere auf die Dokumentationsseiten zu IfcWall, IfcRelContainedInSpatialStructure, Pset_WallCommon und Qto_WallBaseQuantities.