Die Industry Foundation Classes (IFC) wurden in den 1990er Jahren von der International Alliance for Interoperability (IAI) als objektorientierte Beschreibung von Bauwerken entwickelt, die erste Version wurde 1996 veröffentlicht. Die IAI wurde in den USA von Autodesk initiiert und war in über 24 Ländern aktiv, 2005 wurde daraus die Organisation buildingSMART. Bis heute entwickelt buildingSMART International den offenen IFC-Standard weiter und verbreitet das Format frei. Das funktioniert dank offen zugänglicher Arbeitsräume und ehrenamtlicher Experten. Das Netzwerk buildingSMART ist neben dem Engagement der Experten auch auf Sponsoren angewiesen, um seine Entwicklungen und Veröffentlichungen aufrecht zu halten.

Struktur

IFC ist in einer festen und modularen Hierarchie aufgebaut. In einem Baumschema werden alle Gebäudeobjekte fest verankert. Dadurch haben sie eine feste Beziehung zueinander. Unter dem IfcRoot (Kernelement) befindet sich das IfcProject (das Projekt). Darunter steht die IfcSite (die Liegenschaft). Erst darunter findet sich das IfcBuilding (das Bauwerk bzw. Gebäude). Unter dem Bauwerk befinden sich dann Geschosse (IfcBuildingStorey), Räume (IfcSpace) darunter alle anderen Bauteile.

Dieses Baumprinzip ist in der Informatik weit verbreitet und viele Formate und Strukturen sind so aufgebaut. Alle IFC-Entitäten sind an dem Präfix »Ifc« erkennbar. Im IFC4 gibt es rund 800 solcher Entitäten. Das erscheint auf den ersten Blick viel, betrachtet man allerdings ein Gebäude mit all seinen Bauteilen, relativiert sich der Eindruck schnell. Neben nativen Entitäten kann IFC technisch auch weitere eigene Objekte (IfcProduct) enthalten. Allerdings ist es fraglich, ob diese Objekte auch interpretiert und verstanden werden.

Properties

Alle Objekte verfügen neben ihrer strukturellen Anordnung über beschreibende Merkmale, z. B. eine Anschlussleistung einer Leuchte. Merkmale im IFC haben das Präfix »Pset«. Im IFC4 gibt es rund 2.500 native Merkmale (Property sets). Auch diese Menge ist nicht ausreichend, um alles zu beschreiben, was ein Bauwerk ausmacht. Hier kommen freie Merkmale zum Einsatz. Im IFC können zusätzlich einfache Merkmale (IfcSimpleProperty), Listen (IfcPropertyListValue), Tabellen (IfcPropertyTableValue) oder komplexe Merkmalssätze (IfcComplexProperty) abgelegt werden.

Die Optionen sind vielfältig, problematisch ist die Verständigung zwischen Merkmalserzeuger und -nutzer. IFC ist in der Lage, Merkmale mit einer GUID (einer globalen eindeutigen ID, Kurzform der UUID) und einem Quellbezug von Merkmalsservern zu nutzen. Das buildingSMART Data Dictionary (bSDD) ist eine Option für einen solchen Merkmalsserver. Im bSDD liegen Millionen von Merkmalen und Objekten. Leider in keinem gut gepflegten und fachlich korrekten Zustand. Aber die schiere Anzahl zeigt, dass eine Merkmalspflege nativ im IFC quasi unmöglich und eine Auslagerung durchaus sinnvoll ist. Durch die GUID und Bezüge zum Quellsystem ist das technisch kein Problem. Lediglich die fachliche und redaktionelle Pflege des bSDD und weitere gute Merkmalsserver fehlen heute noch, z. B. die rund 350 Leuchtenmerkmale nach CEN/TS 17623.

Geometrie

IFC kann von Anfang an umfangreiche Geometrien beinhalten. Der Ursprung liegt im konstruktiven STEP-Format, das wie in der Konstruktion üblich auf festen Grundkörpern (Solids) basiert. IFC wiederum basiert auf der STEP (ISO 10303-21) Datenbeschreibung. Die konstruktive Geometrie wurde durch Bauwerksobjektklassen und -merkmale erweitert.

Allerdings ist die IFC-Geometrie-Beschreibung auf mehrere Arten möglich. Das scheint zunächst ein Vorteil zu sein, ist für die interpretierende Software aber schwerfällig. Eine Geometrie kann auf fünf Arten beschrieben werden:

• CSG primitiv: einfacher rechteckiger Grundkörper, kombinierbar zu komplexeren Objekten
• Extruded solid: extrudierte (gezogene) Fläche, auch Polygonal und mit Ausschnitten
• Surface model: Kombination von Flächen zu einem Körper
• Brep model: Boundary Representation, also ein Kantenmodel
• Tessellated item: ein Mesh-Modell, Körper aus einer Oberfläche, welche aus Dreiecken erstellt wird

Serialisierungen

Da IFC eine Hierarchie ist und somit eher eine Ordnungsstruktur als ein Datenformat darstellt, lässt es sich in verschiedenen Arten und Formaten abbilden bzw. serialisieren. Man könnte IFC sogar auf Papier als UML-Diagramm zeichnen. Originales IFC ist in EXPRESS (ISO 10303) geschrieben, das in den 1980er Jahren entwickelt wurde. Es ist kompakt, zeilennummeriert und ASCII-basierend. Alternativ zu ASCII kann EXPRESS auch vollständig als Grafik (EXPRESS-G) beschrieben werden. Das Format ifcZIP ist die EXPRESS / STEP-Variante in einem ZIP-Container und damit kompakter als die reine IFC-Textdatei.

Auch IFC ist komplett in XML abbildbar. Diese Serialisierung ist relativ weit verbreitet, besonders bei kleineren Bauwerken, IFC-Ausschnitten oder geometrielosen Varianten. XML ist für Menschen einfacher lesbar als EXPRESS. Aber auch in XML ist IFC durchaus komplex und nur mühsam direkt zu betrachten. Es gibt viele gute XML-Werkzeuge, die auch mit ifcXML funktionieren.

Eine weitere Art, IFC abzubilden, ist die der Ontologie in OWL (Web Ontology Language). In diesem Semantic-Web-Umfeld werden Begriffe mit vielfältigen Beziehungen verknüpft. Hier können alle IFC-Objekte und ihre Merkmale hierarchisch angeordnet werden. OWL definiert Semantik, XML definiert Syntax. Anders als in klassischen Datenstrukturen werden in Ontologien Objekte und Merkmale differenzierter und vielfältiger verknüpft. Ontologien transportieren eher Wissen über Bedeutung und Beziehungen als reine Daten. Ähnlich wie eine Datenbank, kann eine Ontologie mit Queries abgefragt und geschrieben werden. Bei Ontologien gibt es verschiedene Formatausprägungen: RDF (XML basierend), TTL (ASCII basierend), N Triples (ASCII basierend) und JSON LD (JSON basierend).

Noch im Experimentierstadium befinden sich ifcSQL und ifcJSON. Die SQL-Variante könnte das Datenhandling deutlich verbessern und Modellabfragen vereinfachen. Diese Ausprägung wird jedoch aktuell nur von einem kleinen Expertenkreis verfolgt und ist aufgrund der Komplexität von IFC nur schwer zu erstellen. Eine Ausprägung von JSON wäre für einen Transport über REST APIs und Webservices eine sinnvolle Alternative. Auch die technische Umsetzung sollte leicht zu bewerkstelligen sein. buildingSMART verfolgt diese Serialisierung und hat ifcJSON auf seiner technischen Roadmap. Auf dieser Roadmap ist in Klammern auch ein Binärformat HDF5 zu finden. Binärformate sind leichter und performanter als offene Formate, allerdings sind sie nicht offen und frei interpretierbar. Man benötigt hierfür einen Parser bzw. eine Programmbibliothek.

Model View Definition

Ein Bauwerk kann im IFC sehr umfangreich und detailliert beschreiben sein, so dass eine große Datei mit vielen Elementen und Merkmalen entsteht. Nicht für jeden Anwender und jede Software sind alle Objekte und Merkmale interessant. Mit Model View Definition (MVD) lässt sich seit 2013 ein IFC auf wesentliche Informationen filtern. MVDs werden auch in IFC-Struktur als XML – mvdXML geschrieben und reduzieren den Umfang auf die definierte Teilmenge. Das ist effizienter und performanter, als das gesamte Bauwerk zu übertragen und zu betrachten. Neben der Filterfunktion erlauben MVDs auch eine Datenumfangsdefinition für bestimmte Anwendungsfälle, also eine Art Datentemplate oder Informationsanforderung. So werden Koordinierungsmodelle, die Zusammenkunft von mehreren Teilmodellen, über ein MVD in ihrem Umfang und in ihrer Genauigkeit bestimmt. Seit IFC4.3 sind auch grundlegende MVDs im IFC-Format selbst definiert, um die Interoperabilität mit IFC zu verbessern. Mit einem noch modulareren IFC5 soll MVD teilweise durch Information Delivery Specification (IDS) abgelöst werden.

BCF

Der IFC-Gesamtumfang ist komplex und groß. Es ist kaum möglich, ein IFC zu editieren und wieder verständlich zurückzuschicken, das nicht von eigenen BIM-Autorensystemen stammt. Dies ist eines der größten Missverständnisse von IFC. Es ist ein Transport- oder Austauschformat aber kein Bearbeitungsformat. Im übertragenen Sinne lässt sich IFC mit einer PDF-Datei vergleichen, die gegenüber einer Word-Datei andere Funktionalitäten hat. Ein IFC kann also nicht von einem Programm zum nächsten gegeben und dort weiterbearbeitet werden. Jedes Programm hat seine eigene Art, Gebäudeobjekte und -merkmale zu verwalten und zu strukturieren. IFC ist nur Export oder Import.

Damit ist ein lückenloser Arbeitsfluss von vielen Bearbeitern an einem Gebäudemodell schwer zu realisieren. Eine Lösung für diese Herausforderung ist das Open BIM Collaboration-Format (BCF). Bei diesem Format wird vom Bearbeiter ein »Änderungsantrag« an den Ersteller des Gebäudemodells in einer Datei formuliert. Der Bearbeiter ändert nichts selbst am IFC, sondern übermittelt die Änderung über BCF an den Modellierer bzw. an sein Autorensystem. Er muss also nicht das gesamte Modell versenden, sondern nur die Änderung mit einem Änderungskommentar. Das kann durch eine BCF-Datei (bcfXML) erfolgen oder über einen Webservice (bcfAPI). Über die bcfAPI können BIM-Autorensysteme Arbeitsabläufe und Gebäudeplanungen über die eigenen Applikationsgrenzen hinaus ermöglichen.

Normung

IFC ist normiert in der DIN EN ISO 16739-1 »Industry Foundation Classes (IFC) für den Datenaustausch in der Bauwirtschaft und im Anlagenmanagement – Teil 1: Datenschema«. Die Joint Working Group 12 des ISO-BIM-Komitees, ISO/TC 59/SC 13/JWG12, kümmert sich seit 2013 um die internationale Normung. Den Vorsitz hat Dr.-Ing. Thomas Liebich, der die IFC-Entwicklung seit 1999 auch im buildingSMART leitet. Er ist zudem Vorsitzender der DIN-BIM-Normung. Die ISO-Gruppe JWG 12 ist ein Joint aus BIM (ISO/TC 59/SC 13) und STEP (ISO/TC 184/SC 4). Das Subkomitee SC 4 ist außerdem für die ISO 10303 zuständig und somit für EXPRESS / STEP, also die Grundstruktur und das Geometrie-Format von IFC. Die SC 4 ist durch die ANSI / USA organisiert und die SC 13 durch Standards Norway.

Eine Besonderheit ist die Doppelveröffentlichung des IFC-Standards durch ISO und buildingSMART. Die ISO ist gebührenpflichtig und Nutzer erhalten eine CD-Rom mit einem HTML-Inhalt. Auf buildingSMART kann man die nahezu identische HTML direkt online und kostenlos aufrufen. Dennoch ist es für viele Bereiche wichtig, sich auf eine Norm als Referenz und als Quelle zu verlassen. Normalerweise sind alle Normen Eigentum von ISO bzw. CEN und die Veröffentlichung des Normeninhalts unterliegt einem Copyright. IFC ist eine vertraglich zugestandene Ausnahme. Die ISO 16739-1:2018 entspricht der Version IFC 4 Add 2 TC 1 beim buildingSMART.

Leuchten im IFC

Im IFC gibt es seit Version 4 nativ auch Leuchten (IfcLightFixture). Diese können beliebig geometrisch repräsentiert werden (IfcShapeRepresentation) und verfügen über 48 elektrotechnische, mechanische und lichttechnische Merkmale (Pset_LightFixtureTypeCommon). Auch die Notbeleuchtung ist gut im IFC verankert (Pset_LightFixtureTypeSecurityLighting). Am wichtigsten für eine ordentliche Lichtberechnung und Lichtplanung ist die LVK, die ebenfalls in IFC enthalten ist. Die LVK ist neben dem gängigen C-Ebenen-System sogar in A- oder B-Ebenen beschreibbar. IFC hat für die LVK eine eigene und neue Form der Lichtstärkenablage entwickelt. Diese sieht in EXPRESS für eine in 2,5°-Schritten gemessene LVK wie folgt aus (C-Ebene, Gammawinkel, Lichtstärke):

#35118=IfcLightIntensityDistribution(.TYPE_C.,(… #35151,#35152,#35153,#35154,#35155,#35156,#35157,#35158,#35159, …); …
#35151=IfcLightDistributionData(0,(80),(20.7));
#35152=IfcLightDistributionData(0,(82.5),(8));
#35153=IfcLightDistributionData(0,(85),(2.3));
#35154=IfcLightDistributionData(0,(87.5),(0.9));
#35155=IfcLightDistributionData(0,(90),(0.5));
#35156=IfcLightDistributionData(2.5,(0),(157.5));
#35157=IfcLightDistributionData(2.5,(2.5),(158.6));
#35158=IfcLightDistributionData(2.5,(5),(160.4));
#35159=IfcLightDistributionData(2.5,(7.5),(162.8));
…

Produkt IFC

Mit IFC ist es derzeit nicht möglich, einzelne Bauteile wie Leuchten ohne ein Projekt, Bauwerk und einen Raum zu beschreiben. Daher kann es keine IFC-Datei zu einer einzelnen Leuchte geben. IFC ist, wie oben beschrieben, eine hierarchische Baumstruktur. Wenn also eine Leuchte im IFC-Format angeboten wird, bekommt man ein einfaches Projekt, z. B. einen leeren Raum in Boston, mit der gewünschten Leuchte darin. Ein Transfer dieser Leuchte aus dem leeren Raum in Boston zum eigenen Projekt ist, je nach Autorensystem, eine Herausforderung. Dieser Anwendungsfall existiert im IFC schlicht nicht.

Die Normungsgruppe CEN/TC 442/WG 2 hat sich dieser Problematik unter deutscher Initiative angenommen und eine Norm erstellt, die auf IFC-Basis eine Beschreibung eines einzelnen Bauteils ermöglicht. Mit dieser IFC-Variante – man könnte sie auch eine MVD nennen – kann eine Leuchte oder ein ganzer Katalog in IFC beschrieben und transportiert werden. Es können alle IFC-Serialisierungen verwendet werden, wobei XML beim Erstellen der Norm verwendet wurde. Die DIN EN 17549-1 »Building Information Modelling (BIM) – Datenstruktur nach EN ISO 16739-1:2018 für den Austausch von Datenvorlagen und Datenblättern für Bauobjekte – Teil 1: Datenvorlagen und konfigurierte Bauobjekte« und DIN EN 17549-2 »Teil 2: Anforderungen und konfigurierbare Produkte« sind technisch abgeschlossen und sollen noch dieses Jahr veröffentlicht werden. Die Struktur besteht aus drei Teilen:

• Header, der das Format einleitet und Metainformationen enthält
• Product Data Template definiert die Datenstruktur und alle Merkmale
• Product Data, die eigentliche Produktbeschreibung nach den definierten Merkmalen, die Geometrie und Verweise auf Dokumente und Dateien

Vermutlich wird es nach der Veröffentlichung der Norm etwas Zeit brauchen, bevor die ersten Tools und Bibliotheken für COD, Construction Objects Data View, entstehen und sich verbreiten. So müssen sich die BIM-Autorensysteme erst dem Format annehmen und es einlesbar machen und Bauteilhersteller müssen das Format erzeugen.

Beleuchtung im IFC

IFC kann auch im rudimentären Sinne Beleuchtungsinformationen zu Räumen übermitteln. So kann ein Raum (IfcSpace) Anforderungen an eine Beleuchtung als Merkmal enthalten (Pset_SpaceLightingRequirements). Dahinter kann aber lediglich als Boolean Kunstlicht (ArtificialLighting) vermerkt werden (also: Kunstlicht erforderlich oder nicht) und die geforderte Beleuchtungsstärke in lux (IfcIlluminanceMeasure). Lichtberechnungsergebnisse oder andere Gütemerkmale können nicht nativ im IFC abgelegt werden. Sie können über eigene Properties angehängt werden.

IFC-Applikationen

Es gibt kein BIM-Autorenprogramm, das nativ IFC als internes Basisformat vorsieht. IFC ist in keiner Applikation beheimatet. Es ist ein reines Austauschformat zwischen den BIM-Programmen. Nahezu alle Autorensysteme, die sich BIM nennen, haben heute eine IFC-Schnittstelle. Es gibt einige gute und frei verfügbare IFC-Viewer, die es ermöglichen, ein Bauwerk ohne jede Bearbeitungsoption anzusehen, z. B. der FZK Viewer des KIT und IFC++ von Fabian Gerold. Daneben gibt es viele offene Toolkits und Parser, die von einer Open Source Community getragen werden.

OpenBIM vs. ClosedBIM

Ohne IFC gäbe es schlicht kein OpenBIM. Als offenes, freies, normiertes und kostenloses Format, das Bauwerke und Gebäude beschreibt und übertragen kann, ist IFC einzigartig. Alle anderen Formate, die Bauwerke oder Bauwerksinformationen beinhalten, sind geschlossen und proprietär. Ein Grund dafür ist die Komplexität eines kompletten Bauwerks mit allen Details. Anhand von IFC lässt sich gut erkennen, welchen Aufwand die Erstellung und die Pflege kostet. Alle BIM-Autorensysteme haben ihr Gebäudemodell in einer Klassenstruktur für ihre Anwendung und ihre Anforderungen angepasst. Selbst wenn diese offen und frei verfügbar wären, würden sie nicht kompatibel oder einfach verwendbar sein.

IFC ist eine weitere Klassenstruktur, der keiner Anwendung und keiner Software zugeordnet ist und die eine aufwendige öffentliche Pflegeorganisation hat. Das macht IFC besonders und ermöglicht einen software-neutralen Gebäudeaustausch, allerdings nur in der Schnittmenge von IFC und dem System, das es ihm umgibt (z. B. Merkmalsserver). Alle BIM-Normen von buildingSMART, CEN, ISO und andere sind für OpenBIM gedacht – und damit für einen neutralen und offen Austausch von Bauwerksinformationen.

ClosedBIM sind softwarebezogene Formate für einen Bauwerksaustausch. Wie bereits erläutert haben alle BIM-Autorensysteme ihr eigenes Format basierend auf dem, was ihre Anwendung von einem Bauwerk zur Verfügung stellt. Diese sind umfangreich und können im Detail mit IFC mithalten. Eine Revit-DB verfügt über tausende Klassen und Merkmale. Die meisten proprietären Datenformate sind binär und nicht ohne weiteres einsehbar, vor allem, um das Format klein und schnell verarbeitbar zu halten. Eine binäre Revit-Datei lässt sich schneller mit mehr Inhalt verarbeiten als ein Express-IFC (ifcXML wäre noch langsamer und größer). Die BIM-Autorensysteme können mit ihren Formaten gut umgehen. Auch der Datenaustausch von mehreren Akteuren mit der gleichen Software funktioniert meist tadellos.

Natürlich ist man dabei immer an einen Anbieter von Autorensystemen gebunden und kann nicht frei das Programm wechseln. Das ist der Nachteil von ClosedBIM. Alle BIM-Autorensysteme verfügen über eine IFC-Schnittstelle, meist in beide Richtungen, um einen Austausch der Bauwerksinformationen zu anderen Programmen zu ermöglichen. Gerade die Komplexität und die Vielzahl an Beteiligten lassen es unwahrscheinlich erscheinen, dass alle Planer und Gebäudeakteure mit einer BIM-Software arbeiten. Leider funktioniert der Austausch mit IFC in der Praxis heutzutage noch nicht problemlos. Es fehlen Informationen oder diese werden falsch übermittelt. Bei der Komplexität und dem Umfang eines Gebäudemodells und dessen zweifacher Konvertierung von einem Autorensystem zu IFC zu einem anderen Autorensystem ist das kein Wunder. Die Autorensysteme fangen bereits an, die IFC-Konvertierung abzukürzen und erstellen AddOns für andere Autorensysteme, um einen direkteren Datenaustausch zu ermöglichen. So hat Tekla ein Revit-AddOn erstellt.

Fast alle BIM-Autorensystemen haben offene Schnittstellen, um sich mit anderen Anwendungen direkt zu verbinden. RELUX hat ein Revit-AddOn zur Lichtplanung direkt in Revit erstellt. Über den Umweg eines Imports oder Exports durch Revit ist so eine Verwendung von IFC in RELUX bidirektional möglich. Es ist allerdings aufwendig, für alle Autorensysteme ein AddOn zu schreiben und zu unterhalten. Das ist ein weiterer Nachteil von ClosedBIM.

Aktuell scheint sich global in der Planungspraxis eher ClosedBIM, vor allem mit Autodesk Revit, durchzusetzen. Aber der Traum von einem IFC-basierten OpenBIM ist damit noch nicht vorbei und es lohnt sich, OpenBIM weiterzuentwickeln. Je weiter BIM in öffentliche und behördliche Bereiche vordringt, desto wichtiger wird ein neutrales Austauschformat. IFC ist für einen Transport und Austausch ideal geeignet. Die Bauwerks-Modell-Erstellung und Bearbeitung wird IFC aber nie leisten können. Das war und ist auch nicht das Ziel der IFC-Schöpfer.