Das Datenaustausch-Format IFC ist fest mit dem Begriff BIM verbunden. Auch wenn zunehmend Cloud-L\u00f6sungen in den Fokus von Anwendern im Bauwesen geraten und diese einen Austausch \u00fcberfl\u00fcssig erscheinen lassen, bin ich der \u00dcberzeugung, dass Datenaustauschformate weiterhin notwendig sind. Daher ist es wichtig, sich mit den M\u00f6glichkeiten von IFC zu besch\u00e4ftigen.<\/p>\n\n\n\n
IFC im Hochbau<\/strong><\/p>\n\n\n\n Besonders bei Hochbauma\u00dfnahmen ist bereits in der Planungsphase ein reger Austausch zwischen Architekten und Fachplanern notwendig. So erhalten zum Beispiel Planer f\u00fcr die technische Geb\u00e4udeausr\u00fcstung (TGA) von Architekten Rohbaumodelle und erg\u00e4nzen diese um die von ihnen vorgesehenen Leitungen und Aggregate.<\/p>\n\n\n\n Bei dieser Arbeitsweise werden die Teilmodelle nach und nach in einem Koordinationsmodell vereinigt, in dem dann auch Kollisionspr\u00fcfungen vorgenommen werden. Dieser Austausch hochwertiger Dateiformate erfolgt in der Regel \u00fcber das internationale Format IFC, das bereits seit vielen Jahren im Hochbau genutzt wird. IFC ist die Abk\u00fcrzung f\u00fcr \u201eIndustrial Foundation Classes\u2018, was w\u00f6rtlich \u00fcbersetzt ‚industrielle Grundlagenklassen-Bauteile‘ bedeutet. Diese Klassen beschreiben Bauteile wie W\u00e4nde oder Decken. Augenscheinlich handelt es sich somit um eine klassische Anwendung f\u00fcr den Hochbau.<\/p>\n\n\n\n IFC im Tiefbau<\/strong><\/p>\n\n\n\n Weil es beim Datenaustausch-Format IFC zun\u00e4chst in erster Linie um die Arbeit mit Bauteilen aus dem Hochbau geht, h\u00f6rt man im Zusammenhang mit Stra\u00dfen- und Tiefbauprojekten immer wieder das Argument, dass BIM in dieser Sparte des Bauwesens erst m\u00f6glich wird, wenn es eine sogenannte IFC roads \u2013 Schnittstelle gibt.<\/p>\n\n\n\n Meiner Meinung nach ist die Ansicht, BIM ist derzeit noch nicht im Stra\u00dfen- und Tiefbau anwendbar, aus mehreren Gr\u00fcnden falsch. Erstens lassen sich aufgrund der langen Historie der Digitalisierung im Stra\u00dfen- und Tiefbau schon heute viele Daten in ausreichender und guter Qualit\u00e4t mit etablierten Schnittstellen-Formaten wie REB, ISYBAU oder LandXML austauschen. Eine IFC roads \u2013 Schnittstelle ist somit nicht zwingend notwendig, um mit der Anwendung von BIM bereits heute zu beginnen.<\/p>\n\n\n\n Zweitens wird IFC und die damit verbundenen M\u00f6glichkeiten meines Erachtens falsch eingesch\u00e4tzt, wenn man die Nutzung ausschlie\u00dflich auf den Hochbau begrenzt. Um diese Aussage zu manifestieren, erl\u00e4utere ich im folgenden das Prinzip von IFC.<\/p>\n\n\n\n Wie funktioniert IFC<\/strong><\/p>\n\n\n\n Grundprinzip des Datenaustausch-Formates IFC ist, dass Teilobjekte von Bauma\u00dfnahmen in der Regel nicht statisch, sondern \u00fcber ver\u00e4nderbare Parameter beschrieben werden. Als Beispiel hierf\u00fcr eignet sich bestens die Betrachtung des im Hochbau \u00fcblichen Objektes Wand.<\/p>\n\n\n\n Mit dem Format IFC werden nicht die Wand-Ecken als Koordinaten \u00fcbergeben, sondern ein Grundri\u00df-Polygon. Diese geometrische Form l\u00e4sst sich in der L\u00e4nge und Dicke leicht \u00e4ndern, genauso l\u00e4sst sich der Parameter H\u00f6he anpassen. Nach der Daten\u00fcbergabe wird im Zielsystem aus dem Einf\u00fcgepunkt und dem Einf\u00fcgewinkel zusammen mit den Parametern L\u00e4nge, Dicke und H\u00f6he wieder ein konkretes 3D-Modell erstellt.<\/p>\n\n\n\n Diese Vorgehensweise hat den Charme, dass Anwender mit abweichenden CAD-Systemen Objekte viel leichter \u00e4ndern k\u00f6nnen, weil die Objekte nicht \u00fcber feste Koordinaten gespeichert sind. Auch nachtr\u00e4glich k\u00f6nnen Parameter leicht angepasst und somit die Geometrie des geplanten Bauwerks ver\u00e4ndert werden. Auf den ersten Blick wirkt das aus meiner Sicht sehr intelligent und ist bei nachtr\u00e4glichen Planungs\u00e4nderungen ohne Frage ein gro\u00dfer Vorteil.<\/p>\n\n\n\n Gefahren bei der Nutzung von IFC<\/strong><\/p>\n\n\n\n Das beschriebene Prinzip der Parametrisierung bei der Daten\u00fcbergabe via IFC hat jedoch einige ganz entscheidende Nachteile. Wenn das Zielsystem die Parameter anders interpretiert als das Quellsystem, kann es zu schweren Fehlern f\u00fchren. Geometrien und auch Mengen k\u00f6nnen sich ver\u00e4ndern. Zudem ist es oft gar nicht notwendig oder auch nicht gewollt, dass ein Planungspartner Daten von Teilobjekten \u00e4ndern kann. Das Gefahrenpotenzial ist somit gro\u00df und deshalb erinnert mich die Herausgabe eines parametrisierten Modells an die \u00dcberlassung eines Blanko-Schecks.<\/p>\n\n\n\n Um meine Aussagen zu unterstreichen, hier ein Beispiel aus dem Hochbau. Man stelle sich vor, ein TGA-Planer \u00e4ndert die H\u00f6he eines Unterzugs, um seine Leitungen eleganter zu f\u00fchren. Und das ohne R\u00fccksicht auf die Tatsache, dass ein Statiker in dem Unterzug bereits eine sensibel berechnete Bewehrung platziert hat. Diese Szene ist zugegebenerma\u00dfen konstruiert, weil TGA-Planer nur ihre Fach-Modelle zur\u00fcckliefern und nicht die Rohbau-Modelle, aber sie verdeutlicht das Problem.<\/p>\n\n\n\n Vorteile von Proxy-Objekte im IFC<\/strong><\/p>\n\n\n\n Die bisher gemachten Aussagen zeigen: Oft ist ein statisches Modell besser geeignet als ein parametrisiertes. Nun w\u00e4re es falsch zu vermuten, dass somit das IFC-Format ausscheidet. Vielmehr gibt es auch bei IFC die passende Anwendung, n\u00e4mlich die Nutzung von Proxy-Objekten.<\/p>\n\n\n\n Um ein gr\u00f6\u00dferes Verst\u00e4ndnis f\u00fcr die Entwicklung dieser Anwendung zu erlangen, lohnt sich ein Blick in die Vergangenheit. Die Programmierer von IFC waren sich dar\u00fcber im klaren, dass nicht alle Bauteile in Standardklassen wie zum Beispiel Wand, Decke oder St\u00fctze einzuteilen sind. Und so entwickelten sie \u2013 vielleicht sogar als eine Art Notl\u00f6sung \u2013 die Proxy-Objekte, die man auch als \u201ePlatzhalterobjekte\u201c verstehen kann. Es kann sein, dass genau diese Bezeichnung immer noch dazu f\u00fchrt, dass die M\u00f6glichkeiten von Proxy-Objekten untersch\u00e4tzt werden. Denn ein Platzhalterobjekt im Sinn von etwas Minderwertigem k\u00f6nnte aus Sicht mancher Nutzer die Assoziation hervorrufen, dass dabei Objekte in ihrer Geometrie stark reduziert werden.<\/p>\n\n\n\n Auch hier ist es sinnvoll, mit Hilfe von Beispielen das Thema besser zu durchdringen: Wenn in einer Planung eine Stra\u00dfenlampe lediglich als Punkt oder kleiner Zylinder repr\u00e4sentiert wird, ist das sicherlich ein Platzhalter im urspr\u00fcnglichen Sinn. Allerdings erm\u00f6glichen es IFC-Proxy-Objekte, eine vollst\u00e4ndige geometrische Beschreibung des K\u00f6rpers zu \u00fcbergeben. Sie sind daher keine Platzhalter im strengen Sinn. Denn Anwender k\u00f6nnen in IFC ein Proxy-Objekt optisch und geometrisch korrekt durch dreidimensionale Punkte und Dreiecke beschreiben.<\/p>\n\n\n\n Nutzung von Proxy-Objekten im Tiefbau<\/strong><\/p>\n\n\n\n Die M\u00f6glichkeit, Proxy-Objekte in IFC optisch und geometrisch korrekt durch dreidimensionale Punkte und Dreiecke zu beschreiben, kommt Stra\u00dfen- und Tiefbauern sofort bekannt vor. Denn Punkte und Dreiecke bezeichnen, neben Bruchlinien, ein Digitales Gel\u00e4ndemodell (DGM). Die Schlussfolgerung lautet demnach: Ein Proxy-Objekt kann ohne weiteres ein DGM beschreiben. Genauso kann ein Volumenk\u00f6rper dargestellt werden, der gedanklich aus zwei DGM (Topf und Deckel) besteht. \u00dcbrigens: Die nahezu komplette Welt der Computer-Spiele und Animationen ist so aufgebaut. Lara Croft, Protagonistin der Video- und Computerspiel-Serie Tomb Raider und auch gef\u00e4hrlich aussehende Flugdrachen sind datentechnisch nichts anderes als r\u00e4umlich gekr\u00fcmmte, geschlossene DGM.<\/p>\n\n\n\n Daraus ergibt sich eine sehr wichtige Erkenntnis: Es ist schon lange m\u00f6glich, beliebige Tiefbau-Objekte \u00fcber Dreiecke und somit mit statischer Geometrie zu beschreiben und via IFC auszutauschen. Diese Objekte k\u00f6nnen beliebige Attribute besitzen, wie andere IFC-Klassen auch. Wenn die dynamische Ver\u00e4nderbarkeit der Objekte keine oder oder nur eine geringe Rolle spielt, sind diese Platzhalter demnach vollwertige BIM-Objekte.<\/p>\n\n\n\n Frank Kocher<\/strong><\/p>\n","protected":false},"excerpt":{"rendered":" Das Datenaustausch-Format IFC ist fest mit dem Begriff BIM verbunden. Auch wenn zunehmend Cloud-L\u00f6sungen in den Fokus von Anwendern im Bauwesen geraten und diese einen Austausch \u00fcberfl\u00fcssig erscheinen lassen, bin ich der \u00dcberzeugung, dass Datenaustauschformate weiterhin notwendig sind. Daher ist es wichtig, sich mit den M\u00f6glichkeiten von IFC zu besch\u00e4ftigen. IFC im Hochbau Besonders bei Hochbauma\u00dfnahmen ist bereits in der Planungsphase ein reger Austausch zwischen Architekten und Fachplanern notwendig. So erhalten zum Beispiel Planer f\u00fcr die technische Geb\u00e4udeausr\u00fcstung (TGA) von…<\/p>\n