IFC – endlich verständlich

Der Internationale Fußballclub Rostock, abgekürzt IFC, erfreut sich seit einigen Jahren ungewohnt vieler Anfragen bei Google. Gesucht werden jedoch nur selten die Freizeitkicker aus der 2. Kreisklasse Warnow, sondern das Datenformat IFC, das die digitale Bauwerksplanung in die Zukunft führen wird. Doch warum interessieren sich so viele Leute für ein Datenformat?

Formatchaos

Stellen Sie sich vor, Sie wären wieder in der Schule und schrieben mit mehreren Mitschülern an einer hochkomplexen Hausarbeit, beispielsweise zum Thema „Der Elefant – niedliches Haustier oder praktische Alternative zur Brieftaube?“ Gemeinsam entscheiden Sie sich, das Schreiben der unterschiedlichen Kapitel untereinander aufzuteilen.

Mitschüler Archibald übernimmt Kapitel 1: „Äußere Erscheinung und Ästhetik des Elefanten“. Klassenkamerad Statislav beschäftigt sich mit dem Kapitel „Knochengerüst und Muskelaufbau“, und Sie sind für die „Analyse des Verdauungstrakts“ zuständig.

Die Herausforderung: Sie wollen Ihren Abschnitt mit Microsoft Word schreiben, Archibald besitzt einen Mac und verwendet OpenOffice als kostenlose Alternative zu Pages, und Statislav möchte viele Zeichnungen und Illustrationen einfügen. Er verwendet daher InDesign von Adobe. Alle Programme nutzen nativ unterschiedliche Dateiformate (.docx/.odt/.indd). Trotzdem soll eine zusammenhängende Arbeit entstehen. Wie fügen Sie die verschiedenen Kapitel zusammen?

Die IFC-Datenbank einer Stütze (Bild: hammeskrause architekten Stuttgart)

Die Antwort auf diese alltägliche Datenverarbeitungsfrage kann Ihnen heute jeder Viertklässler geben: Portable Document Format. Das im Jahr 1993 erschienene und international wie kein zweites Dateiformat verbreitete PDF ist aus Geschäftswelt und Privatleben nicht mehr wegzudenken.

Merke: Ein international standardisiertes Datenaustauschformat macht es uns möglich, unsere Arbeit in den Programmen zu erledigen, die wir entweder am besten beherrschen, die wir uns leisten können oder für die die jeweilige Aufgabe am geeignetsten sind.

Babylonische Sprachverwirrung

Nehmen wir ein anderes fiktives Beispiel, diesmal aus dem Buch der Bücher:
Vor einigen tausend Jahren trafen sich Investoren in einer fruchtbaren Ebene östlich des Tigris, bildeten eine Baugemeinschaft und sprachen zueinander: "Nun denn, lasset uns im großen Stil Fertigbetonteile aufeinanderstapeln und einen Flughafen bauen, der größer ist als der Himmel." Als der HERR die Anmaßung der Projektbeteiligten hörte, erzürnte er aufs Äußerste, stieg vom Himmel und verwirrte die Sprachen der Menschen. Fortan murmelte der Architekt Altgriechisch, der Tragwerksplaner schwieg, der Projektsteuerer verstand nur noch Spanisch, und der Brandschützer bediente sich indigener Klicklaute. Long story short: Das Projekt konnte nie abgeschlossen werden, egal wie viele Kleinkönige und Provinzfürsten ihren Thron räumen mussten.

Klar, eine solche Geschichte könnte sich heutzutage mit der Verwendung einer anerkannten Weltsprache nicht wiederholen. Denn merke: Erst eine einheitliche Sprache macht internationale Großprojekte möglich.

Von DWG zu Industry Foundation Classes

Als ersten einheitlichen digitalen Standard zum Austausch von Vektorendaten (d. h., konventionellen CAD-Zeichnungen) etablierte Autodesk 1982 das „.D(ra)W(in)G-Format“. Mit diesem Standard gelang es, Zeichnungen mit (mehr oder) weniger Aufwand sowohl unabhängig von der Software, in der sie erzeugt wurden, als auch plattformunabhängig und damit losgelöst vom Betriebssystem auszutauschen.

Ein Meilenstein in der Planungskulturgeschichte. Seither hat sich wenig bis nichts geändert, doch nun steht uns die nächste Planungskulturrevolution ins Haus: BIM kommt. Plötzlich stellt sich nicht nur die Frage nach Layer-Name und Strichstärke, sondern es müssen neben einer weiteren Dimension – die Welt wird 3D – auch zahlreiche Metadaten, also Informationen über ein Bauteil, transportiert werden, die nicht seine Geometrie betreffen. Banales Beispiel: die Farbe.

Zunächst konnten die meisten Softwarehersteller die Aufgabe nur nativ bewältigen, also im eigenen Dateiformat. Es war nur der Austausch zwischen gleichen Softwareprodukten möglich. Einige Hersteller witterten sogar einen Marktvorteil und versuchten, die Entwicklung eines internationalen Standards zu boykottieren, in der Hoffnung, dadurch mehr Kunden zur Verwendung ihres Produkts zu nötigen.

Ab dem Jahrtausendwechsel begann die Industrieallianz für Interoperabilität (IAI) mit der Entwicklung eines Austauschformats, das den eingängigen Namen „Industry Foundation Classes“ trägt –kurz: IFC. Wahrscheinlich, um nicht mit den überall aus dem Boden sprießenden Instituten für angewandte Informatik (auch IAI) verwechselt zu werden, wurde aus der Industrieallianz IAI schließlich die internationale nichtstaatliche Non-Profit-Organisation buildingSMART International.

Diese gliedert sich in Landes-Chapter wie beispielsweise buildingSMART Germany und in Regionalgruppen wie der Regionalgruppe Stuttgart. Der unabhängige Verein buildingSMART beschäftigt sich mit der kontinuierlichen internationalen Weiterentwicklung und Standardisierung von IFC und anderen Formaten und versteht sich selbst als Gremium der Vorstandardisierung. Er arbeitet eng mit der Internationalen Organisation für Normung ISO (vom griechischen Wort isos, deutsch: gleich) und dem Zentrum für europäische Normung CEN zusammen, auf nationaler Ebene auch mit dem Verein Deutscher Ingenieure VDI. Das IFC Format ist in der ISO 16739 registriert.                                                                         

Doch genug der Theorie: Was kann das?

Ein bisschen wie ein PDF

Zunächst einmal kann IFC (fast*) unabhängig davon, mit welchem Programm sie erzeugt wird, von (fast**) allen anderen 3D-Programmen gelesen werden, und ermöglicht ähnlich wie das PDF-Format einen (fast***) reibungslosen Austausch von beliebigen dreidimensionalen Modellen.

Eine IFC-Datei ist immer gleich aufgebaut. Liegenschaft-Gebäude-Geschoss-Bauteil bilden die in jedem Projekt anzuwendende Hierarchie. Jedem Bauteil wird, sobald man es in einer Software platziert, eine eindeutige 32-stellige GUID (Globally Unique Identifier) zugewiesen, über die es den ganzen Planungsprozess hinweg identifiziert werden kann. So lässt sich beispielsweise feststellen, ob eine Stütze lediglich verschoben oder durch eine neue, eventuell andersartige Stütze ersetzt wurde. Dabei ist ein importiertes IFC in der Regel nicht dafür gedacht, geometrisch verändert zu werden – vergleichbar mit einem referenzierten PDF in InDesign, das auch nicht modifizierbar ist. Es dient als Grundlage für die weitere Bearbeitung des eigenen Modells sowie als Basis für Analysen und Simulationen.

Und die einheitliche Sprache?

Hier kommt der Clou: Eine der Haupttätigkeiten von buildingSMART besteht in der internationalen Standardisierung der oben erwähnten Metadaten. In langen, schlaflosen Nächten haben sich Experten aus aller Welt getroffen und in endlosen Katalogen alle möglichen Attribute und die Art ihrer Beschreibung festgehalten. So ist (fast****) jedem Bauteil eine oder mehrere Datenbanken zugewiesen, in denen die Attribute verwaltet werden.

Nehmen wir zum Beispiel eine Stütze. Eine Stütze hat als IFC-Objekt immer die Datenbank mit dem Namen „IfcColumnCommon“ zugewiesen. Diese Datenbanken werden offiziell „Ifc-Property-Sets“ genannt – oder unter coolen Kids einfach „P-Sets“. Darüber hinaus ist international standardisiert, dass diese Datenbank unserer Stütze immer die Datenbankfelder „Reference“ (Typenbezeichnung), „Slope“ (Neigung), „IsExternal“ (ist es ein Außenbauteil?), „LoadBearing“ (ist diese Stütze tragend? – ein schöner Scherz in sich) und „FireRating“ (Feuerwiderstandsklasse) beinhalten muss.

Neben einer detaillierten Beschreibung, was sich die internationale Gemeinschaft der Bauexperten unter den einzelnen Attributen vorstellt, besteht die Dokumentation, die übrigens auf der unten genannten buildingSMART-Website einsehbar ist, noch aus der sogenannten Datenbankfeldeintragstypendefiniton (eine wirklich gelungene Wortschöpfung). Diese beschreibt, welche Werte in den Datenbankfeldern zulässig sind. Während im Datenbankfeld „FireRating“ alle möglichen Kombinationen von Zahlen und Buchstaben möglich sein müssen, um den jeweiligen nationalen Bestimmungen entsprechen zu können, sollen im Datenbankfeld „Slope“ ausschließlich Fließkommazahlen eingetragen werden. Im Datenbankfeld „IsExternal“ ist wiederum nur Ja oder Nein beziehungsweise True/False oder 1/0 möglich. Das wird in den meisten Systemen mittels Haken setzen oder kein Haken setzen eingegeben.

Mit der internationalen Einigung, diese Regeln beim Erzeugen einer IFC einzuhalten, ist es völlig irrelevant, wo der Verfasser sitzt, ob im Dschungel Boliviens oder der Steppe Brandenburgs. Babylonische Missverständnisse sind ausgeschlossen.

Eine saubere IFC-Struktur (Bild: hammeskrause architekten Stuttgart)

Nun setzt diese Vereinbarung, wie jede internationale Zusammenarbeit auch, eine gewisse Kompromissfähigkeit voraus. Oft ist es schwierig, sich auf Teilaspekte zu einigen. So ist zum Beispiel festgelegt, dass die Dichtigkeit einer Tür nur mit Ja oder Nein angegeben werden soll. Gerade auf dem europäischen Planungsmarkt würden wir jedoch gern zwischen einer dichtschließenden Tür mit Absenkdichtung und einer umlaufend dichten Tür, vergleichbar mit einer U-Boot-Tür, differenzieren.

Darüber hinaus haben spezialisierte Büros mit seltenen Anforderungen das Bedürfnis, auch ungewöhnliche Attribute an Bauteilen anzubringen. Bis man allerdings international erklärt hat, dass man einem Laborraumobjekt gern das Attribut „Ist zu Desinfektionszwecken komplett H2O2 (Wasserstoffperoxid) beständig: ja/nein“ beifügen würde, können schon mal Wochen vergehen. Ebenso, bis sich alle an der Standardisierung Beteiligten dafür ausgesprochen haben, ein neues Release zu veröffentlichen und zu implementieren. Viele Wochen. So viele Wochen, dass Jahre daraus werden.

Wie kommen wir diesem Problem bei? Nicht verzagen: Jeder Nutzer kann einem Objekt selbstdefinierte, IFC-konforme Datenbanken mit eigenen Datenbankenfeldern anhängen, sogenannte „IfcCustomPropertySets“. Sie sind völlig frei definierbar und dennoch in gleicher Art und Weise per IFC transportierbar. Diese selbst definierten Attribute sollten aber unbedingt im projekteigenen BIM-Abwicklungsplan (BAP) für alle Planungsbeteiligte transparent dokumentiert sein.

Achtung: Einige Programme, die IFCs weiterverwerten wollen, wie beispielsweise Kostenberechnungsprogramme, können noch keine „CustomPSets“ verarbeiten. Erkundigen Sie sich frühzeitig bei Ihrem Distributor über die Fähigkeiten des von Ihnen verwendeten Programms und verleihen Sie nötigenfalls Ihrer Entrüstung über fehlende Implementierungen vehement Ausdruck. Nur so wird sich etwas ändern. Denn IFC ist programmiersprachentechnisch gesehen nicht schwer. Die verwendeten Programmiersprachen EXPRESS (Vergleichbar mit STEP STandard for the Exchange of Product model data) und XML (Extensible Markup Language) lassen sich quasi mit jedem Texteditor öffnen und bearbeiten. Sie sind daher universell und unabhängig von der Programmiersprache ansteuerbar. Für einen richtigen Geek keine Herausforderung.

Interessiert den Tragwerksplaner die Farbe der Türen?

Gute Frage – einfache Antwort: „Nein“ oder „Nur wenn er hobbymäßig Ästhet ist“. Um die Überflutung von Daten zu vermeiden, ist es möglich, international genormte Teilbereiche der kompletten Attributsets zu exportieren. Diese Definitionen nennen sich „Model-View-Definitionen“ (MVD).

Für die neueste Version von IFC (IFC4) existieren der „Reference-View“ und der „Design-Transfer-View“ als Definitionen. Wobei Letzterer tatsächlich alle Attribute übergibt, der „Reference-View“ jedoch nur eine begrenzte Auswahl an Standardinformationen für das „Modell Referenzieren“ erzeugt.

Um ganz ehrlich zu sein: Ich kenne nicht viele Programme, die schon aktiv mit MVDs arbeiten. Derzeit ist es üblich, alle Informationen zu übergeben und dem Empfänger das Filtern nach Relevanz zu überlassen. In diesem Bereich gibt es also im Prozess noch ordentlich Luft nach oben. Genauso wie in der Verwendung der IFC in Variante 4. Zwar gilt sie seit 2015 als einsatzfähige Version, jedoch geht die Implementierung von Seiten der Softwarehäuser nur schleppend voran, so dass Sie in der Regel auf Daten aus der Vorgängerversion IFC2x3 stoßen werden. Lassen Sie sich davon nicht irritieren, sondern mahnen Sie die zügige Implementierung bei Ihrem örtlichen Distributor an.

Fazit

Es ist nicht meine Aufgabe, Ihnen ein Ergebnis vorzukauen. Mein Ziel ist es, Sie zu informieren und Ihnen vielleicht ein wenig die Sorgen zu nehmen. Lassen Sie sich von niemanden erzählen, auch nicht von mir, was mit IFC machbar ist und was nicht. Sie kommen um IFC nicht herum, probieren Sie es aus, es lohnt sich.

Wenn nicht, schreiben Sie mir. Gern bin ich Prellbock für Ihren Frust, wenn der Datenaustausch mal wieder völlig schief gegangen ist. Und wenn Sie wirklich etwas bewegen wollen, richten Sie sich an die nächstgelegene buildingSMART-Regionalgruppe. Dort finden Sie geballte Fachkompetenz und Menschen, die in vielen Fällen schon an derselben Stelle gestrauchelt sind wie Sie, und immer noch stehen.

Bild Mitte rechts: Liste von Guids diverser Bauteile (Abbildung: hammeskrause architekten Stuttgart)   

Verzeichnis der buildingSMART-Regionalgruppen: https://www.buildingsmart.de/bim-regional
Dokumentationen von IFC & Co.: http://www.buildingsmart-tech.org/

Fußnoten:

* Es gibt Fälle, in denen bestimmte Programme IFCs ausschließlich mittels unautorisiert eingespeisten Plug-Ins erzeugen können. Da ist die Programmierfehlerquote hoch, und es kann zu Fehlfunktionen kommen. Vertrauen Sie daher nur zertifizierten Programmierern. Man lässt ja auch nicht jeden Hobbyfotograf am Hubble-Teleskop herumschrauben.

** So wie Paint kein PDF öffnen kann, gibt es auch jetzt noch Programme, die nicht IFC tauglich sind. Deren Zahl schrumpft aber in den vergangenen Jahren immer mehr. Wer nicht mit der Zeit geht, geht mit der Zeit.

*** Ausnahmen gibt es immer. Kein System ist absolut krisensicher. Ahornsirup klebt.

**** Speziell im Bereich der technischen Gebäudeausrüstung TGA, genauer HLSKE, sind allerdings so viele Komponenten zu behandeln, dass sich der Grad der Vollständigkeit in der Standardisierung besonders im Hinblick auf die technischen Weiterentwicklungen naturgemäß nur limesartig annähern kann.