The Age of Change: IFC is a thing of the past or why CAD vendors are willing to give up IFC for USD in 14 key facts

🚀 Major update: DDC Free Revit Converter expands capabilities! Revit 2004 and selecting the speed and completeness of conversion.

20 November 2024

Das Zeitalter des Wandels: IFC gehört der Vergangenheit an oder warum ADS und andere CAD-Anbieter bereit sind, IFC für USD aufzugeben — 14 wichtige Fakten

3 December 2024

The Age of Change: IFC is a thing of the past or why CAD vendors are willing to give up IFC for USD in 14 key facts

1. Gründung der AOUSD-Allianz

Im Jahr 2023 werden ADSK, Nvidia und Apple die globale Allianz AOUSD bilden, um das USD-Format in der Baubranche zu fördern. Die wichtigen building-SMART-Mitglieder Hexagon und Trimble treten der Allianz ebenfalls bei. Die Initiative gilt als Schritt in Richtung eines “offenen Formats”, das durch neue Konzepte zur Vereinheitlichung von Daten und zur Standardisierung von Prozessen unterstützt wird.

Das Konzept der Verwendung des USD-Formats, wie es in den frühen 90er Jahren mit dem IFC-Format der Fall war, wird mit aktiver Unterstützung der HOK-Unternehmen vorangetrieben, die eine Schlüsselrolle bei der Verbreitung des USD in der Bauindustrie übernommen haben.

2. HOK: von der IFC-Registrierung zur USD-Förderung

Seit 2022 haben Vertreter von HOK (HOK-CEO P. MacLeamy registrierte das IFC-Format 1994 bei ADSK und organisierte building-SMART) die Verwendung des USD-Formats im Bauwesen auf der building-SMART-Ebene aktiv gefördert:

Diese Dokumente und Materialien, die der Förderung von USD gewidmet sind, betonen die Komplexität der Arbeit mit dem IFC-Format, die für ADSK-Entwickler zu einem ernsthaften Hindernis für die Verwendung von IFC in ihren Produkten geworden sein könnte.

3. ADSK weiß nicht, wie man IFCs exportiert

Trotz der Tatsache, dass ADSK laut Wikipedia die Schaffung des IFC-Formats initiiert hat (obwohl die Entwicklung de facto von L. Obermeyer begonnen wurde), war das Unternehmen bisher nicht in der Lage, unabhängig eine vollständige native Unterstützung für den IFC-Export in seinen Produkten wie Revit zu implementieren. In 20 Jahren ist es dem Entwicklungsteam von ADSK nicht gelungen, eine qualitativ hochwertige Unterstützung in Revit, seinem 2002 erworbenen Hauptprodukt, zu implementieren, und ab 2019 verwendet das Unternehmen offiziell ein IFC-SDK, das von der Open Design Alliance (ODA) entwickelt wurde, einer Organisation, die seit 1998 ADSK-Formate zurückentwickelt und mit der ADSK in den letzten 15 Jahren zahlreiche Rechtsstreitigkeiten geführt hat.

Ursprünglich wurden die ODA-Tools dank der Beziehungen zwischen dem Team des Revit-Erfinders Leonid Reitz und den SoftDev-ODA-Entwicklern in Revit integriert, bevor es von ADSK übernommen wurde. Nach dem Kauf von Revit und der Veröffentlichung mehrerer Versionen des Produkts entdeckte ADSK zufällig das Vorhandensein dieses “feindlichen” SDK in seinem Produkt und ersetzte es umgehend durch sein eigenes RealDWG-SDK. Fast 20 Jahre später hat sich die Situation dramatisch verändert: ADSK trat nicht nur der ODA bei, sondern wurde auch eines ihrer Gründungsmitglieder und hatte damit die Möglichkeit, zusammen mit anderen CAD-Anbietern die Richtung der Entwicklung von Werkzeugen für die Arbeit mit offenen Daten zu bestimmen, die ADSK ursprünglich seit 1995 bekämpfte.

4. IFC-Integrationspreis für ADSK

ADSK zahlt jährlich zwischen 50.000 und 200.000 Euro an die ODA Alliance für den Zugang zum IFC-SDK. Paradoxerweise mietet ADSK im Wesentlichen die Unterstützung für ein Format, das es nach offiziellen Angaben “geschaffen” hat.

Dieses Problem bleibt auch anderen CAD-Anbietern nicht erspart: Die Zertifizierung und Entwicklung komplexer Module für die Konvertierung ihrer eigenen Parameter in Parameter des IFC-Formats erfordern erhebliche Ressourcen. Für viele CAD (BIM)-Unternehmen ist dieser Prozess wie eine freiwillige Teilnahme an einem Marathon mit Hindernissen, bei dem man bei jedem Schritt entscheiden muss, ob man in eine vollständige IFC-Unterstützung investiert oder nach Umgehungslösungen wie SVF, GLTF, DAE, JSON, CPIXML oder USD sucht, die in anderen gängigen Ökosystemen bereits weit verbreitet sind.

5. SVF/SVF ADSK und USD als Schritt zur Vereinfachung

Für seine eigenen Zwecke der plattformübergreifenden Interoperabilität verwendet ADSK seit 2013 aktiv das SVF/SVF2-Format — flach und für das Rendering optimiert — im Forge-Produkt. Dieses Format ist proprietär, ähnelt aber Open USD: Geometrie wird als “flache” Meshes gespeichert, und Eigenschaften werden in JSON gespeichert.

ADSK verwendet seinen eigenen flachen Standard, bei dem alle Projektinformationen sicher hinter einer mehrschichtigen API verschlossen sind, auf die nur diejenigen Zugriff haben, die für ein ACC-Abonnement bezahlt haben. In diesem Zusammenhang könnte das USD-Format, da es flach ist, ADSKs offenes Analogon zu seinem eigenen SVF-Format werden, so wie DXF eine offene Version des DWG-Formats geworden ist (DXF bewahrt die DWG-Primitive nicht vollständig).

6. USD wird aktiv in ADSK-Produkte implementiert

ADSK führt aktiv die USD-Unterstützung in seinen Produkten ab 2023 ein. Auf der AOUSD Alliance-Sitzung kündigte ADSK an, dass USD-Exporte bald in allen seinen Produkten verfügbar sein werden.

Eric Bourque, VP Content Creation, ADSK:

“Wir haben es in alle unsere Produkte eingebaut. Bei ADSK haben wir viel in USD investiert und behandeln es wie einen Standard, was es aber nicht ist. Diese neue Allianz mindert dieses Risiko und stellt sicher, dass sich die Dinge weiterhin wie erwartet verhalten. Sie hilft bei der Interoperabilität auf verschiedenen Plattformen und stellt die Datenkonsistenz sicher.”

Eric Bourques Worte über die Vorteile von USD in Bezug auf Universalität, Interoperabilität und Datenkonsistenz sind ein bemerkenswertes Echo auf dieselben Vorteile, die das IFC-Format de jure bietet und die ADSK 1994 de jure geschaffen hat. Warum also jetzt ein neues Format schaffen?

7. CAD-Anbieter verwenden IFC nicht für die Interoperabilität

Das Problem der Interoperabilität ist nach wie vor eines der Hauptprobleme für CAD-Anbieter. Seine Wurzeln reichen bis in die 1990er Jahre zurück, als viele Legacy-Produkte entwickelt wurden, die Unterstützung benötigen. So ist beispielsweise der Revit-Code teilweise immer noch in anderen Sprachen als dem von Reitz’ Team gesprochenen Englisch dokumentiert. Erschwerend kommt hinzu, dass die Unternehmen zu verschiedenen Zeiten unterschiedliche Produkte erworben haben, die auf verschiedenen Technologiestufen aufgebaut sind, was heute zu Schwierigkeiten bei der Gewährleistung ihrer Interaktion führt.

Die meisten großen CAD- und BIM-Softwareunternehmen bieten keinen direkten Zugriff auf ihre Anwendungsdaten. Unter den ADSK-Produkten bildet nur InfraWorks eine Ausnahme: Seine Projekte werden in einem offenen SQLite-Datenbankformat gespeichert, das es den Benutzern ermöglicht, direkt mit den Modelldaten zu arbeiten. Im Gegensatz dazu verwendet ADSK Revit ein geschlossenes Datenspeicherformat, das den direkten Zugriff auf die Modellinformationen einschränkt.

Statt eines offenen Zugriffs auf die Datenbank wird vorgeschlagen, mit vielen verschiedenen APIs zu arbeiten, um auf SQLite zuzugreifen. D.h. im einen Fall können wir mit der Datenbank des CAD-Programms durch SQL-Abfragen und Datenanalysen arbeiten, im anderen Fall benötigen wir Tausende von neuen API-Befehlen, die der Hersteller möglicherweise jedes Jahr ändert. Die Lösung für dieses Problem der Geschlossenheit wurden spezialisierte Datenkonverter und SDKs für das Reverse Engineering, deren Geschichte in dem Artikel “Der Kampf um offene Daten in der Bauindustrie” ausführlich beschrieben wird. Die Geschichte von AUTOLISP, intelliCAD, openDWG, ODA und openCASCADE”. Große Unternehmen, die mit CAD- und MCAD-Formaten arbeiten, müssen jährlich zwischen 40.000 und 200.000 Euro für den Zugang zu diesen Werkzeugen aufwenden.

Das Aufkommen des IFC-Formats in den späten 1990er Jahren, das DXF ablöste, lenkte die Aufmerksamkeit der Benutzer vorübergehend von dem Problem der Offenheit der Daten und der Notwendigkeit von SDKs zum Reverse-Engineering des DWG-Formats ab (solche Lösungen wurden damals bereits von MarComp, Vision und später openDWG angeboten). Im Laufe der Zeit warf die Komplexität des IFC-Formats jedoch viele Fragen auf, sowohl für die Entwickler von CAD-(BIM-)Anwendungen als auch für die Benutzer, die Probleme mit der Qualität des Exports und Imports von Daten aus geschlossenen CAD-Systemen hatten. Laut dem leitenden technischen Direktor von building-SMART könnten einige Probleme, insbesondere im Zusammenhang mit der Geometrieübertragung, durch die Verwendung einfacherer und flacherer alternativer Formen gelöst werden.

8. GLTF (~USD) in Zehn Prinzipien für eine zukünftige IFC

Bereits im Jahr 2020 schlug der CTO von building-SMART, Leon van Berlo, in dem Manifest “Ten Principles for a Future IFC” vor, das glTF-Format als Standard für die Darstellung von Geometrie im IFC-Format zu verwenden.

Die parametrische Geometrie ist eine Schwachstelle des IFC-Formats, da die Logik der Geometriekonstruktion zwischen verschiedenen Softwareprodukten verloren gehen kann, was durch die Verwendung der MESH-Geometrie in IFC umgangen wird. Zusammen mit der komplexen Klassifizierung bereitet dies sowohl den Entwicklern als auch den Anwendern, die versuchen, Daten aus IFC zu exportieren und zu importieren, Kopfschmerzen.

Das GLTF-Format soll nach Angaben des technischen Leiters von bS die mit dem Import und Export verschiedener parametrischer Geometrien verbundenen Probleme umgehen, indem es diese von einem komplexen parametrischen BREP in ein vereinfachtes MESH-Format umwandelt. Hinter der Entwicklung von GLTF steht die Khronos Group, ein einflussreicher Zusammenschluss fast aller großen Unternehmen der Welt (von Google und Nvidia bis hin zu IKEA und Samsung), die an 3D-Visualisierung interessiert sind. Das Format hat bereits breite Unterstützung von wichtigen Akteuren der 3D-Inhaltserstellungsbranche erhalten, darunter Unreal Engine, Blender und Unity. Die von Sun Microsystems und Intel gegründete Khronos Group ist einer der wichtigsten Partner der neuen AOUSD-Allianz, was die Kontinuität und Interkonnektivität der beiden Formate — GLTF und USD — unterstreicht.

9. Veraltete IFC-Struktur vs. vereinfachter USD

IFC (Industry Foundation Classes) ist der Nachfolger älterer Standards wie IGES und STEP, die ihren Ursprung in der Ära der Lochkarten und minimalen Computerressourcen in den 1970er Jahren haben. Die zeilenweise Struktur von IFC ist das Ergebnis seiner Ursprünge in STEP Part 21, das auf der Grundlage der IGES-Erfahrung entwickelt wurde. Obwohl diese Formate in den 1980er und 1990er Jahren hochmodern waren und sich gut für den Einsatz in CNC-Maschinen eigneten, wirkt ihre textuelle, zeilenweise Organisation heute archaisch und ist für die moderne digitale Datenverarbeitung und -analyse nicht wirklich geeignet.

Im Gegensatz dazu bieten flache Formate wie USD, GLTF eine einfache flache Objekthierarchiestruktur, die die Datenintegration vereinfacht und das Abrufen, Filtern, Gruppieren und Umwandeln von Daten beschleunigt (einer der wichtigsten Ansätze in der Datenverarbeitung ist ETL — Extrahieren, Transformieren, Laden). USD wurde ursprünglich entwickelt, um die Zusammenarbeit mehrerer Autoren zu ermöglichen und die Latenzzeit zu minimieren, wodurch es sich besser für moderne Prozesse eignet als das veraltete und komplexe IFC. Einen allgemeinen Vergleich nach für die Verarbeitung und Prozessautomatisierung wichtigen Parametern finden Sie in der Vergleichstabelle.

ETL, ELT, OLAP, die in allen anderen Wirtschaftszweigen der Bauwirtschaft eingesetzt werden, sind schwerfällige ERP-CAFM-Systeme, deren Entwickler ebenfalls nach Möglichkeiten suchen, die Phase der Informationsbeschaffung zu vereinfachen — Extract.

10. IFC-Autoren helfen bei der Entwicklung des deutschen USD — CPIXML

In den frühen 2000er Jahren stieß eines der größten europäischen Bauunternehmen, Züblin-Strabag, bei der Verwendung des IFC-Formats in ERP-CAFM-Systemen, insbesondere bei 4D-7D-Berechnungsprozessen, an seine Grenzen. Um dieses Problem zu lösen, holte das Unternehmen erfahrene Ingenieure ins Boot, darunter auch einen der Ingenieure, die in den frühen 1990er Jahren mit Leonard Obermeyer an der IFC-Registrierung gearbeitet hatten.

Das Ergebnis dieser Initiative ist CPIXML, ein neues Format, das speziell für die aktuellen Bedürfnisse von Bauunternehmen im deutschsprachigen Raum entwickelt wurde. Obwohl es sich bei CPIXML um ein proprietäres Format handelt, ist es offen zu lesen und weist bemerkenswerte Ähnlichkeiten mit dem kürzlich eingeführten USD-Format auf: Beide verwenden flache Daten zur Speicherung von Informationen über Geometrie und Elementeigenschaften. Der wichtigste technische Unterschied besteht darin, dass CPIXML zur Speicherung von Geometrie (OBJ) und Eigenschaften das XML-Format verwendet, während USD auf einer JSON-Struktur basiert. Nach dem Verkauf von ITWO — Schneider Electric investiert Züblin 2018 in die Entwicklung eines neuen Datenformats auf der Grundlage von OpenCascade — einem offenen Geometrie-Kernel, über den wir in den folgenden Abschnitten sprechen werden.

Eine vollständige Karte der Beziehungen zwischen CAD-MCAD-BOM-BIM-Werkzeugentwicklern seit 1980 finden Sie unter dem Link “BIM History Map”.

Als Abschweifung vom Thema und im Zusammenhang mit der Entstehungsgeschichte des IFC-Formats möchte ich mich an die Nemetschek AG mit dem Vorschlag wenden, eine wichtige historische Klärung in der offiziellen building-SMART-Chronologie zu initiieren. Es geht um die Anerkennung der Schlüsselrolle eines der führenden Ingenieure Münchens, Leonard Obermeyer, einem Kollegen und Freund von Herrn Nemetschek, bei der Schaffung des IFC-Formats.

11. Anstelle von IFC verwendet Mitteleuropa CPIXML, ein USD-ähnliches Format für 4D-7D

IFC wurde in Deutschland erfunden und entwickelt (TU München und Büro Obermeyer), aber die meisten großen Unternehmen im deutschsprachigen Raum verwenden für ihre 4D-7D-Prozesse das flache CPIXML-Format (OBJXML). ZÜBLIN, STRABAG, HOCHTIEF, Bilfinger, Buro Happold, Implenia, Peter Gross Bau, Deutsche Bahn, Firmengruppe Max Bögl, WOLFF & MÜLLER, Drees & Sommer, ZECH Bau, Kohlbecker Gesamtplan GmbH, Arcadis, Deutsche Telekom, Die Autobahn GmbH des Bundes. Fast alle großen Unternehmen im deutschsprachigen Raum nutzen die ERP-Systeme ITWO und MTWO, die Anfang der 2000er Jahre in Stuttgart von Züblin und RIB Software entwickelt wurden. Der Erfolg dieser Plattformen ist vor allem auf das ausgedehnte globale Netzwerk von Joint Ventures und die strategische Partnerschaft mit Microsoft zurückzuführen. Im Jahr 2021 erwarb der internationale Konzern Schneider Electric RIB Software zusammen mit dem CPIXML-Format und dem darauf basierenden ERP für 1,5 Milliarden Euro

Trotz der Tatsache, dass große deutsche Unternehmen zunehmend vereinfachte Formate für ihre spezifischen 4D-7D-Aufgaben bevorzugen, wird die Entwicklung des IFC-Formats dank einer aktiven Gemeinschaft von openBIM-Entwicklern, die das IFC-Format als Hauptformat in ihren Tools verwenden, fortgesetzt. Das OPENBIM-Marketingkonzept wurde 2012 von CAD-Anbietern entwickelt und als Marke geschützt. Später wurden die Markenrechte an building-SMART übertragen, das auch die Marke registrierte und das openBIM-Logo aktualisierte.

12. Blender und UE implementieren aktiv USD-Unterstützung

BlenderBIM (Bonsai) ist einer der Hauptanwärter für das erste native Produkt, in dem IFCs erstellt und bearbeitet werden können. Aber auch hier gilt: Statt mit parametrischen IFC in BlenderBIM zu arbeiten, das einen nicht nativen OpenCascade-Geometriekern verwendet, können die Nutzer bald direkt in Blender mit USD arbeiten — das möglicherweise bald aus CAD-Produkten ausgelagert wird. Das Blender-Team arbeitet aktiv an der Integration von USD, was die Hemmschwelle für Nutzer offener und kostenloser Werkzeuge in Zukunft senken könnte. Neben Blender kann das USD-Format auch in Unreal Engine und Unity verwendet werden, die zunehmend die Herzen von Architekten und CAFM-Fachleuten in der Baubranche erobern.

FreeCAD, IfcOpenShell und fast alle anderen IFC-Bibliotheken wie BlenderBIM verwenden OpenCascade — den einzigen freien Geometrie-Kernel, der in Nizhny Novgorod entwickelt wird. OCCT (Open CASCADE Technology) ist ein Werkzeug, das bei der Arbeit mit Objektgeometrie hilft. Es kann Daten aus Dateien verschiedener Formate lesen, z.B. STEP, OBJ, DWG, und sie dann in ein anderes Format, z.B. IFC, konvertieren. OCCT selbst arbeitet nur mit der Geometrie, d.h. mit der Form und den Abmessungen von Objekten. Wie andere openBIM-Plattformen nutzt IfcOpenShell OpenCascade, um mit IFC zu arbeiten (es fungiert als Wrapper und arbeitet mit Daten über Objekttypen oder deren Beziehungen), beteiligt sich aber nicht an der Entwicklung des Geometriekerns selbst und hat keinen Einfluss auf die Entwicklung und Lizenzierung von OpenCascade.

Infolgedessen stoßen die Benutzer bei der Arbeit mit dem IFC-Format auf gewisse Schwierigkeiten, insbesondere was die Qualität des Datenexports und -imports betrifft. Diese Schwierigkeiten veranlassen die Suche nach alternativen Lösungen. Infolgedessen richten die Entwickler ihr Augenmerk auf das USD-Format, das sich durch eine einfachere und flachere Struktur auszeichnet. Es wird von verschiedenen Partnerallianzen gefördert, was zu seiner wachsenden Beliebtheit in der Branche beiträgt.

13. HOK und ARUP beginnen mit der Förderung der USD-Agenda in building-SMART

Ende August 2024 veranstaltete Trimble in seinen Geschäftsräumen in Westminster die building-SMART Developers General Assembly. Im Mittelpunkt der Veranstaltung stand die Diskussion über die Vorteile von USD im Zusammenhang mit offenen Standards und deren Potenzial zur Verbesserung des Datenaustauschs in der Baubranche.

Die größten Beratungs- und Planungsunternehmen, HOK und ARUP, haben sich aktiv an der Diskussion über die Vorteile von USD für einen verbesserten Datenaustausch beteiligt und damit begonnen, dessen Einführung in der Branche aktiv zu fördern:

In diesen Beiträgen werden die Vorteile des USD-Formats gegenüber IFC erörtert, darunter die verbesserte Unterstützung komplexer Animationen, die flexiblere Integration von 3D-Modellen und die effiziente Datenverwaltung im Bauwesen und in der Architektur.

14. USD erscheint in den IFC5-Entwicklungsdokumenten

Bereits einen Monat nach der Generalversammlung 2024 bei Trimble, im September, veröffentlicht der building-SMART CTO das Dokument Examples_FAQ auf GitHub im IFC5-Development Repository als vorläufiges Material und Entwicklungsrichtung für IFC Version 5.

In dem Papier werden Beispiele und Hauptmerkmale des neuen Standards beschrieben, wobei der Schwerpunkt auf der Umsetzung von openUSD-Konzepten und einer Verlagerung von der traditionellen STEP-Syntax zu moderneren und besser lesbaren Formaten wie JSON liegt, das in USD verwendet wird.

IFC, IFC5 oder USD

USD und IFC können eher als “Cousins” denn als Konkurrenten bezeichnet werden, da beide Formate ähnliche Herausforderungen bei der Datenorganisation und der Zusammenarbeit bei großen Projekten angehen, allerdings aus unterschiedlichen Blickwinkeln. USD konzentriert sich auf eine effiziente Visualisierung und die Kombination von Modellen aus verschiedenen Quellen, während IFC sich durch seine Stärke bei der semantischen Beschreibung von Bauobjekten auszeichnet. Theoretisch sind sie daher eher komplementär als austauschbar. Es ist möglich, dass building-SMART in naher Zukunft damit beginnt, den grafischen Teil von USD im IFC5-Format zu übernehmen, was CAD-Unternehmen später einen reibungslosen Übergang zur vollständigen Unterstützung des USD-Datenexports in ihren Produkten ermöglichen wird.

Es ist schwer vorstellbar, dass die CAD-Anbieter zwei vollwertige Datenexportformate unterstützen und eine Art “Frankenstein” aus einer Mischung von Formaten schaffen werden. Höchstwahrscheinlich werden Anbieter und Anwender früher oder später gezwungen sein, eine Entscheidung zu treffen: entweder vollständig auf den USD-Export umzusteigen oder IFC zu verwenden und dabei notwendige Elemente von USD zu übernehmen.

Derzeit ist ADSK gezwungen, Drittentwickler zu gewinnen, um ein Modul für den Export in das IFC-Format zu erstellen. Es ist bemerkenswert, dass diese Entwickler in den letzten 15 Jahren die Hauptkonkurrenten von ADSK in Fragen der offenen Daten waren und ADSK viele Probleme bereitet haben, indem sie die wichtigsten Formate des Unternehmens geöffnet haben. Daher ist es sehr wahrscheinlich, dass ADSK dazu übergehen wird, Daten aus Revit direkt in das USD-Format zu exportieren, ohne SDKs von Drittanbietern zu verwenden, da dieses Format bereits in vielerlei Hinsicht dem eigenen flachen MESH-Format SFV/SVF2 ähnelt, das im ADSK-Ökosystem verwendet wird.

Bild 15: AOUSD Podiumsdiskussion — Open Source Days 2023

Die Unterstützung des IFC-Formats in der Bauindustrie wird oft mit einem einfachen Argument begründet: “IFC wird von der Industrie benötigt, also sollte es auch unterstützt werden”. Die Situation ist jedoch komplizierter: IFC ist kein natives Format für moderne CAD-Programme, und die Qualität seines Exports und Imports hängt nicht so sehr von den tatsächlichen Bedürfnissen der Industrie ab, sondern von der Bereitschaft der Entwickler von CAD-Systemen, diese Unterstützung bereitzustellen. Es ist bezeichnend, dass die meisten Entwickler, einschließlich des Branchenführers ADSK, sich an die Open Design Alliance wenden, um ein “hochwertiges” IFC-SDK und Tools für die Interoperabilität zwischen verschiedenen Plattformen zu erhalten.

Dies wirft eine berechtigte Frage auf: Wie notwendig sind die von den CAD-Anbietern angebotenen Formate, wenn dieselben SDKs und Reverse-Engineering-Methoden verwendet werden können, um beliebige CAD-Daten in das für einen bestimmten Fall am besten geeignete Format zu konvertieren — sei es SQLite, XML, JSON, Parquet oder sogar XLSX? Dieser Ansatz bietet mehr Flexibilität und Komfort als die ausschließliche Verwendung von USD oder IFC, die Informationen über Projektelemente mit ihren eigenen Besonderheiten speichern.

Die derzeitige Situation bei den Formaten in der Baubranche gleicht einer Seifenoper, in der ein führender CAD-Anbieter über seine Vertreter in verschiedenen Allianzen ein neues Format bewirbt und es als offenes Format positioniert, obwohl dies in erster Linie im Interesse des Anbieters selbst liegt. Anstatt den Anwendern vollen Zugang zur Projektdatenbank zu gewähren (was in Infraworks oder CAD Exchanger und ODA-Lösungen bereits realisiert ist), wird nur ein begrenzter Datensatz angeboten. Gleichzeitig ist selbst für den Zugriff auf diese reduzierten Informationen durch den anbietergesteuerten Export ein obligatorisches Abonnement für die Dienste des Unternehmens erforderlich.

Globaler Wandel, Transformation und Paradigmenwechsel?

Die globalen Veränderungen im Format und im Umgang mit Daten hängen wahrscheinlich mit den langfristigen strategischen Interessen der Anbieter zusammen. Die IFC-Unterstützung ist für sie weniger attraktiv, da ihr Hauptaugenmerk darauf liegt, die Nutzer in ihrem eigenen Ökosystem zu halten. IFC hingegen ist nicht an eine bestimmte Plattform gebunden und verfügt nicht über ein eigenes natives Produkt mit einem eigenen geometrischen Kern, der vollständig mit diesem Format arbeiten kann.

Das Hauptproblem bei IFC ist das Fehlen eines eigenen nativen Geometrie-Kernelprodukts, das vollständig mit diesem Format arbeiten kann. Bestehende Open-Source-Projekte wie BlenderBIM und IfcOpenShell und viele andere im openBIM-Ökosystem hängen von dem einzigen freien Open-Source-Kernel OpenCascade ab, der in einem der BRICS-Länder entwickelt wird. Sie haben keinen Einfluss auf dessen Entwicklung oder Lizenzbedingungen.

In diesem Zusammenhang wird deutlich, dass es für eine echte Unabhängigkeit im openBIM-Ökosystem notwendig ist, einen eigenen Geometrie-Kernel zu entwickeln, der speziell für die Arbeit mit dem IFC-Format optimiert ist. Dies würde die Abhängigkeit von bestehenden kommerziellen Lösungen verringern und ein nachhaltigeres Ökosystem offener Werkzeuge schaffen. Ob dies jedoch notwendig sein wird, wenn CAD-Anbieter einen neuen Entwicklungsvektor wählen können, bleibt eine Frage.

Aufgrund von Qualitätsproblemen, der Komplexität und der Abhängigkeit des IFC-Formats von verschiedenen angeschlossenen Organisationen bleiben die Finanzierung und das Interesse an seiner Entwicklung begrenzt. Andererseits bietet die Zusammenarbeit mit Technologieführern bei der Entwicklung des USD-Formats, wie NVIDIA und Apple, CAD-Anbietern die Möglichkeit, neue Plattformen mit potenziell großen Aussichten für die Monetarisierung der Nutzung von Designdaten zu schaffen.

Der Mythos der Interoperabilität

In der Baubranche gibt es derzeit ein interessantes Phänomen. Viele Entwicklungsteams konzentrieren ihre Bemühungen darauf, Brücken zwischen ClosedBIM- und OpenBIM-Lösungen zu bauen, in dem Glauben, dass dies der universelle Schlüssel zur Lösung von Datenaustauschproblemen im Bauwesen ist.

Aber es genügt, sich an die Ereignisse von vor zwanzig Jahren zu erinnern, als Entwickler, die der Dominanz von Adobe auf dem Markt der Grafikeditoren überdrüssig waren, versuchten, eine nahtlose Integration zwischen Photoshop und GIMP herzustellen. Dieses historische Beispiel kann uns

Damals wie heute konzentrierten sich die Bemühungen auf die Schaffung von Verbindungen zwischen geschlossenen und offenen Systemen, um die Interoperabilität zwischen proprietären und quelloffenen Softwarelösungen zu ermöglichen. Die Nutzer suchten jedoch eigentlich nach einfachen Lösungen — flache, offene Daten ohne die unnötige Komplexität von Schichten und Programmparametern. Sie wollten einfach nur die flachen Daten, die sie brauchten und die sie ohne zusätzliche Anpassungen verwenden konnten.

Infolgedessen verwendet fast niemand in der Bildbearbeitungsbranche geschlossene Formate wie PSD oder das offene XCF für Anwendungen, soziale Medien wie Facebook und Instagram oder als Inhalt auf Websites. Stattdessen verwenden die meisten die flachen und offenen Formate JPEG, PNG und GIF aus Gründen der Benutzerfreundlichkeit und breiten Kompatibilität.

In der Bauindustrie spielen heute die Formate USD, OBJ, glTF und DAE bei der 3D-Modellierung die gleiche Rolle wie flache Bilder in der Grafik. Diese Formate vereinfachen und beschleunigen die Arbeit, indem sie Kompatibilitätsprobleme außer Kraft setzen. Die beliebten vereinfachten Formate NWC, SVF und CP2 erfüllen ähnliche Funktionen, sind aber im Gegensatz zu den oben genannten offenen Standards geschlossen.

Die Anbieter folgen dem historischen Trend in anderen Branchen: Die meisten Nutzer brauchen keine geschlossenen Formate wie PSD oder komplexe GIMP-Dateien mit Ebenenlogik. Sie brauchen einfache Objektbilder, die in Instagram (CAFM), Facebook (ERP) und tausenden anderen Prozessen mit Excel-Tabellen und PDF-Dokumenten verwendet werden können. Ähnlich im Bauwesen: die geschlossene Logik von Revit oder die komplexen parametrischen Dateien von IFC sind oft überflüssig. Die Anwender suchen nach vereinfachten und flachen Formaten wie USD, CPIXML, DXF, DXF, glTF, SQL, DAE und XLSX, die alle notwendigen Elementinformationen enthalten, aber nicht durch redundante BREP-Geometrielogik und interne Klassifizierungen spezifischer CAD- und BIM-Produkte belastet sind.

Die Situation bei den Datenformaten in der CAD-Branche nähert sich ihrem Ende. Autodsddesk, der führende Entwickler in der Branche, scheint bereits eine Entscheidung zugunsten von USD und der AOUSD-Allianz getroffen zu haben. Die Einfachheit und Vielseitigkeit von USD scheint im Vergleich zur komplexen parametrischen Struktur von IFC attraktiver zu sein.

Die Debatte über Datenformate verliert jedoch die Hauptfrage aus den Augen: Welchen Wert haben diese Dutzende von verschiedenen Formaten, die dieselben Informationen in unterschiedlicher Form enthalten, und wozu dienen sie wirklich?

Granulare Daten, Analytik, maschinelles Lernen und große Sprachmodelle

Die Arbeit mit Daten im Bauwesen beinhaltet die Interaktion mit einer großen Menge von Informationen aus verschiedenen Quellen, die früher oder später miteinander integriert werden müssen.

In der heutigen Planungs- und Bauwelt führt die Komplexität des Datenzugriffs zu einem übertechnisierten Projektmanagement. Mittlere bis große Unternehmen auf dem BIM-Markt sind entweder gezwungen, enge Beziehungen zu CAD-Anbietern zu unterhalten, um über APIs und Produkte wie Forge und ACC auf Daten zuzugreifen, oder die Beschränkungen der CAD-Anbieter zu umgehen, indem sie teure SDK-Konverter für das Reverse Engineering offener Daten verwenden.

Mit dem Zugang zu offenen Daten kann jeder Fachmann in der Baubranche, der LLM und Python in wenigen Tagen beherrscht, zu alternativen Werkzeugen für quantitative Berechnungen (QTO), Datenvalidierung, Dokumentenerstellung, Tabellenkalkulationen und Dashboards übergehen und sich von den traditionellen CAD-Lösungen (BIM) entfernen. Die CAD-Anbieter versuchen, den nahtlosen Übergang zu offenen Daten und Datenanalysen zu verzögern, indem sie neue Formate, Konzepte und Allianzen schaffen.

Die Gründung der AOUSD-Allianz im Jahr 2023 markiert einen wichtigen Wendepunkt für die Bauindustrie. Wir erleben die Entstehung einer neuen Realität im Umgang mit Baudaten durch mehrere bedeutende Veränderungen. Die erste große Veränderung betrifft die Wahrnehmung von CAD-Daten. Die Marktteilnehmer beginnen zu begreifen, dass die Bauplanung nur der Anfang der Reise ist. Die in CAD-Systemen erstellten Daten werden zur Grundlage für eine eingehende Analyse und den anschließenden Betrieb von Anlagen.

Gleichzeitig gibt es eine Revolution in der Vorgehensweise der führenden Entwickler. ADSK, einer der Branchenführer, vollzieht eine unerwartete Wende in seiner Strategie. Das Unternehmen wendet sich von der traditionellen Speicherung von Daten in separaten Dateien ab, konzentriert sich auf die Arbeit mit normalisierten und strukturierten Daten und geht zu einem datenzentrierten Ansatz über.

Nicht weniger wichtig ist die Aktivierung von Cloud-Giganten. Amazon und Huawei haben das Marktpotenzial erkannt und beschleunigen die Entwicklung von Speziallösungen. Ihr Ziel ist es, Marktplatz-Tools für die effiziente Normalisierung und Strukturierung von Bauprojekten zu schaffen, die in ihren Cloud-Systemen gespeichert sind und von verschiedenen CAD-Plattformen stammen.

Bis 2025 werden sich die Veränderungen in der Datenverarbeitung voraussichtlich erheblich beschleunigen. Nach Angaben des CEO von Nvidia werden bereits jetzt 30 % der Rechenressourcen für die Verarbeitung strukturierter Daten — Datenrahmen — verwendet. Meta bereitet die Einführung eines neuen LLaMa-Modells vor, dessen wichtigstes Anwendungsszenario die Arbeit mit normalisierten spaltenförmigen Informationen ist. Die Popularität von Datenanalysetools wie Pandas nimmt weiterhin rapide zu und erreicht 10 Millionen Downloads pro Tag.

All diese Trends markieren den Beginn einer neuen Ära, in der die Arbeit mit Daten zur Grundlage der beruflichen Tätigkeit wird. Die Branche bereitet sich auf eine neue Ära vor — die Ära der Datenanalytik im Bauwesen. Das manuelle Verschieben von Daten zwischen Tabellenkalkulationen gehört der Vergangenheit an und macht Platz für Automatisierung, Datenflussanalyse, Analytik und maschinelles Lernen, die zu wichtigen Entscheidungshilfen werden.

Sie haben die Wahl: Passen Sie sich an diese neue Realität an oder bleiben Sie in einer Welt veralteter Konzepte und geschlossener Ökosysteme.

Mit den geschlossenen Formaten von Revit und anderen CAD/BIM-Systemen geschah das Gleiche wie mit DWG vor 20 Jahren. Reverse-Engineering-SDKs und Konverter haben diese Formate sowohl für Entwickler als auch für Anwender zugänglich gemacht. Fast alle großen CAD-, MCAD- und Bauunternehmen geben zwischen 10.000 und 200.000 Euro pro Jahr aus, um über Konverter auf Daten zuzugreifen, und keines der weltweit führenden Unternehmen arbeitet mit Daten über APIs, Plugins oder von CAD-Anbietern angebotene Formate — sei es IFC oder USD.

Alte Lösungen und geschlossene Plattformen mit API-Dokumentation gehören der Vergangenheit an. Das De-facto-Marketingkonzept von BIM ist die Umsetzung von Kundenanforderungen in die Realität durch die “Magie” von Metriken und Datenanalysen. Wenn Sie sich noch nicht mit dem Thema Analytik beschäftigt haben, ist es jetzt an der Zeit, dies zu tun. Warten Sie nicht darauf, dass Anbieter ein neues Format, einen neuen Schulungskurs, ein neues Zertifikat oder ein neues Konzept zur Datenanalyse einführen. Fangen Sie noch heute an, mit Daten und Datenanalyse zu arbeiten — das ist der Schlüssel zur Zukunft des Baugewerbes und nicht nur des Baugewerbes. Alle Werkzeuge, die von Experten in anderen Branchen verwendet werden, sind kostenlos und offen und stehen Ihnen bereits zur Verfügung, wenn Sie offene Daten erhalten können.

Die Daten, die heute in der Baubranche entstehen, werden in Zukunft eine wichtige Ressource für Geschäftsentscheidungen sein. Sie werden als strategischer “Treibstoff” dienen, der die Entwicklung und Effizienz von Bauunternehmen vorantreibt.

Schlussfolgerung

Die Zukunft des Baugewerbes liegt in der Fähigkeit, mit Daten zu arbeiten, nicht in der Wahl des Formats. Ergebnisse für 2024:

Datenformate wie RVT, IFC, PLN, DB1, CP2, CPIXML, USD, SQLite, XLSX, PARQUET und andere enthalten die gleichen Informationen über Projektelemente. Dies bedeutet, dass die Kenntnis eines bestimmten Formats kein Hindernis mehr für die Arbeit mit Daten darstellt.
Die Daten aus diesen Formaten werden in einer offenen granularen Struktur kombiniert, die MESH-Geometrie und Objekteigenschaften enthält.
Datenanalyse ist der Schlüssel zur Vielseitigkeit: Mit offenen Daten können Sie lernen, wie man mit Projektdaten (ETL, ELT, OLP, DWH, DLA) arbeitet, unabhängig vom verwendeten Format. Dies ist nicht nur eine nützliche Fähigkeit, sondern Ihr Zugang zur Zukunft von Design und Konstruktion.
Goodbye APIs: Die Arbeit mit Daten hängt nicht mehr von API-Kenntnissen ab. Lernen Sie, wie man mit offenen Daten arbeitet und beginnen Sie noch heute mit dem Sammeln von Daten!

Entwickler und Nutzer stehen vor einer strategischen Entscheidung, die die Zukunft der Branche für die nächsten Jahre bestimmen könnte. Die Schaffung einer Hybridlösung, die die Formate IFC und USD kombiniert, scheint unwahrscheinlich — eine solche künstliche Kombination wäre zu komplex und ineffizient. Stattdessen wird die Branche eine klare Entscheidung treffen müssen: entweder die vollständige Umstellung auf ein modernes USD-Format oder die Modernisierung des bewährten IFC unter Einbeziehung der besten Elemente des USD. Diese Entscheidung wird einer der Schlüsselfaktoren sein, die die Richtung der gesamten Bauindustrie bestimmen.

Die aktuellen Trends in der Baubranche werden möglicherweise die Voraussetzungen für eine allmähliche Abkehr vom veralteten IFC-Format zugunsten des vielseitigeren USD schaffen. Dies spiegelt die Strategie großer Marktteilnehmer wie ADSK, Trimble und Hexagon wider, die bereits versuchen, ihren Einfluss über die AOUSD-Allianz zu konsolidieren. Historische Marktführer wie HOK, die einst zusammen mit ADSK und der IAI-building-SMART-Allianz IFC aktiv förderten, werben nun offen für USD und betonen dessen Einfachheit und Vielseitigkeit. Die massenhafte Einführung von USD in Produkten, die GLTF-Kompatibilität und die aktive Integration in Tools wie Blender und Unreal Engine zeigen das Potenzial für den Beginn eines neuen Paradigmas für die Arbeit mit Daten. Zusammen mit der Popularität von lokalisierten Lösungen wie dem europäischen flachen USD — CPIXML, das in ITWO/MTWO verwendet wird, kann die Position von USD in Mitteleuropa potenziell gestärkt werden.

Vor diesem Hintergrund hat der USD das Potenzial, zum De-facto-Standard zu werden, und verspricht, viele derzeitige Beschränkungen zu überwinden. Und building-SMART ist bereits dabei, seine Strategie an USD anzupassen, was die Unvermeidbarkeit des Wandels nur bestätigt. USD gewinnt aufgrund seiner Einfachheit, Flexibilität und Unterstützung für große Technologieallianzen in der Bauindustrie rasch an Boden. Hinter der Fassade der “offenen Daten” kann sich jedoch die Absicht der Marktführer verbergen, das Projektdatenmanagement zu monopolisieren. Die Nutzer finden sich in einer Situation wieder, in der die Wahl des Formats mehr mit Unternehmensinteressen als mit tatsächlichen Bedürfnissen zu tun hat.

Die Ära des Wandels im Baugewerbe scheint auf den ersten Blick ein technologischer Durchbruch in Form eines Übergangs vom veralteten IFC zum moderneren USD zu sein. Im Moment geht es bei diesem Wandel jedoch eher darum, dass sich große Unternehmen um das Datenmanagement streiten. Die Analyse von 14 Schlüsselfakten zeigt, dass das Hauptziel dieser Veränderungen nicht nur die Benutzerfreundlichkeit ist, sondern auch die Beibehaltung der Kontrolle über Ökosysteme und Datenflüsse.

Die wichtigste Erkenntnis: Die Zukunft liegt in offenen, flachen, einheitlichen Daten, die für Analysen zur Verfügung stehen. Um jedoch nicht zum Spielball der großen Anbieter zu werden, sollten Bau- und Ingenieurbüros heute auf echte Offenheit und Unabhängigkeit setzen.

📯 Ich wäre Ihnen dankbar, wenn Sie diese Informationen unterstützen und weiterverbreiten würden. Offene Daten und Formate werden unweigerlich zu einem Standard in der Bauindustrie werden — es ist nur eine Frage der Zeit. Dieser Übergang wird beschleunigt, wenn wir alle offene Formate, Datenbankzugriffstools und SDKs für Reverse Engineering bekannt machen. Jeder Einzelne von Ihnen kann bei diesem Prozess helfen. Wenn Sie die Informationen, die Sie lesen, nützlich finden, geben Sie sie bitte an Ihre Kollegen weiter.

🔗 LinkedIn: Das Zeitalter des Wandels: IFC ist ein Ding der Vergangenheit oder warum ADSK und andere CAD-Anbieter bereit sind, IFC für USD aufzugeben — 14 Fakten

👋 Liebe Leserinnen und Leser, ich würde mich sehr über Ihre Kommentare und Meinungen freuen! Wenn irgendwelche Fakten für Sie Fragen aufwerfen oder Sie Ihre eigene Meinung zu den angesprochenen Themen mitteilen möchten, lassen Sie uns darüber diskutieren. Ihre Sichtweise, jede Bemerkung und Beobachtung ist wichtig für die Diskussion. Ich freue mich darauf, den Dialog mit jedem von Ihnen fortzusetzen.

Abonnieren Sie den Newsletter

This document discusses general topics in the field of construction and data processes, referencing historical and current industry practices. All trademarks and registered trademarks are the property of their respective owners, and this text is not affiliated with or endorsed by any trademark holders. The content herein is provided for informational purposes and does not constitute legal or technical advice.

Trademark Disclaimer:

All product names, logos, and brands mentioned in this document are the property of their respective owners. Use of these names, logos, or brands does not imply endorsement.

2. Non-Infringement Statement:

This document is intended for informational purposes only. The content presented does not aim to infringe upon or claim ownership of any proprietary trademarks, patents, or intellectual property.

3. Fair Use Notice:

This material is provided under the principles of fair use for educational, research, and informational purposes. The content is based on publicly available information and does not claim to represent or replicate proprietary knowledge.

4. Copyright Acknowledgment:

Certain sections of this document reference third-party materials and are duly credited. If there are any copyright concerns, please contact us to address them appropriately.

5. Attribution Statement:

Specific frameworks, formats, or tools mentioned are attributed to their respective authors or organizations. Their inclusion is intended for analysis and commentary.