El mundo post-BIM. Pasando a los datos y los procesos, ¿necesita el sector de la construcción semántica, formatos e interoperabilidad?
7 January 2025
🚀 New Version of Free offline Revit® 2015-2024 Converter is Out!
16 January 2025
Mit dem Aufkommen digitaler Daten in den 1990er Jahren begann sich die Baubranche aktiv zu verändern. Computertechnologie wurde in die Entwurfs-, Verwaltungs- und Bauprozesse eingeführt, was zur Entstehung von Konzepten wie CAD (Computer-Aided Design-Systeme), PLM (Product Lifecycle Management) und später BIM (Building Information Modeling) führte.
Wie jede Innovation sind sie jedoch nicht das Ende der Entwicklung. Konzepte wie BIM sind zu einem wichtigen Meilenstein in der Geschichte der Bauindustrie geworden, aber früher oder später werden sie besseren Werkzeugen und Ansätzen weichen, die den Herausforderungen der Zukunft besser gerecht werden.
Das 2002 aufgekommene BIM-Konzept ist vom Einfluss der CAD-Anbieter überwältigt und durch die Komplexität seiner eigenen Implementierung verwirrt. Es wird seinen dreißigsten Geburtstag wahrscheinlich nicht erleben – wie ein Rockstar, der hell aufleuchtete, aber schnell verblasste. Der Grund ist einfach: Die Anforderungen an Datenspezialisten ändern sich schneller, als CAD-Anbieter sich ihnen anpassen können.
Angesichts des Mangels an qualitativ hochwertigen Daten fordern Fachleute in der Baubranche heute plattformübergreifende Interoperabilität und Zugriff auf offene Daten zur einfacheren Analyse und Verarbeitung. Der Mangel an Daten und ihre Komplexität wirken sich negativ auf alle am Bauprozess Beteiligten aus: Designer, Projektmanager, Bauarbeiter vor Ort und letztendlich den Kunden.
Statt eines vollständigen Datensatzes für den Betrieb erhalten Kunde und Investor heute Container in Formaten, die komplexe geometrische Kernel, ein Verständnis von Datenschemata, jährlich aktualisierte API-Dokumentation und spezielle CAD-BIM-Software zur Arbeit mit den Daten erfordern. Gleichzeitig bleiben viele der Entwurfsdaten ungenutzt.
Dieser Ansatz ist veraltet und wird den Anforderungen der heutigen digitalen Umgebung nicht mehr gerecht. Die Unternehmen der Zukunft werden sich in zwei Typen spalten: diejenigen, die Daten effektiv nutzen, und diejenigen, die den Markt verlassen.
In diesem Artikel werden wir uns sowohl mit dem bestehenden BIM-Framework, einschließlich der Verwendung der Formate CAD (BIM), IFC und USD, als auch mit alternativen und zukünftigen Ansätzen für die Arbeit mit Daten und Prozessen befassen und wichtige Fragen beantworten, die für Datenexperten in der Baubranche heute von Interesse sind:
- Was ist BIM – Marketing oder echte Innovation für die Baubranche
- Warum CAD-Formate die Interoperabilität und das BIM-Konzept zerstören
- USD vs. IFC: Warum zwingen Anbieter neue Formate auf?
- Warum die neuen Formate der CAD-Anbieter IFC und USD zentrale Interoperabilitätsprobleme nicht lösen
- Warum verzichten CAD-Anbieter ab 2023 auf Dateien und wechseln zu granularen Daten?
- Warum parametrische CAD-Formate und BREP-Geometrie für die Bauindustrie nicht zwingend erforderlich sind
- Wie Strabag und Züblin CAD-Anbieter herausforderten und was dabei herauskam
- Warum der Einsatz von Semantik und Ontologien im Datenmanagement zu kurz greift.
- Warum Bauunternehmen sich gegen die Nutzung offener Daten wehren werden
- Und was sind die Werkzeuge der Zukunft für den Umgang mit Bauprojektdaten
Vielen Dank für die wertvollen Diskussionen und Debatten zu den Themen, die vonRasso Steinmann, Thomas Liebich, Ulf-Günter Krause, Bernd Müller-Jürries, Simon Dihlas, Michael Maass, liebe Mitglieder von BuildingSMART, dieOSArch-Gemeinschaftund dieDataDrivenConstruction-ChatGruppe.
Inhalt:
- Bei BIM geht es um Daten und Prozesse, aber warum dann das Akronym?
- Jeder CAD (BIM) Datennutzer bedient zehn Datenkonsumenten
- Jedes CAD (BIM)-Programm ist ein Datencompiler, der Geometrie durch einen Geometriekernel visualisiert
- CAD, IFC und Geometriekerne: Wer trägt die Verantwortung?
- IFC ist CAD innerhalb von CAD mit einer Abhängigkeit vom Geometriekernel und dem SDK
- Warum brauchen Bauherren Geometrie? Wenn Linien zu Geld werden
- Grundrechnungen im Bauwesen oder von Linien zu Volumen: Wie aus Flächen und Volumen Zahlen werden
- Warum brauchen wir Dreiecke? Die ganze Wahrheit über Tessellation im Bauwesen
- Der Versuch von Zublin-Strabag, CAD-Anbieter (BIM) den Interessen der Bauindustrie unterzuordnen
- Die Entstehung von Semantik und Ontologie in der Bauindustrie
- Semantik und Ontologie: Wie bringt man Daten zum Sprechen?
- Von Diagrammen zu Tabellen: Arbeitsaufwand beim Gruppieren und Filtern
- Im Schatten von ISO und buildingSMART: der Krieg um die Kontrolle des Datenformats
- Warum brauchen Bauherren und Kunden eine Datenkontrolle?
- Uberisierung und Open Data sind eine Bedrohung für die Baubranche
- Gibt es BIM, openBIM, BIM Level 3 und noBIM tatsächlich oder handelt es sich dabei nur um Marketing-Gimmicks?
- Was kommt als Nächstes? Einfache Formate und benutzerfreundliche Tools
- Aufkommen von LLM und ChatGPT in Projektdatenprozessen Abschließend
1. Bei BIM geht es um Daten und Prozesse, aber warum dann das Akronym?
Das Konzept von BIM (Building Information Modeling), das in der Bauindustrie mit der Veröffentlichung von ADSKs BIM wiederbelebt wurdeWhitepaperim Jahr 2002 und ergänzt durch das Maschinenbaukonzept BOM (Bills of Materials), entstand aus dem parametrischen Ansatz zur Erstellung und Verarbeitung von Projektdaten. Der parametrische Ansatz zur Erstellung und Verarbeitung von Konstruktionsdaten wurde erstmals im Pro/Engineer-System für Maschinenbaukonstruktionen (MCAD) implementiert. DiesSystem wurde zum Prototypfür viele moderne CAD-Lösungen, einschließlich derjenigen, die heute in der Bauindustrie verwendet werden.
Abb. 1 Geschichte der Entstehung von Revit, Solidworks, Autocad und Whitepaper zu BIM-Produkten
Zitat vonSamuel Geisberg, Gründer von PTC, Entwickler des MCAD-Produkts Pro/ENGINEER und Mentor von Leonid Reitz, dem Erfinder von Revit:
Das Ziel ist, ein System zu schaffen, das flexibel genug ist, um den Ingenieur zu ermutigen, problemlos verschiedene Designs in Betracht zu ziehen. Und die Kosten für Designänderungen sollten so nahe wie möglich bei null liegen. Herkömmliche CAD/CAM-Software der damaligen Zeit beschränkte kostengünstige Änderungen unrealistischerweise nur auf die allererste Phase des Designprozesses.
Bereits Ende der 1980er Jahre bestand das Ziel darin,Beseitigung der Einschränkungen derals vorhandene CAD-Programme. Das Hauptziel bestand darin, den Arbeitsaufwand für Änderungen an den Parametern der Konstruktionselemente zu reduzieren und die Aktualisierung des Modells auf der Grundlage von Daten außerhalb der CAD-Programme zu ermöglichen. In diesem Fall sollte die Parametrisierung der Aufgabe und die automatische Eingabe von Parametern aus der Datenbank zur Aktualisierung des Modells im CAD-System die Schlüsselrolle spielen.
Nachdem ADSK den Kauf von Revit (mit dem alten Stücklistenkonzept von Pro/ENGINEER) abgeschlossen hatte, bereiteten die beiden Vizepräsidenten von ADSK eineWhitepaperdas kennzeichnete 2002 die Einführung des BIM-Konzepts in der Bauindustrie.
Abbildung 2. Erscheinen des BIM-Whitepapers im Jahr 2002
Auf einer Website mit einem veröffentlichten WhitePaper zum Thema BIMADSK reproduzierte tatsächlich die Marketingmaterialien des BOM-Konzepts (Bills of Materials) aus den Pro/ENGINEER-Produktengebrauchtin den frühen 1990er Jahren.
BIM steht für Building Information Management, bei dem alle Aktualisierungen und Änderungen in einer Datenbank erfolgen. Egal, ob Sie mit Schemata, Schnitten oder Planzeichnungen arbeiten, alles ist immer aufeinander abgestimmt, konsistent und auf dem neuesten Stand.
Fast alle modernen Konzepte zur Parametereingabe und -verarbeitung im Bauwesen, wie IFC, BIM, openBIM undGebäudeSmart, wurden bei der Erstellung unterstützt und werden von CAD-Lösungsanbietern gefördert. Viele dieser Ideen werden jedoch aus anderen Branchen übernommen oder von Startups übernommen. Beispielsweise hat ADSK Revit, das BIM-Konzept, AutoCAD Architecture, Navisworks, Civil 3D und Advanced Steel nicht selbst entwickelt, sondern diese Lösungen von Startups übernommen.
Ähnlich,GebäudeSmarthat weder das IFC-Format noch das Akronym openBIM® geschaffen. IFC wurdeadaptiert von der Technischen Universität Münchenaus dem Maschinenbauformat STEP, später umbenanntvonHOK zur Gründung der IAI Alliance, während openBIM nurgebrandet vonGebäudeSmartals Marke Anfang der 2020er Jahre nach der Erstregistrierungvonmehrere CAD-Anbieter im Jahr 2012. Das IFC-STEP-Format wiederum basiert auf IGES, das 1979 von einer Gruppe von CAD-Anwendern und -Anbietern mit Unterstützung von NIST und dem US-Verteidigungsministerium entwickelt wurde. Die Verbindungen zwischen den Entwicklern und den Ideen moderner Konzepte werden indie Karte „Geschichte von BIM“.
Abbildung 3. Karte der Verbindungen der wichtigsten Teams von CAD (BIM)-Lösungsentwicklern
Der Maschinenbau, aus dem die Kernwerkzeuge und -konzepte stammen, bewegt sich allmählich weg von der Arbeit mit CAD-, CAM- und PLM-Begriffen hin zu digitalen Zwillingen und End-to-End-Datenmanagementprozessen. Design-, Fertigungs- und Betriebsprozesse werden nicht durch die Linse spezifischer Werkzeuge (von Unternehmen wie PTC, Siemens und Dassault Systemes) betrachtet, sondern durch einheitliche Ansätze für Daten und Prozesse. Anstelle von Fachbegriffen wie BOM, PLM oder PDM werden die Konzepte Datenmanagement, Prozessmanagement undDatenanalysewird zunehmend verwendet. Nicht nur im Maschinenbau und anderen Branchen ist dieser Übergang von engen Abkürzungen der Softwareanbieter zu universellen Konzepten, die von „Daten“ und „Prozessen“ geleitet werden, zu beobachten.
Benutzer und Entwickler in der Baubranche werden sich, wie auch ihre Kollegen in anderen Branchen, zwangsläufig von der vagen Terminologie der Softwareanbieter verabschieden, die die letzten 20 Jahre dominiert hat, und sich auf die Schlüsselaspekte der Digitalisierung konzentrieren – „Daten“ und „Prozesse“.
Abbildung 4. Bauprozesse und Design sind untrennbar mit Daten und Prozessen verbunden
Ohne freien Zugang zu hochwertigen strukturierten Daten wird es in Zukunft unmöglich sein, effiziente Prozesse aufzubauen und zu automatisieren. Daher wird die Entdeckung, Organisation, Vereinheitlichung und Organisation von Daten oberste Priorität haben, die die Grundlage für die Automatisierung und Optimierung von Geschäftsprozessen bilden.
Um die Komplexität und Verwirrung des aktuellen CAD-BIM-Konzepts für Daten- und Prozessmanagement zu verstehen, werden wir uns die Grundlagen der Erstellung der Geometrie und der Metainformationen ansehen, die in Entwurfsdaten enthalten sind. Dadurch wird die Frage beantwortet, warum die Verwendung, Automatisierung und Standardisierung von Entwurfsdaten in den letzten 30 Jahren eine Herausforderung geblieben ist.
2. Jeder CAD (BIM)-Datennutzer bedient zehn Datenkonsumenten
Während vor Anfang der 2000er Jahre der Anteil digital gespeicherter Daten äußerst gering war und die Frage der Verwendung dieser Daten in anderen Systemen praktisch nicht aufgeworfen wurde, hat sich die Situation heute dank der Einführung von CAD (BIM), PLM, ERP, Excel und SQL-basierten Anwendungen dramatisch verändert. Die Anzahl der Systeme, die Daten verbrauchen, hat sich verzehnfacht, was für Manager und Spezialisten, die Daten empfangen, verarbeiten und übertragen müssen, eine echte Krise darstellt.
Abbildung 5. Daten- und Prozessintegrationsschema im Ökosystem des Bauunternehmens
Seit Anfang der 2000er Jahre ist die Zahl der Büroangestellten, die mit der Wartung verschiedener Benutzeroberflächensysteme und Datenbanken befasst sind, exponentiell gestiegen, was zu einem dramatischen Anstieg der Bedeutung des Datenzugriffs und der gemeinsamen Nutzung von Daten geführt hat. Als CEO von ADSKbereits 2002 festgestellt, auf jeden CAD-Ingenieur kamen bereits Anfang der 2000er Jahre mindestens ein Dutzend andere Spezialisten, die mit in CAD-Systemen erstellten Daten arbeiten mussten (Zitat):
Sie müssen in der Lage sein, all diese Daten (CAD – Anm. d. Autors) zu verwalten, sie digital zu speichern und Software für das Lebenszyklus- und Prozessmanagement zu verkaufen, denn auf jeden Ingenieur, der etwas herstellt, kommen zehn Leute, die mit den Daten arbeiten müssen.
Bis Anfang der 2020er Jahre ist die Zahl der Fachleute, die mit Daten aus CAD- und BIM-Programmen arbeiten, exponentiell gewachsen und hat Hunderte von Fachleuten in großen Unternehmen erreicht – von GIS-, ERP- und CAFM-Systemmanagern bis hin zu Bauleitern.
Abbildung 6. Dutzende Spezialisten pro Ingenieur erstellen Daten in CAD-Programmen (BIM)
Alle diese Benutzer und ihre Datenmanager in der Baubranche streben nach vollständiger Kompatibilität zwischen verschiedenen Programmen und Plattformen und insbesondere Datenbanken und Datenformaten. Und während fast alle Systeme und Datenbanken in der Baubranche für Ingenieure und IT-Experten offen sind, bleiben nur CAD (BIM) geschlossene Datenbanken mit proprietären Formaten. Diese geschlossenen Außenposten für Projektinformationen haben in den letzten 30 Jahren Dutzende anderer Abteilungen und Hunderte von Fachleuten beeinflusst und eine Abhängigkeit von eingeschränktem Informationszugriff geschaffen.
Bei Fragen der echten plattformübergreifenden und Interoperabilität stehen die grundsätzlichen Probleme der geschlossenen Natur von CAD-Programmen und der komplexen proprietären Geometrie-Kernel, SDK-Tools von Drittanbietern und verschiedenen Datenschemata, die sie in proprietären Formaten verwenden, im Vordergrund..
Abbildung 7. Von allen Datenbanken ist nur der CAD-Zugriff (BIM) nicht verfügbar
Warum brauchen wir CAD-Systeme (BIM) im Bauwesen? Ihre Hauptaufgabe besteht darin, dem Designer zu helfen, neue Daten basierend auf den Anfangsparametern der Aufgaben im Projekt zu erstellen, die sowohl die Geometrie der Entwurfselemente als auch zugehörige Metainformationen umfassen.Definition aus Wikipedia:
Building Information Modeling (BIM) ist eine Methode zum Erstellen und Verwalten digitaler Darstellungen der physischen und funktionalen Eigenschaften von Gebäuden und anderen Objekten.
Die meisten CAD-Systeme (BIM) verwenden geschlossene Datenbanken und proprietäre Speicherformate, um diese Funktionen und Parameter zu erstellen und zu speichern. Darüber hinaus verwenden sie anspruchsvolle proprietäre Geometriekernel, die eine Visualisierung und interaktive Interaktion mit der Projektgeometrie ermöglichen.
3. Jedes CAD (BIM)-Programm ist ein Datencompiler, der Geometrie durch einen Geometriekernel visualisiert
Jedes CAD (BIM)-Programm verwendet entweder einen eigenen Geometriekernel oder greift auf eine proprietäre Lösung eines Drittanbieters zurück, was den Datenaustausch zwischen verschiedenen Plattformen erheblich erschwert.
Jedes CAD (BIM)-Programm ist ein Compiler von Geometriedaten, die mithilfe eines Geometriekernels angezeigt werden.
Der Markt wird von Geometriekernen wie Siemens Parasolid, Dassault Systèmes CGM, PTC ProEngineer, ADSK ShapeManager und ASCON C3D dominiert. Die einzigen kostenlosen Open-Source-Geometriekerne sind OpenCascade und die OCGL-Bibliothek unter der GPL-Lizenz.
Abbildung 8. Architektur des CAD/BIM-System-Workflows: von der Codebasis bis zur Visualisierung
Bei einfachen geometrischen Elementen wie Linien oder Ebenen gibt es keine Probleme beim Zeichnen von Geometrie anhand von Parametern. Bei der Arbeit mit komplexen oder zusammengesetzten Elementen ändert sich die Situation jedoch. Selbst bei denselben Eingabeparametern können unterschiedliche geometrische Kernel aufgrund der Besonderheiten ihrer Funktionsweise und Verarbeitungsalgorithmen unterschiedliche Ergebnisse liefern. Infolgedessen werden die als parametrische Geometrie gespeicherten geometrischen Elemente des Projekts in verschiedenen CAD-Produkten (BIM) unterschiedlich angezeigt.
Abbildung 9. Unterschiedliche parametrische Eingabemodelle liefern unterschiedliche Ergebnisse, wenn unterschiedliche geometrische Kernel verwendet werden.
Die vollständige plattformübergreifende Kompatibilität auf der Ebene der parametrischen Geometrie bleibt für die meisten CAD-Anbieter unerreichbar. Dies liegt an der fehlenden Standardisierung der in den Geometriekernen von Systemen verwendeten Algorithmen, die häufig nicht im Besitz von CAD-Anbietern (und mehr MCAD-Anbietern) sind, sowie an der Notwendigkeit, offene Austauschspezifikationen zu erstellen und universelle Konverter zu entwickeln. Derzeit befassen sich nur eine Handvoll Initiativen, darunter OpenCascade, Open Design Alliance und CADExchanger, mit solchen Herausforderungen. In der Vergangenheit kamen Initiativen zur Konvertierung und Vereinheitlichung von Multiformatdatenunter enormem Druckvon CAD-Anbietern. Viele dieser Konflikte endeten jedoch inRechtsstreitmit Entscheidungen nicht zugunsten der Anbieter.
Lassen Sie uns verstehen, warum wir einen geometrischen Kernel bei der Datenverarbeitung benötigen, der so komplex ist, dass selbst Entwickler von CAD-Systemen (BIM) sich für Lösungen und Entwicklung an Drittanbieter und Entwickler wenden müssen.
4. CAD, IFC und Geometriekerne: Wer ist verantwortlich?
Der Geometriekern ist für die Visualisierung und Verarbeitung von Geometrie erforderlich. Eine der gängigsten Methoden zur Geometriedarstellung in CAD-Systemen (BIM) ist die Boundary Representation (BREP oder B-rep).
BREP (Boundary Representation) ist eine Möglichkeit, die Geometrie eines Objekts durch Randparameter zu beschreiben: Oberflächen, Kanten und Eckpunkte.
Andere Formen der Geometriedarstellung, wie CSG und Swept Solids, werden im IFC-Format und in internen Containern von CAD-Programmen verwendet, die bei bestimmten Aufgaben Anwendung finden. Aufgrund seiner Vielseitigkeit ist BREP jedoch die führende Form der Geometriedarstellung und hat sich zum Standard für die meisten technischen und architektonischen Lösungen im CAD-Umfeld (BIM) entwickelt.
In jedem CAD-Programm werden Benutzeraktionen wie Mausklicks in der Programmoberfläche zum Auswählen von Punkten oder Linien mithilfe eines geometrischen (mathematischen) Kernels in BREP umgewandelt und als fertige Form im Programmfenster angezeigt.
Da jedoch jeder CAD-Anbieter seinen eigenen Geometriekernel mit einer einzigartigen Codebasis verwendet, die oft aus mehreren zehn Millionen Zeilen besteht, garantiert die Übertragung von BREP-Parametern zwischen Programmen nicht ihre identische Darstellung in einem anderen CAD-System.
Abbildung 10. Entstehung aus der BREP-Parameteranalyse unter Verwendung des geometrischen Kernels der Elementform
BREP (Boundary Representation) im IFC-Format ist kein grundlegendes Format, da es parametrisch beschrieben wird, ohne einen bestimmten oder vorhandenen geometrischen Kernel dafür zu verwenden. Dies führt dazu, dass dasselbe parametrische IFC-Modell in verschiedenen Softwareprodukten, die unterschiedliche geometrische Kernel verwenden, wie OpenCascade, Shape Manager und Siemens Polarsolid, die in CAD-Programmen (BIM) verwendet werden, unterschiedlich interpretiert werden kann.
Ein Schlüsselelement bei der Schaffung echter plattformübergreifender Interoperabilität könnte möglicherweise die utopische Idee sein, einen universellen geometrischen Kern zu schaffen, an den die Parametrik der Elemente gebunden werden kann. Dies würde eine korrekte Interpretation derselben Geometrie in jedem CAD-System (BIM) gewährleisten.
Daher entwederGebäudeSmartsollte einen eigenen freien und offenen geometrischen Kern haben, sonst wird das gleiche BREP-Element aus dem IFC-Format in verschiedenen Tools und Programmen weiterhin unterschiedlich dargestellt.
IFC selbst kann als eine Art CAD innerhalb von CAD oder als Grundgerüst für ein computergestütztes Designsystem angesehen werden, das in 30 Jahren nicht offiziell für IFC erschienen ist.
5. IFC ist CAD innerhalb von CAD mit Abhängigkeit von Geometriekernel und SDKs
Das IFC-Format verwendet unterschiedliche Möglichkeiten zur Darstellung der Geometrie, z. B. CSG und Swept Solids. BREP hat sich jedoch auch zum führenden Standard für die Übertragung von Feature-Geometrie im IFC-Format entwickelt, da dieses Format beim Export aus CAD-Programmen (BIM) unterstützt wird und eine potenzielle (nur in experimentellen Produkten implementierte) Bearbeitung von Features beim Rückimport von IFC in CAD-Programme ermöglicht.
Wenn die Geometrie in IFC parametrisch definiert ist (BREP), ist es in den meisten Fällen nicht möglich, Eigenschaften wie Volumen oder Fläche von Projekteinheiten nur mit einer IFC-Datei zu ermitteln, da man in diesem Fall zum Arbeiten mit der Geometrie und ihrer Visualisierung einen Geometriekernel benötigt, der zunächst nicht vorhanden ist.
Um IFC in einem beliebigen Programm zu unterstützen, ist es eigentlich notwendig, innerhalb der vorhandenen Lösung ein weiteres ideales IFC-CAD mit einem eigenen Geometriekern und einer eigenen Logik für die Arbeit mit Geometrie zu erstellen.
Abbildung 11. Ist es möglich, die von CAD-Anbietern verwendeten Geometrie-Kernel und SDKs zu standardisieren?
Und obwohl es im IFC-BREP-Format möglicherweise keine Probleme mit primitiven Elementen gibt, gibt es neben Problemen mit verschiedenen geometrischen Kernel-Engines genügend Elemente, die ihre eigenen Besonderheiten für eine korrekte Zuordnung aufweisen. Dieses Problem wird ausführlich im internationalen „Referenzstudie zur IFC-Softwareunterstützung” veröffentlicht 2019. Zitat:
Dieselben standardisierten Datensätze führen zu inkonsistenten Ergebnissen, es sind nur wenige gemeinsame Muster erkennbar und es gibt ernsthafte Probleme bei der Unterstützung des Standards (IFC – Anmerkung des Autors), wahrscheinlich aufgrund der sehr hohen Komplexität des Standarddatenmodells. Die Standards selbst sind hier teilweise schuld, da sie oft einige Details undefiniert lassen, mit hohen Freiheitsgraden und verschiedenen möglichen Interpretationen. Sie ermöglichen eine hohe Komplexität bei der Organisation und Speicherung von Objekten, was einem effektiven universellen Verständnis, eindeutigen Implementierungen und konsistenter Datenmodellierung nicht förderlich ist.
Das richtige Verständnis von „bestimmten Bestimmungen“ steht bezahlten Mitgliedern vonGebäudeSmartund oft in Diskussionen hinter den Kulissen. Wer daher an wichtiges Wissen über bestimmte Features von IFC gelangen möchte, wird versuchen, mit großen Unternehmen zusammenzuarbeiten oder es durch eigene Recherchen zu erreichen.Aus einem Interview mit dem Entwickler desCAD-ProgrammRenga:
Sie stoßen auf eine Frage zum Importieren und Exportieren von Daten über das IFC-Format und fragen Ihre Kollegen: „Warum werden die Informationen zur parametrischen Übertragung von Räumlichkeiten auf diese Weise in die IFC-Datei übertragen? Die offene Spezifikation vonGebäudeSmartsagt nichts darüber“. Antwort von „kundigeren“ europäischen Verkäufern: „Ja, es wird nicht gesagt, aber es ist erlaubt.“
Abb. 10: Das gleiche IFC-Projekt in verschiedenen CAD (BIM)-Programmen liefert unterschiedliche Ergebnisse
Alle Funktionen der IFC-Parameterzuordnung und -generierung im Geometriekernel können nur von großen Entwicklungsteams realisiert werden. Daher ist die aktuelle Praxis der Funktionen und Komplexität des IFC-Formats in erster Linie für CAD-Anbieter von Vorteil und hat viel mit Microsofts „Adopt, Extend, Destroy“-Strategie gemeinsam, bei der die zunehmende Komplexität des Standards tatsächlich Barrieren für kleinere Marktteilnehmer schafft. Microsofts Strategie bestand darin, offene Standards anzupassen, eigene Erweiterungen und Funktionen hinzuzufügen, um Benutzerabhängigkeit von seinen Produkten zu schaffen und dann Konkurrenten zu verdrängen. Microsoft hat lange Zeit seine eigenen Standards durchgesetzt (z. B. Internet Explorer), was die Einführung fortschrittlicherer und universellerer Technologien wie CSS, HTML5 oder unabhängiger Browser verlangsamte.
Infolgedessen können heute nur große CAD-Anbieter, die erhebliche Ressourcen in die Unterstützung aller Entitäten und deren Zuordnung zu ihrem internen Geometriekern investieren können, die IFC-Ontologie vollständig implementieren. Große Anbieter haben auch die Möglichkeit, technische Details von Funktionen untereinander zu harmonisieren, die möglicherweise selbst dem aktivsten Teilnehmer nicht zur Verfügung stehen.GebäudeSmart.
Erfahren Sie mehr über die Herausforderungen für Entwicklungsteams, die mit IFC-Formaten arbeiten, in derReferenzstudie zur IFC-Softwareunterstützung
Abb. 12: Internationale Studie zur Plattformtauglichkeit des IFC-Formats
Für kleine unabhängige Teams und Open-Source-Projekte, die die Entwicklung interoperabler Formate unterstützen möchten, wird das Fehlen eines eigenen Geometriekernels zu einem ernsthaften Problem. Ohne ihn ist es praktisch unmöglich, all die vielen Feinheiten und Nuancen zu berücksichtigen, die mit dem plattformübergreifenden Datenaustausch verbunden sind.
Derzeit ist OpenCascade der einzige weit verbreitete Open-Source-Kern, der beliebten OpenBIM-Tools zugrunde liegt – wie IfcOpenShell, BlenderBIM-Bonsai, IFC.js und FreeCAD. Allerdings hat auch dieser seine Grenzen. DerGebäudeSmartDie Organisation verfügt über keine direkten Instrumente, um die Entwicklung und Lizenzierung von OpenCascade (OCC) zu beeinflussen. Historisch gesehen war das OCC-Entwicklungsteam in Nischni Nowgorod angesiedelt, doch in den letzten Jahren sind einige OCC-Spezialisten nach Portugal gezogen, und der größere und verbleibende Teil des Teams hat sich auf die Entwicklung eines Zweigs des OpenCascade (OCC)-Projekts unter der Marke des neuen chinesischen Open-Source-Projekts konzentriert.Geometrie-Kernel OGG.
Und warum brauchen wir im Bauwesen überhaupt mühsam erarbeitete Geometrie, und brauchen wir sie in parametrischer Form?
6. Warum brauchen Bauherren Geometrie? Wenn Linien zu Geld werden
Die Geometrie ergänzt zusätzlich zur Visualisierung vorhandene Elementparameterlisten um wichtige volumetrische Eigenschaften wie Fläche und Volumen, die automatisch auf Grundlage der Form des Projektobjekts berechnet werden. Diese Parameter spielen eine entscheidende Rolle, da sie als Grundlage für nachfolgende Berechnungen, Berechnungen und Analysen dienen.
Die automatische Berechnung der Geometrie wird zum Bindeglied zwischen abstrakten Daten in Form von Problemparametern und deren physikalischer Realisierung.
Die Geometrie bildet seit jeher die Grundlage der technischen Kommunikation und ermöglicht die Berechnung von Längen, Flächen und Volumina. Von den frühesten Papyruszeichnungen bis hin zu modernen digitalen Formaten dienten Zeichnungen schon immer als wichtiges Instrument zur Übermittlung von Informationen über Materialmengen und Arbeitsaufwand zwischen Ingenieuren, Vorarbeitern und Kostenschätzern. Über Jahrtausende hinweg, bis in die 1980er Jahre, erfassten Kostenschätzer Mengen- und Volumendaten manuell und ausschließlich auf der Grundlage visueller Darstellungen, wobei sie Lineale und Winkelmesser als primäre Messwerkzeuge verwendeten.
Abbildung 13: Die Hauptzwecke geometrischer Daten in Baugeschäftsprozessen
Mit dem Aufkommen von Computern wird die manuelle und zeitaufwändige Aufgabe der Berechnung volumetrischer Eigenschaften nun durch die vollständige Automatisierung gelöst, dank der Einführung der volumetrischen Modellierung in modernen CAD-Tools (BIM). Dadurch können Sie automatisch die volumetrischen Attribute jedes Elements ermitteln, ohne diese Werte manuell mit einem Taschenrechner berechnen zu müssen.
Bei der Arbeit in CAD-Programmen erfolgt die Erstellung geometrischer Elemente für Berechnungen über die Benutzeroberfläche von CAD-BIM-Programmen. Um Punkte und Linien in volumetrische Körper umzuwandeln, wird ein geometrischer Kernel verwendet. Der geometrische Kernel führt die Hauptaufgabe aus – die Umwandlung der Geometrie in volumetrische Modelle, aus denen nach der Annäherung die Volumina des Elements automatisch berechnet werden.
Abb. 14: Pfad der Visualisierung geometrischer Formen außerhalb von CAD-Systemen (BIM)
So wie vor Tausenden von Jahren beim Bau der Pyramiden die Maße Ellenbogen und Ellen verwendet wurden, so spielt auch heute in CAD-Programmen die Genauigkeit der Geometrieinterpretation eine Schlüsselrolle: Die Genauigkeit der Projektbudgetberechnungen, die korrekte Bestimmung der Kosten und der Zeitpunkt der Arbeiten, die jedes Bauprojekt ausmachen, hängen davon ab.
Genaue Kalkulationen sind ein entscheidender Faktor für das Überleben in der Baubranche. In einem hart umkämpften Umfeld ist der Zugriff auf qualitativ hochwertige Volumendaten für die erfolgreiche Projektumsetzung und den Erhalt der Wettbewerbsfähigkeit von entscheidender Bedeutung.
Wenn genaue Berechnungen bei der Bestimmung der Ressourcen-, Material- und Zeitparameter eines Projekts eine Schlüsselrolle spielen, ist es wichtig, genau zu verstehen, wie diese Berechnungen durchgeführt werden.
7. Grundlagen des Rechnens im Bauwesen oder von Linien zu Volumen: Wie aus Flächen und Volumen Zahlen werden
In der Praxis wird die Triangulation häufig verwendet, um Flächen und Volumina geometrischer Oberflächen zu berechnen, die analytisch oder über NURBS in BREP definiert sind, wobei komplexe Oberflächen in ein Raster aus Dreiecken umgewandelt werden.
NURBS (Non-Uniform Rational B-Splines) ist eine mathematische Methode zur Beschreibung von Kurven und Oberflächen, während BREP eine Struktur zur Beschreibung der vollständigen dreidimensionalen Geometrie eines Objekts einschließlich seiner Grenzen ist, die mit NURBS definiert werden können.
Auch wenn die Oberfläche analytisch oder über NURBS gegeben ist, wird sie meist durch Tessellation angenähert, da exakte Berechnungen über Integrale oder komplexe analytische Methoden aufgrund ihrer Komplexität und des hohen Rechenaufwands in der Praxis selten realisiert werden können.
Das Wesen der Tessellation besteht darin, komplexe Oberflächen in einfachere Elemente – Dreiecke oder Polygone – zu zerlegen. Dieser Ansatz wird für Oberflächen- und Volumenberechnungen, Bildschirmvisualisierungen, den Export in Formate wie MESH („Mesh“) sowie Kollisions- und Kollisionsanalysesysteme verwendet. In Spielen wird Tessellation verwendet, um realistische Landschaften zu erstellen, und in CAD/CAE-Systemen für Berechnungen und Visualisierungen. Bienenwaben sind ein Beispiel für Tessellation in der Natur.
Abbildung 15: BREP und polygonale Darstellung der Kugel
BREP (NURBS), das in CAD (einschließlich BIM-Systemen) verwendet wird, ist kein grundlegendes Geometriemodell. Diese Methode wurde als praktisches Werkzeug zur Darstellung von Kreisen und rationalen Splines entwickelt. Sie weist jedoch Einschränkungen auf – beispielsweise die Unfähigkeit, die Sinuskurve, die spiralförmigen Linien und Oberflächen zugrunde liegt, genau zu beschreiben. Daher bleibt BREP (NURBS) nur eine Näherungsmethode, aber kein grundlegendes Mittel zur Beschreibung von Geometrie.
Im Gegensatz dazu zeichnen sich Dreiecksnetze und parametrische Tessellation durch ihre Einfachheit, effiziente Speichernutzung und die Fähigkeit zur Verarbeitung großer Datenmengen aus. Diese Vorteile ermöglichen es, bei der Berechnung geometrischer Formen auf komplexe und teure Geometriekerne und Hunderte Millionen Zeilen Code zu verzichten.
Abbildung 16. Beispiele für Zylinder- und Würfel-Tesselation
In der Bauindustrie spielt es keine Rolle, wie die volumetrischen Eigenschaften bestimmt werden – durch parametrische Modelle in internen CAD- oder IFC-Formaten oder durch die Verwendung vereinfachter geometrischer Darstellungen in den Formaten USD, glTF, DAE oder OBJ.
Geometrie, die als Polygone oder BREPs (NURBS) definiert ist, ist eine Möglichkeit, eine kontinuierliche Form anzunähern. So wie Fresnel-Integrale keinen exakten analytischen Ausdruck haben, ist die Diskretisierung von Geometrie durch Polygone oder NURBS immer eine Annäherung, genau wie bei dreieckigem MESH.
Sowohl polygonales MESH als auch parametrisches BREP haben ihre Vorteile und Nachteile, aber das Ziel ist dasselbe – die Geometrie effizient und bequem zu beschreiben und dabei die Aufgaben des Benutzers zu berücksichtigen. Letztendlich hängt die Genauigkeit des geometrischen Modells nicht nur von der Methode seiner Darstellung ab, sondern auch von den Anforderungen einer bestimmten Aufgabe.
Abb. 17: Unterschied der volumetrischen Eigenschaften von Figuren mit unterschiedlicher Polygonanzahl
Parametrische Geometrie im BREP-Format ist vor allem dann erforderlich, wenn eine minimale Datengröße wichtig ist und für die Verarbeitung und Anzeige ressourcenintensive und teure Geometriekernel verwendet werden können. Am häufigsten ist dies charakteristisch für CAD-Programme, die zu diesem Zweck Geometriekernel von MCAD-Anbietern verwenden.
In den meisten Konstruktionsanwendungen besteht selten Bedarf an parametrischer Geometrie und komplexen Geometriekerneln, es sei denn, ihre Bedeutung wird von den CAD-Anbietern selbst oder von den Anbietern von Geometriekerneln, die diese Tools entwickeln, betont.
Daher wird parametrische Geometrie (BREP, RVT, IFC, PLN) in CAD-Programmen (BIM) immer noch durch den Tessellationsprozess in MESH-Dreiecke und -Polygone für Berechnungen umgewandelt. Außerhalb der CAD-Umgebung (BIM) wird in den meisten Fällen auch triangulierte MESH-Geometrie (USD, SVF, glTF, CPIXML, DAE, NWC) zur Visualisierung, Berechnung und Kollisionssuche verwendet, wodurch die Notwendigkeit parametrischer Geometrie noch weniger offensichtlich wird.
Welches Format sollte also als Standard für den Datenaustausch gewählt werden und ist IFC das geeignete Format für den Austausch – dreieckiges IFC-MESH (gLTF, OBJ, DAE, SVF) oder parametrisches IFC-BREP (RVT, PLN, DGN)?
8. Warum brauchen wir Dreiecke? Verwendung von Tessellation im Bauwesen
Ein bestimmtes CAD-Programm (BIM) sollte nicht die Grundlage des Austauschformats sein, das sowohl in den Kostenabteilungen als auch auf der Baustelle verwendet werden soll. Geometrische Informationen sollten direkt im Format dargestellt werden, ohne Bezug auf einen geometrischen Kern oder eine CAD-Architektur.
In der Bauindustrie sollte in Systemen und Datenbanken, die Konstruktionsdaten verwenden, die Abhängigkeit vom CAD-Editor und Geometriekernel minimiert werden.
Geometrieparametriken aus CAD-Programmen können Teil des Prozesses sein, allerdings nur als Eingabedaten, nicht als Grundlage für ein Austauschformat. Nur so kann die Universalität und Unabhängigkeit der Geometriebeschreibungen gewährleistet werden. Die meisten parametrischen Geometrien, einschließlich BREP und NURBS, werden zur Berechnung und Visualisierung in ein dreieckiges Netz umgewandelt (Tessellation). Nach der Tessellation erhalten Sie immer noch ein dreieckiges MESH. Wenn Sie am Ende den Unterschied nicht sehen können, warum den Prozess dann verkomplizieren?
Parametrische Formate sind nicht grundlegend, und umgekehrt bleiben Formate wie OBJ, STL, gLTF, SVF, CPIXML, USD und DAE grundlegend, da sie die einfache und universelle Triangle MESH-Struktur verwenden. Sie ist in der Computergrafikarchitektur verständlich und effizient und erfordert keine zusätzlichen Geometriekernel mit zig Millionen Codezeilen für die Visualisierung oder Elementberechnungen.
Abb. 18: Übergang der Geometrie vom parametrischen Format zur polygonalen Darstellung
Aufgrund von Problemen mit der IFC-Interpretation und geometrischen Kernel-Unterschieden verwenden ausnahmslos alle CAD-Anbieter Reverse Engineering SDKs, um Daten zwischen Lösungen verschiedener Anbieter zu übertragen undniemand benutztkomplexes IFC- oder USD-Format für Interoperabilitätszwecke.
Das MESH-USD-Format, das ab 2023 von CAD-Anbietern in der neuen AOUSD-Allianz angeboten wird, die im Artikel der letzten Woche besprochen wurde (Eine Ära des Wandels: IFC gehört der Vergangenheit an oder warum ADSK und andere CAD-Anbieter bereit sind, IFC für USD aufzugeben, in 14 Schlüsselfakten), hat das Potenzial, der neue Standard für den Ersatz parametrischer Geometrie in proprietären Formaten zu werden. Es kann auch als Mittel zur Beschreibung von BREP-Geometrie in IFC dienen, was den CAD-Anbietern selbst bisher nicht gelungen ist.
Doch statt Konzepte von Allianzen aus CAD-Anbietern zu verwenden, die diese selbst nicht nutzen, ist es produktiver, sich auf das Verständnis der Vorteile der einzelnen Ansätze in einem bestimmten Kontext zu konzentrieren und je nach Anwendungsfall den einen oder anderen Geometrietyp auszuwählen.
Die Wahl zwischen verschiedenen geometrischen Darstellungen ist ein Kompromiss zwischen Genauigkeit, Rechenleistung und den praktischen Anforderungen eines bestimmten Problems.
Abbildung 19: Tessellierte BREP-Kugel mit unterschiedlicher Polygonanzahl
Die Komplexität und Verwendung geometrischer Kernel, die CAD-Anbieter der Bauindustrie bei der Verarbeitung von Entwurfsdaten auferlegen, ist möglicherweise gar nicht notwendig. Das USD-Format mit MESH-Geometrie könnte für die Branche eine Büchse der Pandora sein und Designern alternative Ansätze für den IFC- und BREP-Datenaustausch eröffnen. Es hat sich herausgestellt, dass es andere, einfachere und offenere Formate gibt, die eine qualitativ hochwertige Interaktion zwischen CAD-Ingenieuren (BIM) und Dutzenden anderer Spezialisten ermöglichen können.
Eines der beliebtesten ERP-Systeme für die Baubranche – ITWO/MTWO – ist ein aktuelles Beispiel für eine solch effektive Anwendung der MESH-Geometrie in den Geschäftsprozessen von Bauunternehmen. Dieses Produkt des deutsch-französischen Verbunds von Schneider Electric und RIB Software demonstrierte bereits Mitte der 2000er Jahre die Verwendung des MESH-Formats mit einem vereinfachten Speicherschema für Metainformationen. Anstelle der Formate IFC und USD verwendet ITWO/MTWO das proprietäre, aber lesbare CPIXML-Format.
Hinter der Entwicklung des ERP-Systems iTWO/MTWO steht der Baukonzern Strabag, genauer gesagt dessen Tochterunternehmen Züblin aus Stuttgart. Züblin war der Initiator der Entwicklung von iTWO, das damals nicht nur als ERP-System, sondern als internationale Plattform für 4D-5D BIM – die Integration von Entwurfsdaten mit Zeitplänen und Kostenvoranschlägen – positioniert war.
9. Der Versuch von Zublin-Strabag, CAD-Anbieter (BIM) den Interessen der Bauindustrie unterzuordnen
Züblin-Strabag ist eines der größten Bauunternehmen Europas mit umfassendem Know-how in allen Phasen des Bauprozesses. Der Umsatz der STRABAG SEerreichte 17,67Milliarden Euro im Jahr 2023. Zum Vergleich: Die gesamte globale Marktgröße der CAD-Softwareunternehmen, einschließlich ADSKwurde geschätztbeium18,54 Milliarden US-Dollar im Jahr 2021.
Den Entwicklern von Zublin (Strabag) und RIB Software in Stuttgart gelang es, Plug-in-Konverter für grundlegende CAD-Programme zu erstellen, die geometrische Daten aufnehmen und im OBJ-Format CPIXML (ähnlich USD) tesselieren. Infolgedessen ermöglichten solche triangulierten Geometrien die Berechnung von mehr als 150 verschiedenen volumetrischen Eigenschaften auf der Grundlage primitiver MESH-OBJ-Geometrien über die CAD-Programme (BIM) hinaus in einem tabellarischen ERP, zusätzlich zu denen, die bereits im CAD-Programm selbst erhalten wurden. Nach dem Verkauf von ITWO an das französische Unternehmen Schneider Electric für 1,5 Milliarden Euro konzentrierte sich Züblin (Strabag) auf die Entwicklung eines neuen Produkts für die Interoperabilität in der Bauindustrie.
Abbildung 20: Geschichte der Zublin-Strabag-Swallows und die Entstehung des geometrischen OGG-Kernels
Seit Mitte der 2010er Jahre entwickelt Züblin (Strabag) eine Plattform namens SCOPE, die über API-Verbindungen und das Reverse Engineering SDK Geometrie aus verschiedenen CAD-Programmen erfasst und in ein neutrales Format auf Basis von OpenCascade konvertiert. Dadurch können Geometriedaten in verschiedenen Geschäftsfällen verwendet werden, ohne an bestimmte CAD-Programme (BIM) gebunden zu sein. Die Hauptidee des Projekts besteht darin, das Projektdatenmanagement von CAD-Anwendungen zu trennen und die Unabhängigkeit der Benutzer von herstellerspezifischen Tools zu gewährleisten. Die SCOPE-Projektbeschreibung spiegelt die Idee von Samuel Geisberg (Gründer von PTC und Mentor des Revit-Projekts) wider, der den Einfluss von CAD-Programmen auf die Prozesse der Datenänderung und -ergänzung verringern wollte:
Während der ersten acht Monate des Projekts gelang es dem Konsortium, erste vollständige Bauteilbeschreibungen in den World Wide Web-Formaten RDF und OWL zu erstellen. Hierzu wurde die Funktionalität des Geometriekernels von openCASCADE in webadressierbare Strukturen überführt. Das erklärte Ziel von SCOPE ist die Schaffung von Webstrukturen, um die Hürden der Digitalisierung zu überwinden. Hierzu werden alle Bauteile eines digitalen Zwillings eines Gebäudes softwareunabhängig dargestellt und über Weboberflächen zugänglich gemacht. Im Erfolgsfall bedeutet dies, dass alle zur Erstellung eines Gebäudezwillings erforderlichen Digitalisierungsaktivitäten aller beteiligten Unternehmen, Fachdisziplinen und Branchen unabhängig voneinander und dennoch vernetzt durchgeführt werden können. Vorausgesetzt, die Inhalte werden auf derselben technischen Basis bereitgestellt, nämlich einer einzigen Serverstruktur und einem einzigen Datenschema.
Abbildung 21: SCOPE-Semantikprojekt des Züblin-Strabag-Teams
Die Idee des SCOPE-Projekts ist sicherlich vielversprechend und für die Branche notwendig, aber das Projekt wird innerhalb des geschlossenen Ökosystems von Zublin und Strabag umgesetzt, mit wechselnden Entwickler- und Managerteams. Dies führt möglicherweise zur Schaffung eines schwerfälligen und ineffizienten Systems mit verlängerten Projektrealisierungsbedingungen. Das auf OpenCascade basierende Züblin-Projekt ist außerdem mit den technischen Einschränkungen des OpenCascade-Geometriekernels selbst und der sich ständig ändernden API von CAD-Programmen konfrontiert. Ob es für ein Unternehmen mit zweifellos talentierten Spezialisten möglich ist, diese Probleme zu bewältigen, bleibt eine Frage.
Zusammenfassend kann man sagen, dass SCOPE angesichts der Einschränkungen, mit denen Entwickler konfrontiert sind, derzeit nicht als Komplettlösung bezeichnet werden kann. Eine von einer privaten Organisation für den internen Gebrauch erstellte Entwicklung ist kein universelles Tool.
Andererseits unternehmen die CAD-Anbieter selbst einen Schritt in Richtung Vereinfachung undwollen der Bauwirtschaft eineneues USD-Austauschformat, das dem CPIXML-Format ähnelt, das bereits alle 4D-7D-Prozesse in Bauunternehmen in Mitteleuropa abdeckt.
Die Unternehmen der Baubranche stehen daher in Zukunft vor einer Entscheidung: Entweder sie folgen den Ansätzen von Züblin und dem Fraunhofer-Institut oder sie übernehmen Lösungen, die von HOK und CAD-Anbietern über dasGebäudeSmartoder AOUSD-Allianz.
Beide Ansätze, ob aus der Baubranche oder der CAD-Welt stammend, kommen jedoch zum gleichen Ergebnis: Für einen effizienten Datenaustausch ist die Verwendung einfacher flacher Metainformationsspeicherformate und triangulierter Formate wie OBJ, CPIXML, DAE, SVF, gLTF oder USD, die dieselben Elementdaten speichern, sinnvoll.
Abb. 22: Unterschiedliche Datenformate enthalten identische Geometrie- und Metainformationen von Projektelementen
Nachdem wir die Geometrieübertragung und die damit verbundenen Komplexitäten besprochen haben, wollen wir nun den zweiten integralen Bestandteil von CAD (BIM)-Formaten diskutieren – Metainformationen und semantische Ontologie von Elementen, die in den offiziellen Pressemitteilungen von SCOPE undGebäudeSmartTeam.
Ähnlich wie dieGebäudeSmartMit diesem Ansatz hat Züblin das Konzept der Datensemantik auf seine SCOPE-Plattform angewendet. Grundlage dieses Ansatzes ist die Idee des semantischen Webs von Tim Berners-Lee. Sein Ziel ist es, eine intelligente Semantik zu schaffen, bei der Daten so strukturiert sind, dass sie nicht nur von Menschen, sondern auch von Maschinen verstanden werden können.
10. Entstehung von Semantik und Ontologie im Bauwesen
Die Standardisierung und Vereinheitlichung im Bauwesen übernahm die Einführung von Semantik und Ontologie aus dem Konzept des semantischen Webs in den späten 1990er Jahren. Dieses Konzept wurde im Rahmen vonGebäudeSmartfür den IFC-Standard. Die Grundidee der Semantik besteht darin, dass Daten nicht nur für Menschen, sondern auch für Maschinen Sinn ergeben sollten, sodass sie Informationen „verstehen“ und nicht nur übermitteln können. Die Ontologie wiederum schafft klare Definitionen von Begriffen und ihren Beziehungen, was einen einheitlichen Rahmen für alle Systeme bietet.
GebäudeSmarthat versucht, diesen Ansatz auf die gesamte Baubranche auszuweiten. In einem der wichtigstenDokumente über die Zukunft derdas IFC5Format,mit dem Titel „Future of the Industry Foundation Classes: Towards IFC 5“, der semantische Ansatzwird 32 mal erwähntund betonte dessen Bedeutung für die Weiterentwicklung des Standards:
Insbesondere im Bereich des Semantic Web wurde viel Aufwand in die Transformation, Modularisierung und Vereinfachung des IFC-Schemas (oder der IFC-Ontologie, je nach der typischen Ausdrucksweise in diesem Bereich) investiert. Es begann mit einer einfachen Transformation des IFC EXPRESS-Schemas und Modifikationen, die zu einer idiomatischeren Ontologie führten (Beetz et al. 2009), sowie Analysen, die auf die Einführung von Modularität abzielten (Terkaj und Pauwels 2017).
Das Ziel vonGebäudeSmartist die Schaffung eines einzigen universellen Standards zur Beschreibung von Objekten und ihren Beziehungen. Dieser Ansatz sollte in der gesamten Bauwelt anwendbar sein, die Vereinheitlichung der Daten sicherstellen und ihre Interpretation durch verschiedene Systeme verbessern. Der Erwerb einer Mitgliedschaft inGebäudeSmartbietet den Mitgliedsunternehmen nicht nur die Möglichkeit, die Zukunft mitzugestalten, sondern bereits heute aktiv auf ihre Gestaltung Einfluss zu nehmen.
Abbildung 23: Zitat des Vorsitzenden des internationalen Verwaltungsrats von BuildingSmart aus dem Jahr 1994
Die Implementierung von Semantik und Ontologien gelingt jedoch nicht immer. Die Realität hat sich als viel komplexer erwiesen. In der Spielebranche sind Versuche, Spielobjekte und Interaktionen durch Ontologien zu beschreiben, aufgrund der hohen Veränderungsdynamik und der kreativen Natur der Branche auf Probleme gestoßen. Daher erwiesen sich Standarddatenformate (XML, JSON) und -algorithmen als effizienter. Eine ähnliche Situation war auf dem Immobilienmarkt zu beobachten, wo die Vielfalt lokaler Begriffe und schnelle Veränderungen Ontologien übermäßig komplex machten. Einfache Datenbanken und Standardswie RETSBeim Datenaustausch und der Datenverarbeitung schnitten sie besser ab.
Neue Einheiten sollten nur dann eingeführt werden, wenn dies unbedingt notwendig ist
Ockhams Rasiermesser
Technische Schwierigkeiten, wie die Komplexität der Auszeichnung und der hohe Arbeitsaufwand bei der Unterstützung sowie die geringe Motivation der Entwickler, behinderten die Entwicklung dieser Idee in anderen Branchen. RDF (Resource Description Framework) wurde kein Massenstandard und Ontologien erwiesen sich als übermäßig komplex und wirtschaftlich nicht vertretbar. Infolgedessen konnte das Ziel, ein globales semantisches Web zu schaffen, nicht verwirklicht werden. Einige Ideen wurden in Unternehmenslösungen übernommen, aber das ursprüngliche Ziel, ein einziges umfassendes Diagramm zu erstellen, wurde nicht erreicht.
Abbildung 24. Vergleich von relationalen und ontologischen Datenbanken
Ontologien und semantische Technologien versprachen, aus Daten Bedeutung zu erzeugen, doch in der Praxis fungieren sie eher als Vereinheitlichungs- und Standardisierungsmechanismus. Der Übergang von Tabellen zu Datengraphen verbessert die Suche und vereinheitlicht das Datenmodell, macht die Daten für Maschinen jedoch nicht bedeutungsvoller. Die Frage ist nicht, ob semantische Technologien eingesetzt werden sollten, sondern wo sie wirklich einen Unterschied machen.
Das Interesse an semantischen Technologien und Ontologien in der Baubranche wird unterstützt durch dieGebäudeSmartInitiativen. Die Notwendigkeit einer vollständigen formalen Logik und der Schaffung einer einheitlichen Ontologie für die gesamte Branche bleibt jedoch ein kontroverser Punkt. Die Erfahrungen mit den CYC- („Enzyklopädie“) und Semantic-Web-Projekten zeigen, dass der Verzicht auf die Idee einer einzigen universellen Ontologie zugunsten lokaler Mikrotheorien, die nur innerhalb einer bestimmten Aufgabe, eines bestimmten Projekts oder Unternehmens anwendbar sind, ein produktiverer Ansatz sein kann.
11. Semantik und Ontologie: Wie bringt man Daten zum Sprechen?
Dank der Bemühungen vonGebäudeSmart, Semantik und Ontologien sind nicht nur zur Schlüsselidee hinter der CAD-Anbieter-Standardisierung geworden, sondern auch zur Grundlage für Projekte wie SCOPE, das von Züblin (Strabag) gefördert wird und darauf abzielt, die Bauindustrie von der Abhängigkeit von CAD-Systemen zu befreien.
Semantische Technologien dienen der Vereinheitlichung, Standardisierung und Modifizierung großer Mengen heterogener Daten sowie der Implementierung komplexer Suchfunktionen. Semantik hat jedoch nichts mit der Schaffung neuer Bedeutungen oder neuer Erkenntnisse zu tun – in dieser Hinsicht sind sie anderen Technologien zur Datenspeicherung und -verarbeitung nicht überlegen.
Die Darstellung von Daten aus einer relationalen Datenbank als Satz von Tripletts verleiht den Daten selbst keine Aussagekraft. Das Ersetzen von Tabellen durch ein Diagramm kann nützlich sein, um das Datenmodell zu vereinheitlichen, komplexe Suchvorgänge zu implementieren und Geschäftsmodelle sicher zu ändern. Die Daten werden dadurch jedoch nicht „intelligenter“ – der Computer beginnt nicht, ihre Bedeutung besser zu verstehen.
Wenn es um die Speicherung von „OWL-Daten“ geht, werden diese Daten mithilfe von RDF-Tripletts (RDF – Resource Description Framework und OWL – Web Ontology Language) gespeichert.
Abbildung 25: Graphendatenmodell: Knoten, Kanten und Tripel veranschaulichen die Beziehungen zwischen Bausteinen
Theoretisch ermöglicht die logische Inferenz von Risonern (Programmen für automatische logische Inferenz), neue Aussagen auf der Grundlage von Ontologien abzuleiten. Wenn beispielsweise in einer Gebäudeontologie festgehalten ist, dass „ein Fundament eine Stütze für eine Wand ist“ und „eine Wand eine Stütze für ein Dach ist“, kann der Risoner automatisch folgern, dass „ein Fundament eine Stütze für ein Dach ist“. Dieser Mechanismus ist in der Tat nützlich, um die Datenanalyse zu optimieren, da er die Notwendigkeit beseitigt, jede Abhängigkeit explizit auszuformulieren. Allerdings wird dabei kein neues Wissen geschaffen, sondern lediglich automatisch bereits bekannte Fakten verglichen.
Logische Verknüpfungen in der Ontologie können, sofern sie benötigt werden, ohne komplexe semantische Technologien organisiert werden, beispielsweise mithilfe relationaler Datenbanken (SQL) oder CSV- und XLSX-Tabellen. In spaltenorientierten Datenbanken und Formaten ist es möglich, eine Spalte „Dachträger“ hinzuzufügen und programmgesteuert sicherzustellen, dass die Tatsache, dass das Dach mit dem Fundament verknüpft ist, beim Erstellen der Wand hinzugefügt wird. Dies wird ohne die Verwendung von RDF, OWL, Graphen oder Resolvern erreicht.
Abb. 26: Vergleich grafischer und tabellarischer Modelle zur Darstellung gleicher logischer Zusammenhänge
Die Entscheidung vonGebäudeSmartund Strabag (Zublin) dem Konzept des semantischen Webs zu folgen, das Ende der 1990er Jahre vielversprechend und populär schien und die gesamte Baubranche beeinflusst hat. Das Paradoxe ist jedoch, dass das ursprünglich für das Internet vorgeschlagene Konzept des semantischen Webs selbst in seiner nativen Umgebung nicht weit verbreitet war. Im Internet, für das RDF und OWL entwickelt wurden, werden diese Konzepte heute kaum noch verwendet. Ein vollwertiges semantisches Web in der ursprünglichen Architektur ist nie aufgetaucht und seine Schaffung ist wahrscheinlich auch nicht vorgesehen.
Die Idee, ein Internet zu schaffen, in dem Computer die Bedeutung von Inhalten verstehen, erwies sich als zu komplex und unwirtschaftlich. Deshalb haben die Unternehmen, die das semantische Web ursprünglich unterstützten, nur die nützlichen Elemente der Technologie – wie Ontologien und SPARQL – aufgegeben und sie für Unternehmenszwecke und nicht für das Internet als Ganzes eingesetzt. Wenn Sie sich beispielsweise Google Trends der letzten 20 Jahre ansehen, können Sie erkennen, dass es dort möglicherweise keine Aussichten mehr gibt.
Abb. 27: Interesse am Thema Semantic Web laut Google-Abfragestatistik
Hier stellt sich eine logische Frage: Warum überhaupt Triplets, Rizoners und SPARQL beim Bauen verwenden, wenn man Daten mit gängigen strukturierten Abfragen (SQL, Pandas, Apache) verarbeiten kann? In Unternehmensanwendungen ist SQL der Standard für die Arbeit mit Datenbanken. SPARQL hingegen erfordert komplexe Graphstrukturen und spezielle Software und stößt laut den Trends bei Google bei Entwicklern nicht auf Interesse.
Graphdatenbanken und Klassifikationsbäume können in manchen Fällen nützlich sein, aber ihre Anwendung ist für die meisten alltäglichen Aufgaben nicht immer gerechtfertigt. Daher ist die Erstellung von Wissensgraphen und die Verwendung von semantischen Webtechnologien nur dann sinnvoll, wenn es darum geht, Daten aus verschiedenen Quellen zu vereinheitlichen oder komplexe logische Schlussfolgerungen zu ziehen. Für alltägliche Aufgaben wie die Verwaltung von Baudaten bleiben relationale Datenbanken, CSV, SQL und Excel einfachere, zugänglichere und effizientere Tools.
12. Von Diagrammen zu Tabellen: Arbeitsaufwand beim Gruppieren und Filtern
Jede Ontologie und Relation beschreibt grundsätzlich die Parameter von Projektelementen und Entitäten mithilfe von Schlüssel-Wert-Paaren. Die einzige Frage ist, wie und in welcher Form diese Schlüssel-Wert-Wörterbuchparameter kommuniziert werden. Der Unterschied liegt nicht im Speichermechanismus oder der Struktur, sondern in der Tiefe des semantischen Verständnisses und der Fähigkeit, sinnvolle Verbindungen zwischen Konzepten herzustellen. Ob Express-Markup und die IFC-Ontologie hierfür das ideale Werkzeug sind, ist eine große Frage.
Abb. 28: Informationen über Element-Entitäten werden in Schlüssel-Wert-Form als verschiedene Darstellungsformen gespeichert
In anderen Branchen gibt es dieselben Elemente mit Parametern, Geometrien und ähnlichen Problemen bei der Übertragung von Ontologien. Allerdings übertragen Spezialisten in diesen Branchen Metainformationen mithilfe gängiger Formate wie XML, DB, JSON, CSV, HD5 und XLSX. Es stellt sich eine logische Frage: Warum haben wir uns in der Baubranche entschieden, Metainformationen mithilfe von Technologien zu übertragen, die bereits in den 70er Jahren für das IGES-STEP-Format in zeilenweiser EXPRESS-Auszeichnung entwickelt wurden, das noch zu Zeiten der Lochkarten erfunden wurde? Ja, es gibt Konverter zum Konvertieren von Daten von IFC in JSON, XML, CSV oder XLSX. Es stellt sich jedoch die Frage: Warum überhaupt einen Zwischenschritt mit IFC verwenden?
Es ist viel logischer, Daten aus CAD-Programmen direkt in JSON, XML oder strukturierte CSV/XLSX-Formate zu entladen, indem man Reverse-Engineering-SDKs verwendet, die verwendet werden vonalle CAD-Anbieter ohne Ausnahme. In diesem Fall verliert die Verwendung von IFC als Zwischenschritt ihre Bedeutung. Und wenn es keinen Unterschied in der Informationsvollständigkeit zwischen Diagrammen und Tabellen gibt, beschränkt sich die Auswahl nur auf die Wahl des Datenschemas und des Datensatzformats.
Form und Schema der Daten sollten zum Anwendungsfall für bestimmte Aufgaben passen.
Abbildung 29: Graphik- und Tabellenstruktur enthalten identische Informationen zu Projektelementen
Das semantische Graphformat vereinfacht lediglich die Erstellung neuer Beziehungen, das heißt, es ermöglicht das Hinzufügen neuer Datentypen zum Graphen, ohne dass Änderungen an der Speicherstruktur vorgenommen werden müssen.
Im Vergleich zu relationalen Tabellen gibt es in einem Graphen keine spezielle, zusätzliche Datenkonnektivität – die Übersetzung zweidimensionaler Datenbankdaten in einen Graphen erhöht weder die Anzahl der Beziehungen noch ermöglicht sie neue Informationen.
Um Daten in Geschäftsprozesse zu integrieren, sollten wir danach streben, jene Tools zu verwenden, die uns dabei helfen, möglichst schnell und einfach Ergebnisse zu erzielen.
Die Hauptaufgabe bei der Verarbeitung von Daten aus CAD-(BIM-)Modellen und Datenbanken bleibt dieselbe: Sie besteht in der schnellen Gruppierung und Filterung aus der gemeinsamen Projektdatenbank einer bestimmten Gruppe, um wichtige Informationen zu extrahieren. Die Ergebnisse dieser Arbeit werden in Form von Tabellen, Diagrammen oder Dokumenten präsentiert und ermöglichen fundierte, datengesteuerte Geschäftsentscheidungen.
Abbildung 29: Einer der Hauptanwendungsfälle für Entwurfsdaten im Bauwesen ist die QTO-Gruppierung und -Filterung
Trotz identischer Eingabe- und Ausgabedaten können die Vorgehensweisen und der Zeitaufwand für die Durchführung dieser Vorgänge je nach den verwendeten CAD-(BIM-)Systemen und insbesondere den darin verwendeten Formaten, Datenschemata und konzeptionellen Ansätzen erheblich variieren.
Beispielsweise sieht die Aufgabe, eine Volumentabelle für alle Elementtypen derselben Kategorie (nehmen wir das Beispiel der Kategorie Wände – OST_Walls, IfcWalls) aus dem Projekt abzurufen, je nach Tool anders aus. In der Revit-GUI sind 17 Mausklicks erforderlich, um die Tabelle zu gruppieren und abzurufen. Mit Dynamo für Revit können Sie den Prozess automatisieren, müssen dafür jedoch 13 Codeblöcke in eine spezielle IronPython-IDE importieren und verknüpfen. Das Schreiben eines Python-Skripts für Revit würde 40 Codezeilen und Kenntnisse von APU erfordern, was mehr Flexibilität bietet, aber mehr Aufwand seitens des Ingenieurs oder Programmierers erfordert.
Die Arbeit mit IFC-Dateien über die Solibri-Programmoberfläche ist in Bezug auf den Arbeitsaufwand ähnlich wie bei Revit – um eine einfache Tabelle mit Volumen aus dem Projekt zu erhalten, müssen Sie auch hier 17 Mausklicks ausführen. Bei Verwendung der Python-Bibliothek IfcOpenShell oder des JavaScript IFC.js wird die Verarbeitung automatisiert, aber auch hier müssen etwa 40 bzw. mehr als 100 Zeilen Code geschrieben werden.
Darüber hinaus besteht das Problem mit proprietären Formaten und Formaten von CAD-Tools (BIM) darin, dass sie einerseits eine praktische Umgebung für die Entwicklung eigener Algorithmen zur Automatisierung von Produktionsprozessen bieten. Andererseits sind diese Algorithmen jedoch starr an ein bestimmtes Datenformat oder die Art und Weise ihrer Interpretation gebunden. Infolgedessen verliert die Automatisierung ihre Universalität und beginnt, von den Besonderheiten des Formats abhängig zu sein, anstatt mit Entitäten zu arbeiten und unabhängig von technischen Einschränkungen zu sein.
Abbildung 30: Mit unterschiedlichem Arbeitseinsatz wird das gleiche Ergebnis erzielt
Indem wir Daten aus CAD-Projektformaten normalisieren und strukturieren, ohne CAD-Programme (BIM) selbst zu öffnen, sondern beispielsweise Reverse-Engineering-Tools verwenden, erhalten wir Zugriff auf die Verwendung von Datenanalysetools zum Gruppieren, Filtern und Analysieren. Mit Datenanalysetools werden Gruppierungs-, Filter- und Verarbeitungsvorgänge buchstäblich mit einer Codezeile ausgeführt, während Sie in herkömmlichen CAD-Systemen und BIM-Konzepten, in denen Daten als Diagramme dargestellt werden, Hierarchien und Klassen durchlaufen müssen, um zu den Elementen zu gelangen. Infolgedessen können dieselben Aktionen, die Dutzende von Klicks in der Benutzeroberfläche und Hunderte von Skriptzeilen erfordern, durch die Verarbeitung von Daten in strukturierten Formaten schneller und einfacher ausgeführt werden.
Es handelt sich um strukturierte und normalisierte Daten, die es Ingenieuren ermöglichen, schnell und effizient zwischen unterschiedlichen Datentypen zu wechseln, sodass sie sich nicht mit individuellen Formatschemata, Schnittstellenfunktionen, API-Verbindungen und Geometriekerneln auskennen müssen.
Abbildung 31. In einem Diagrammdatenformular gelangen Benutzer über eine API oder eine Benutzeroberfläche zu den benötigten Daten.
Die Normalisierung und Strukturierung von Daten ermöglicht Flexibilität bei der Verarbeitung, ohne dass ein erheblicher Aufwand erforderlich ist, um das Datenschema für jeden einzelnen Anwendungsfall zu verstehen. Die gleiche Idee wird von ADSK im Jahr 2023 aufgegriffenund kündigt eine neue Ära dergranulare Daten, bei denen es kein Dateisystem mehr gibt – und Projekte werden in minimale Elemente zerlegt, wie es bei Datenanalysen und strukturierten Formaten der Fall ist.
Wenn CAD-Anbieter für ihre Kunden neue Formate und Methoden zur Datenverarbeitung entwickeln, wer ist dann für die Datenformate und Prozesse für die gesamte Baubranche verantwortlich und wer ist an der Entwicklung von Standards für deren Nutzung beteiligt?
13. Im Schatten von ISO und BuildingSmart: der Krieg um die Kontrolle des Datenformats
Die Probleme plattformübergreifender CAD-MCAD-Daten wurden erstmals von Spezialisten im Maschinenbau festgestellt, die häufig mit den Formaten STEP und IGES (dem ideologischen Vorgänger von IFC) arbeiten müssen, um Informationen zwischen MCAD-Produkten zu übertragen, wo Spezialisten, wie in der Bauindustrie, mit plattformübergreifenden geometrischen Kerneln zu kämpfen haben. Zitat aus dem Artikel „Auswahl des besten CAD-Dateiformats”:
Alle CAD-Systeme verfügen außerdem über einen geometrischen Modellierungskern, der dem nativen Format zugrunde liegt und Ihnen das Erstellen und Bearbeiten von Geometrie ermöglicht. CATIA verwendet Convergence Geometric Modeler (CGM), Creo verwendet Granite (g) und Siemens NX und SOLIDWORKS verwenden den Parasolid-Kernel (x_t).
Der geometrische Modellierungskernel ist in Bezug auf die reine Geometrie genau derselbe wie das native Format, da das native Format für jedes CAD-System auf seinem geometrischen Modellierungskernel basiert. Sie können keine bessere geometrische Genauigkeit als mit dem Kernelformat erreichen, solange Sie den Kernel für die Quell- oder Endanwendung verwenden. Wenn Sie beispielsweise ein Teil aus CATIA haben und es in MasterCam öffnen möchten, speichern Sie es im Parasolid-Kernelformat, da die MasterCam-Softwareanwendung darauf basiert.
Abbildung 32. Datenqualität in geschlossenen (Closed BIM) und offenen (Open BIM) Formaten
Programme wie Revit (basierend auf Pro/Engineer) und AutoCAD (basierend auf CADDS 3) sowie die meisten modernen Geometriekernel, darunter Open-Source OpenCascade, kamen aus dem Maschinenbau in die Baubranche. In dieser Branche wurden Datenaustauschstandards wie STEP (analog zu IFC für den Maschinenbau) entwickelt.
Obwohl die Probleme der Maschinenbauingenieure bei der Arbeit mit Formaten im Allgemeinen ähnlich sind und uns zu Problemen bei der Verwendung geometrischer Kernel führen, unterscheiden sich die Ansätze zur Standardisierung und Förderung dieser Formate im Maschinenbau und in der Baubranche deutlich.
Im Gegensatz zum Bauwesen, wo der IFC-Standard entwickelt und gefördert wird vonGebäudeSmart, Normen im Maschinenbau werden auf der Ebene der Internationalen Organisation für Normung (ISO) gebildet. In der ISO werden Normenwerden entwickelt unter gleichberechtigter Beteiligung vonaller Mitgliedsländer, was den Prozess globaler und unabhängiger macht. Die ISO kann als die „Vereinten Nationen für Normung“ mit Sitz in Genf betrachtet werden.
Der STEP-Standard istwird von TC 184 entwickelt, einem Komiteeist dem American National Standards Institute (ANSI) angeschlossen. Seine Geschichte geht zurück auf das IGES-Projekt, das 1979 von einer Gruppe von CAD-Anwendern und -Lieferanten, darunter Boeing, General Electric, Xerox, Computervision und Applicon, ins Leben gerufen wurde. Das Projekt erhielt Unterstützung vom US-amerikanischen National Institute of Standards and Technology (NIST) und dem US-amerikanischen Verteidigungsministerium, wobei die Entwicklung vom militärisch-industriellen Komplex finanziert und vom Militär kontrolliert wurde. Später wurde der STEP-Standard auf der Grundlage von IGES erstellt, und sein Ableger wurde in den 90er Jahren IFC. Im Gegensatz zu offenen Initiativen wurden alle wichtigen Entscheidungen zur Entwicklung des STEP-Standards hinter den Kulissen getroffen, ohne übermäßige Publizität und Lärm.
STEP ist ein rein nordamerikanischer Standard: Maschinenbauingenieure müssen ihn nicht verwenden. Wenn Sie ihn verwenden möchten, verwenden Sie ihn. Wenn Sie ihn nicht verwenden möchten, ist das kein Problem. Im Gegensatz dazuGebäudeSmart, ursprünglich 1994 zur Förderung der Interessen von HOK und ADSK gegründet, positioniert sich STEP-IFC mit der Gründung als globale Initiative, die sich für Interoperabilität und universelle Lösungen für die ganze Welt einsetzt.
Im Gegensatz zuGebäudeSmart, die Entwickler von STEP sind nicht daran interessiert, Abonnements zu verkaufen oder Unterteilungen wie Kapitel und Räume zu erstellen, über die Beiträge gesammelt werden, um ein parametrisches Format ohne eigenen geometrischen Kern und semantische Ontologie zu fördern, das das leisten soll, was dem semantischen Web nicht gelungen ist.
Aber selbst der Versuch, STEP-IFC in die Baubranche zu bringen und Allianzen zu bilden, lässt das durch die Austauschformate verursachte Chaos nicht überwinden. Die Situation hat den Punkt erreicht, an dem selbst CAD-Anbieter selbst nicht mehr in der Lage sind, IFC in ihren Produkten zu unterstützen, ohne spezielle SDKs zu verwenden, die wir im Artikel ausführlich besprochen habenKampf um offene Daten in der Baubranche. Geschichte von AUTOLISP, intelliCAD, openDWG, ODA und openCASCADE
Abbildung 33. Artikel: Die Ära der Veränderung: IFC gehört der Vergangenheit an oder warum ADSK bereit ist, IFC für USD aufzugeben
14. Warum müssen Bauherren und Auftraggeber die Kontrolle über Daten haben?
Die Datenerstellung im Bauwesen ist ein kontinuierlicher Prozess der Generierung von Parametern und deren Konvertierung in lesbare Formate. Jede Projekteinheit – eine Wand, ein Fenster oder ein Fundament – ist ein Objekt mit einer Reihe von Attributen wie Material, Typ, Kosten, Volumen und Fläche. Diese Daten müssen irgendwo gespeichert, verarbeitet und Endbenutzern zur Verfügung gestellt werden.
Entwickler von CAD-Programmen (BIM) sind bestrebt, Benutzer in ihrem Ökosystem zu halten, und verlagern jedes Jahr mehr und mehr Datenverarbeitung auf die Cloud-Speicherpartner Amazon, Microsoft Azure und Huawei. Der wichtigste Marketingvorteil geschlossener Systeme ist die Verfügbarkeit einer hochwertigen Geometrieübertragung vom geometrischen Kern von CAD-Lösungen (BIM) in das Cloud-MESH-Format und die Möglichkeit, Drittanbieterformate anderer Anbieter mithilfe teurer SDKs für Reverse Engineering zu importieren/exportieren.
Aber warum brauchen normale Ingenieure, Logistiker, Bauarbeiter, Vorarbeiter und Kostenschätzer geometrische Kernel und Cloud-Technologien? Die Genauigkeit tessellierter Formate reicht für die meisten Konstruktionsaufgaben aus, und die Verwendung komplexer geometrischer Kernel und SDKs erschwert den Prozess nur.
Abbildung 34. Die Baubranche steht vor einem unvermeidlichen Übergang zu offenen strukturierten Daten und offenen Tools
Die meisten modernen Grafik-Engines arbeiten speziell mit Dreiecksnetzen, nicht mit BREP-Geometrie. Die Ironie besteht darin, dass alle CAD-Anbieter weiterhin hartnäckig komplexe Geometriekernel fördern, manchmal nicht ihre eigenen, während Visualisierung, Simulation und Animation allmählich auf beliebte und kostenlose Tools für den nichtkommerziellen Gebrauch umsteigen – Blender, Unity, Unreal Engine und Omniverse.
Durch den Verzicht auf parametrische Geometrie für den Datenaustausch und die Datenverarbeitung zugunsten der MESH-Geometrie wird die Abhängigkeit von CAD-Programmen und Geometriekernen erheblich reduziert. Dies macht die Datenverarbeitung transparenter und beschleunigt die Entwicklung bereits beliebter Formate wie OBJ, gLTF, DAE und USD. CAD-Anbieter erkennen diesen Trend und bemühen sich, Benutzer in ihren Ökosystemen zu halten. Zu diesem Zweck fördern sie „benutzerfreundliche“ Interoperabilitätsformate, die formal als offen positioniert sind. In der Praxis erfordert der Export dieser Formate jedoch ein Abonnement für CAD-Programme (BIM), und die Verarbeitung erfordert API-Kenntnisse und Fähigkeiten zum Zuordnen von Funktionen komplexer geometrischer Kerne.
In der heutigen Design- und Bauwelt hat die Komplexität des Datenzugriffs zu einem Überengineering des Projektmanagements geführt. Mittlere bis große Bau- und Designunternehmen sind gezwungen, entweder enge Beziehungen zu CAD-Lösungsanbietern (BIM) zu pflegen, um über APIs und Produkte wie Forge und ACC auf Daten zuzugreifen, oder die Einschränkungen der CAD-Anbieter zu umgehen, indem sie teure SDK-Konverter für das Reverse Engineering verwenden.
Für den Zugriff auf die eigenen Projektdaten sollte kein spezieller Schlüssel, keine Abonnementgebühr für eine Cloud-basierte Lösung und auch kein Zauberspruch in Form einer API-Anfrage erforderlich sein.
Der Zugang zu Informationen ist ein Recht, kein Privileg.
Tim Berners-Lee, Erfinder des World Wide Web
Der Zugriff auf offene Daten wird für Bauunternehmen die nächste Büchse der Pandora öffnen, was unweigerlich zu einer Transformation der gesamten Baubranche führen wird.
15. Uberisierung und offene Daten sind eine Bedrohung für das Baugeschäft
Investoren und Baufinanzierungskunden werden in Zukunft zwangsläufig den Wert offener Daten und historischer Datenanalysen erkennen. Dies eröffnet Möglichkeiten zur Automatisierung der Berechnung von Projektplänen und -kosten, was eine bessere Kostenkontrolle und eine schnellere Identifizierung von Mehrkosten ermöglicht. Wenn beispielsweise Betonvolumina auf der Baustelle automatisch mit einfachen flachen MESH-Projektdaten mit strukturierten Metadaten verglichen werden können, ohne dass CAD (BIM) und seine komplexen geometrischen Kernel verwendet werden müssen, wird sofort ersichtlich, wie Überschätzungen überschätzt werden.
Diese Offenheit und Transparenz der Daten stellt eine Bedrohung für Bauunternehmen dar, die es gewohnt sind, mit undurchsichtigen Prozessen und verwirrenden Berichten Geld zu verdienen, bei denen sich Spekulationen und versteckte Kosten hinter komplexen und geschlossenen Datenformaten und Plattformen verbergen können. Daher dürften Bauunternehmen kaum daran interessiert sein, offene Daten vollständig in ihre Geschäftsprozesse zu implementieren. Wenn die Daten verfügbar und für den Kunden leicht zu verarbeiten sind, können sie automatisch überprüft werden, wodurch die Möglichkeit einer Überschätzung der Mengen und einer Manipulation der Schätzungen ausgeschlossen wird.
Der Verlust der Kontrolle über Volumen- und Kostenkalkulationen hat bereits andere Branchen verändert und ermöglicht es Kunden, ihre Ziele direkt zu erreichen. Digitalisierung und Datentransparenz haben viele traditionelle Geschäftsmodelle verändert, wie etwa Taxifahrer mit Uber, Hoteliers mit Airbnb und Einzelhändler mit Amazon, wo direkter Zugang zu Informationen und automatisierte Zahlungen die Rolle von Vermittlern erheblich reduziert haben.
Abbildung 35. Das Baugewerbe wird bald mit den gleichen Prozessen konfrontiert sein, mit denen Taxifahrer, Hoteliers und Verkäufer vor 10 Jahren konfrontiert waren
Investoren, Kunden und Banken haben bereits begonnen, auch in der Baubranche Transparenz zu fordern. Der Prozess der Öffnung und des uneingeschränkten Datenzugriffs ist unvermeidlich, und mit der Zeit werden offene Daten zum neuen Standard werden. Daher werden die Fragen der Implementierung offener Formate vor allem von Investoren, Kunden, Banken und Private-Equity-Fonds – also denjenigen, die letztlich die Endnutzer der gebauten Objekte sind – nachgefragt.
Die Fortbewegung des Investors, des Kunden von der Idee bis zum fertigen Bauwerk erfolgt künftig quasi auf Autopilot – ohne Fahrer in Form eines Bauunternehmens, verspricht eine Unabhängigkeit von Spekulationen und Unsicherheiten.
Abbildung 36. Übergang von der Entscheidungsfindung auf Grundlage der Meinungen wichtiger Fachleute (HIPPO) zur Datenanalyse in der Baubranche: heute und morgen
Daten und Prozesse in allen menschlichen Wirtschaftsaktivitäten unterscheiden sich nicht von denen, mit denen Fachleute in der Baubranche zu tun haben. Das Zeitalter offener Daten und Automatisierung wird das Baugeschäft unweigerlich verändern, so wie es bereits im Bankwesen, im Handel, in der Landwirtschaft und in der Logistik der Fall war. In diesen Branchen werden die Rolle der Vermittler und traditionelle Geschäftsmethoden durch Automatisierung und Robotisierung ersetzt, sodass kein Raum mehr für ungerechtfertigte Preisaufschläge und Spekulationen bleibt.
Auf lange Sicht könnten Bauunternehmen, die heute den Markt durch die Festlegung von Preis- und Leistungsqualitätsstandards dominieren, ihre Rolle als zentrale Vermittler zwischen dem Kunden und seinem Bauprojekt verlieren.
Offene, strukturierte Daten und Prozesse werden Kunden und Investoren die Grundlage für genaue Schätzungen der Projektkosten und des Zeitplans bieten und Bauunternehmen die Möglichkeit nehmen, auf Grundlage undurchsichtiger Daten und komplexer Formate zu spekulieren. Dies ist sowohl eine Herausforderung als auch eine Chance für die Branche, ihre Rolle zu überdenken und sich an ein neues Umfeld anzupassen, in dem Transparenz und Effizienz zu entscheidenden Erfolgsfaktoren werden. Aber was bedeutet das für BIM in dieser Geschichte?
16. Gibt es BIM, openBIM, BIM Level 3 und noBIM tatsächlich oder handelt es sich dabei nur um Marketing-Gimmicks?
Wenn wir über BIM sprechen, kommen uns Bilder von 3D-Modellen, Kollisionserkennungstools und Modellbetrachtern in ACC in den Sinn. Aber wenn man tiefer gräbt, stellt sich die Frage: Was ist BIM wirklich? Ist es ein Satz von Daten, Parametern und Prozessen oder nur ein Marketingslogan? Um diese Frage zu beantworten, müssen wir über die von CAD-Anbietern propagierten Akronyme und Konzepte hinausgehen und uns das Wesentliche der Arbeit mit Designinformationen ansehen – Daten und Prozesse.
Jeder Geschäftsprozess im Bauwesen beginnt nicht mit der Arbeit mit CAD- (oder BIM-)Tools. In jedem Geschäftsprozess bilden wir zunächst die Parameter der Aufgabe und definieren die Anforderungen an zukünftige Elemente: Wir geben eine Liste von Entitäten, ihre anfänglichen Eigenschaften und Grenzwerte an. Dies geschieht normalerweise in Form mehrerer Spalten einer Tabelle, Datenbank oder Listen mit Schlüssel-Wert-Paaren (1–2).
Und nur auf der Grundlage dieser Ausgangsparameter werden Objekte automatisch oder manuell in CAD/BIM-Programmen mithilfe von API erstellt (3–4), wonach sie erneut auf die Einhaltung der Ausgangsanforderungen überprüft werden (5–6). Dieser Zyklus – Definition, Erstellung, Überprüfung und Korrektur (2–6) – wird so lange wiederholt, bis die Datenqualität das gewünschte Niveau für das Zielsystem – Dokumente, Tabellen oder Dashboards – erreicht (7).
Abbildung 37. Prozessautomatisierungszyklus für Geschäftsprozesse in der Baubranche
Wenn wir CAD (BIM) als eine Möglichkeit zur Übertragung von Parametern betrachten, also Schlüssel- und Wertesätze, die ursprünglich außerhalb der CAD-Umgebung generiert wurden (1–2), wird deutlich, dass wir tatsächlich mit einer Parameterdatenbank (2–3, 5–6) arbeiten, die durch verschiedene Tools ergänzt wird und irgendwann von einfachen Anforderungen zu einem Satz von Elementen mit Parametern wird, die in einem CAD-Programm normalerweise als geschlossene Datenbank behandelt werden. Wenn wir BIM durch das Prisma dieser Definition betrachten, finden wir Prinzipien, die denen ähneln, die in der Datenanalyse sowie in ETL-Prozessen (Datenextraktion, -transformation und -laden) verwendet werden. Es stellt sich die Frage: Was ist die Einzigartigkeit von BIM, wenn es in anderen Branchen keine ähnlichen Ansätze gibt?
In den letzten 20 Jahren haben CAD-Anbieter BIM als mehr als nur eine Datenbank positioniert. Marketingtechnisch wird BIM als parametrisches Werkzeug verkauft, mit dem sich die Design-, Modellierungs- und Lebenszyklusmanagementprozesse von Bauprojekten automatisieren lassen. In Wirklichkeit ist BIM jedoch eher zu einem Werkzeug geworden, um Benutzer auf der Plattform der Anbieter zu halten, als zu einer praktischen Methode zur Verwaltung von Daten und Prozessen.
Abbildung 38. Vergleich der Datenverarbeitungs-Workflows: manueller CAD (BIM)-Ansatz ohne Verarbeitung und automatisierter Workflow mit Datenvorverarbeitung
Anbieter haben hochwertige CAD-Daten (BIM) effektiv innerhalb ihrer Plattformen isoliert und sie hinter proprietären APIs, SDKs und Geometrie-Kerneln versteckt. Dadurch ist es den Benutzern nicht mehr möglich, Daten unabhängig zu extrahieren, zu analysieren und zu kommunizieren und diese Ökosysteme zu umgehen.
Heute ähneln die meisten Datenanalyseprozesse in der Baubranche denen in anderen Branchen. Dabei handelt es sich um typische ETL-Zyklen (Extrahieren, Transformieren, Laden) und Datenanalyse. Im Bankwesen werden beispielsweise Daten extrahiert, in verständliche Formate umgewandelt und zur Visualisierung und Analyse in BI-Plattformen geladen. Im Bauwesen wurden und werden dieselben Aktionen durchgeführt – Datenextraktion aus CAD-Datenbanken (BIM) (Extrahieren), Normalisierung und Strukturierung, anschließende Analyse, Transformation (Transformieren) und Hochladen in andere Systeme und Datenbanken (Laden).
Mit vollem Zugriff auf die CAD-Datenbank und unter Verwendung von Reverse-Engineering-Tools,Wir können eineFlache Entitätssätze mit Attributen und exportieren Sie sie in jedes beliebige offene Format, das sowohl Geometrie als auch Attribute von Designelementen enthält, ähnlich wie es im SCOPE-Projekt implementiert ist. Wenn BIM-Daten in leicht zu analysierende Formate umgewandelt werden – strukturierte Darstellungen von Tabellen, Datenbanken, DWH, DL –, sind Entwickler nicht mehr von bestimmten Datenschemata und geschlossenen Ökosystemen abhängig.
Abbildung 38. Vergleich der Datenverarbeitungs-Workflows: manueller CAD (BIM)-Ansatz ohne Verarbeitung und automatisierter Workflow mit Datenvorverarbeitung
So sieht die Zukunft der Baubranche aus: Daten sammeln, analysieren, validieren und Prozesse mit Datenanalysetools automatisieren.
Informationen sind das Öl des 21. Jahrhunderts und Analytik ist der Verbrennungsmotor.
Vielleicht ist BIM (CAD) nicht das Endziel, sondern nur eine Entwicklungsstufe. Wenn Baufachleute erkennen, dass sie direkt mit Daten arbeiten und traditionelle CAD-Tools umgehen können, wird sich „BIM“ als Begriff in einer Informationsflut auflösen. Wir werden anfangen, über granulare oder strukturierte Bauprojektdaten zu sprechen, aber es wird nicht mehr das BIM sein, das wir heute kennen.
17. Was kommt als nächstes? Einfache Formate und benutzerfreundliche Tools
Die wichtigste Entwicklungsrichtung könnte der Übergang zu offenen und unabhängigen Lösungen ohne proprietäre SDKs und Geometrie-Engines sein. Anstatt zu versuchen, das IFC-Format zu „optimieren“, das ohne spezielle Kenntnisse der Besonderheiten des Formats und eine spezielle Geometrie-Engine weiterhin schwierig zu handhaben ist, sollte die Branche auf bestehende universelle Formate achten, die ihre Wirksamkeit bewiesen haben: MESH, OBJ, gLTF, DAE, FBX oder USD für Geometrie sowie CSV, JSON, XML, XLSX, SQL, YAML für Metadaten und Parameter.
Die Zukunft der Baubranche hängt von der Entwicklung einfacher und kostengünstiger Tools ab, die denen ähneln, die Ende der 2010er Jahre nach zwei Jahrzehnten der Photoshop-Dominanz in der 2D-Grafik aufkamen. Das Aufkommen flacher JPEG-, PNG- und GIF-Formate, die frei von der redundanten Logik der internen Engines von 2D-Editoren sind, hat zur Entwicklung Tausender kompatibler Bildverarbeitungslösungen geführt.
Ebenso wird die Standardisierung und Vereinfachung von 3D-Formaten und Metainformationen die Entstehung vieler praktischer und unabhängiger Tools für die Arbeit mit Bauprojekten fördern. Der Abschied von der komplexen Logik der „Anbieterkerne“ und der Übergang zu universellen, offenen Formaten werden die Voraussetzungen für flexibleres und effizienteres Arbeiten sowie einen offenen Datenzugriff für alle am Bauprozess Beteiligten schaffen.
Abbildung 39. CAD/BIM-Reifegrad: von unstrukturierten Daten zu vollständig strukturierten Daten und Repositories.
Es gibt vielversprechende Projekte in der Open-Source-Community, die als Beispiele für die Entwicklung leichtgewichtiger geometrischer Löser dienen können:Lösungsraummit dem Potenzial, im Browser zu arbeiten,Web-CAD.orgzu JavaScript, verschiedene kostenlose CSG-Editoren.Besonderes Augenmerk sollte auf die Unity-Plattform gelegt werden, die eine fertige Basis für die Erstellung komplexer Tools mit der Möglichkeit bietet, das Rendering anzupassen und die erforderliche Funktionalität hinzuzufügen.In meinem2021Beispiel,die Engine des browserbasierten CAD-Programms von UnityHinweisCADwurde mit einem eigenen Geometrielöser überarbeitet, um der Funktionalität des kostenlosen Online-Programms SketchUp so weit wie möglich zu entsprechen.Das Ergebnis ist ein leichtes, kostenlosesund Open SourceProduktdas auf jedem Server schnell läuft.
Abbildung 40. BimCADOnline-Beispiel einer Open-Source-Online-Lösung mit eigenem geometrischen Solver
Das Hauptprinzip der Branchenentwicklung sollte nicht die Schaffung neuer Formate sein, sondern die effektive Nutzung und Verfeinerung bestehender Lösungen. Es ist wichtig, sich auf internationale Gemeinschaften zu stützen, wieOsArchUndFreeCAD, und um Teams zu unterstützen, die offene Geometrie-Kernel entwickeln.
Für diejenigen, die mit BREP-Geometrie arbeiten müssen, gibt es Open Source-Geometriekernel wieOCCUndOGGkann eine Schlüsselrolle spielen. Und für Aufgaben, bei denen MESH-Geometrie ausreicht,CGAL, OpenMeshUndMeshLibist eine vielversprechende Lösung. Verwenden Sie Reverse Engineering SDKs von Unternehmen wieOpenDesignAlliance, CADExchangeroderREIFENzum Abrufen und Schreiben von Daten in verschiedeneCADund MCAD-Formate. Diese SDKs wurden erstellt, um Entwicklern den gleichen Zugriff auf Daten zu ermöglichen und sicherzustellen, dass jeder CAD- und MCAD-Lösungen auf dem Niveau führender CAD-(BIM)-Entwickler entwickeln kann.
Abbildung 41 OpenDWG. Das Ziel der Allianz ist es, gleiche Wettbewerbsbedingungen für alle CAD-Anbieter zu schaffen, unabhängig von ihrer Beziehung zu ADSK.
In Kombination mit LLM-Modellen verbessern solche Tools die Effizienz der Prozesse zum Erstellen, Transformieren und Exportieren von Daten in Zielsysteme erheblich.
18. Aufkommen von LLM und ChatGPT in Projektdatenprozessen
Neben der Entwicklung offener Formate und universeller Tools revolutionieren Large Language Models (LLMs) wie LLaMA, ChatGPT, Gemini und Claude die Datenverarbeitungsbranche. Diese Technologien sindgrundlegend ändernProjektdaten werden verarbeitet und analysiert, sodass die Verarbeitung und Automatisierung für alle am Bauprozess Beteiligten zugänglich ist.
Während früher der Zugriff auf die Informationen ausschließlich über komplexe APIs und SDK-Schnittstellen erfolgte, die spezielle Programmierkenntnisse erforderten, ist es jetzt möglich, mit den Daten in natürlicher Sprache zu interagieren.
Innerhalb weniger Jahre wird es unweigerlich zu einer Demokratisierung des Datenzugriffs kommen. Einfache Ingenieure, Manager und Planer werden in der Lage sein, die notwendigen Informationen aus Projektdaten in strukturierten Formaten zu erhalten, indem sie einfach Abfragen in normaler Sprache formulieren. Es wird zum Beispiel ausreichen, im Chat zu fragen:„Alle Wände mit einem Volumen von mehr als 10 Kubikmetern tabellarisch nach Typ gruppiert anzeigen“, — und LLM wandelt diese Abfrage selbstständig in eine SQL- oder Pandas-Abfrage um und transformiert strukturierte Projektdaten durch Gruppierung in das gewünschte Format einer Tabelle, eines Diagramms oder eines fertigen Dokuments.
Mit jedem Tag wird die Baubranche mehr und mehr über granular strukturierte Daten, DataFrames und spaltenorientierte Datenbanken hören. Einheitliche zweidimensionale DataFrames, die aus verschiedenen Datenbanken und CAD-Formaten (BIM) gebildet werden, sind der perfekte Treibstoff für moderne Analysetools. Und Tools wie Pandas und ähnliche Bibliotheken für die Arbeit mit zweidimensionalen Tabellen und spaltenorientierten Datenbanken sind aufgrund ihrer leistungsstarken Datenverarbeitungsfunktionen und effizienten Indizierung ideal für den Einsatz in LLM. Für solche Daten ist kein Verständnis von Schemaformaten erforderlich und sie werden zu einer idealen Quelle für RAG, LLM und ChatGPT.
Der Automatisierungsprozess selbst wird erheblich vereinfacht – statt APIs geschlossener Produkte zu studieren und komplexe Skripte in Python, C# oder JavaScript zu schreiben, um Parameter zu analysieren oder zu transformieren, reicht es nun aus, die Aufgabe in Form einer Reihe separater Textbefehle zu formulieren, die in den richtigen Pipeline- oder Workflow-Prozess für die richtige Programmiersprache integriert werden.
Abbildung 42. Übergang von der Programmierung zur Abfrageerstellung im LLM, um einen Pipeline-Prozess zu erstellen
Kein Warten mehr auf neue Produkte, Formate, Plug-Ins oder Updates von CAD (BIM)-Tool-Anbietern. Ingenieure und Bauherren können mit einfachen, kostenlosen und leicht verständlichen Tools mit LLM-Chatbots selbstständig mit Daten arbeiten.
Moderne Datenanalysetools in Kombination mit offenen Datenformaten werden ein neues Arbeitsparadigma in der Baubranche schaffen, bei dem es nicht mehr darauf ankommt, eine bestimmte Software zu besitzen und ihre API zu verstehen, sondern auf die Fähigkeit, Aufgaben effektiv zu formulieren und zu parametrisieren und die erhaltenen Daten schnell zu analysieren.
Anstelle einer Schlussfolgerung
Die Situation mit Interoperabilität und plattformübergreifender Nutzung in der Baubranche zeigt deutlich die grundlegenden Probleme, die mit der Übertragung und Nutzung von Daten zwischen verschiedenen CAD-Systemen (BIM) verbunden sind. Ein Paradebeispiel hierfür ist ADSK, das das offene IFC-Format aktiv fördert, aber selbst nicht in der Lage ist, dessen korrekten Export aus seinen eigenen Produkten sicherzustellen und auf das Reverse-Engineering-SDK von OpenDesignAlliance zurückgreifen muss, einer Organisation, die ursprünglich 1998 gegründet wurde.konternADSKs Monopolüber Daten. Paradoxerweise zwingt diese Situation alle Akteure der Branche dazu, ähnliche SDKs zu verwenden, um Daten konkurrierender CAD-Lösungen für ihre Plattformen zu extrahieren und anzupassen. Dies untergräbt effektiv die Idee der plattformübergreifenden Interoperabilität, für die das IFC-Interoperabilitätsformat geschaffen wurde.
Das IFC-Format, das als universelle Brücke zwischen verschiedenen CAD-Systemen (BIM) gedacht ist, dient in Wirklichkeit als Indikator für Kompatibilitätsprobleme zwischen geometrischen Kerneln verschiedener CAD-Plattformen, ähnlich wie das STEP-Format, aus dem es ursprünglich hervorgegangen ist. Trotz der aktiven Förderung des Formats durch dieGebäudeSmartDie Hauptanstrengungen der Organisation konzentrieren sich auf die Standardisierung der Geometrie (wofür ein einheitlicher Geometriekernel erforderlich ist, der noch nicht existiert) und auf die Vereinheitlichung von Semantik und Ontologien für die Bauindustrie. Diese Bemühungen spiegeln jedoch die unerfüllten Ambitionen des Konzepts des semantischen Internets wider, bei dem die Erwartungen die Realität bei weitem übertrafen.
Abbildung 43. Geometrie und Informationen in Bauprozessen: von komplexen CAD- und BIM-Systemen bis hin zu vereinfachten Daten für Analysen
Branchenspezifische Besonderheiten verschärfen dieses Problem. Die Baubranche, die bei der Beherrschung neuer Technologien traditionell 10–20 Jahre hinter anderen Branchen zurückliegt, läuft Gefahr, diesen Weg zu wiederholen. Während in der IT die Ausfälle des semantischen Webs durch das Aufkommen neuer Technologien (Big Data, IoT, maschinelles Lernen, AR/VR) kompensiert wurden, gibt es in der Baubranche keine derartigen Gründe.
Es gibt jedoch auch vereinzelte Beispiele für alternative Ansätze. Züblin zeigt mit seinem SCOPE-Projekt, wie es möglich ist, über die klassische Logik von CAD-Systemen (BIM) hinauszugehen. Anstatt zu versuchen, IFC unterzuordnen oder sich auf proprietäre Geometriekernel zu verlassen, verwenden sie Reverse-Engineering-APIs und SDKs, um Daten aus verschiedenen CAD-Programmen zu extrahieren, sie auf Basis des Open-Source-OpenCascade-Kernels in neutrale Formate wie OBJ oder CPIXML zu konvertieren und sie dann auf Hunderte von Geschäftsprozessen von Bau- und Planungsunternehmen anzuwenden. Trotz der Fortschrittlichkeit der Idee bleiben solche Projekte jedoch Teil geschlossener Ökosysteme, die die Logik von Monovendor-Lösungen reproduzieren. Infolgedessen steckt die Baubranche erneut in einer Situation fest, in der plattformübergreifende Standards wie IFC ihre Mission nicht erfüllen und lokale Initiativen das Problem nur teilweise mildern.
Und es ist sehr wahrscheinlich, dass es den CAD-Anbietern erneut gelingen wird, die Diskussion über den Zugang zu offenen Daten auf „neue“ Konzepte, Formate und Allianzen zu lenken, die wie BIM und openBIM in erster Linie dazu dienen werden, Benutzer in proprietären Ökosystemen zu halten. Dies wird das Produktivitätswachstum in einer ohnehin unproduktiven Branche erneut zum Erliegen bringen, da die Ressourcen nicht darauf verwendet werden, Prozesse zu vereinfachen und zu optimieren, sondern darauf, die Kontrolle über Ökosysteme zu behalten und Benutzer für das neue Konzept zu gewinnen.
Abbildung 44. In den letzten 30 Jahren haben CAD-Technologien (BIM) nicht dazu beigetragen, die Produktivität in der Bauindustrie zu steigern
Der Zweck dieser Analyse besteht nicht darin, bestehende Ansätze zu kritisieren, sondern eine Diskussion über die Hauptfrage anzustoßen – wie man die Produktivität in der Baubranche steigern kann und ob dies grundsätzlich möglich ist. Ich habe großen Respekt vor den Entwicklern von CAD (BIM)-Lösungen und ADSK sowie vor den Teilnehmern und Mitgliedern vonGebäudeSmart. Vielleicht ist es jedoch an der Zeit, nicht mehr auf neue Konzepte von Anbietersoftware zu warten und sich auf unabhängige Entwicklung zu konzentrieren. Indem sich die Branche von Datenzugriffsproblemen befreit, kann sie auf moderne und benutzerfreundliche Tools für die Arbeit mit und die Analyse von Daten umsteigen. Dies wird es der Branche ermöglichen, sich in die Richtung zu bewegen, die Samuel Geisbergwies darauf hinin den späten 1980er Jahren.
Herkömmliche CAD/CAM-Software schränkt kostengünstige Änderungen zu Beginn des Designprozesses unrealistisch ein. Ziel ist es, ein System zu schaffen, das flexibel genug ist, um den Ingenieur zu ermutigen, problemlos verschiedene Designs in Betracht zu ziehen. Und die Kosten für Designänderungen sollten so nahe wie möglich bei Null liegen.
Dies ist der Beginn einer Diskussion über die Transformation der Branche. Nur wenn wir Datenzugriffsprobleme lösen, können wir mit der Untersuchung und Automatisierung von Geschäftsprozessen fortfahren.
📈 Offene Daten und Formate werden unweigerlich zum Standard in der Baubranche – es ist nur eine Frage der Zeit. Dieser Übergang wird beschleunigt, wenn wir alle die offenen Formate, Datenbankzugriffstools und SDKs für Reverse Engineering bekannt machen. Jeder Einzelne von Ihnen kann diesen Prozess unterstützen. Wenn Sie die Informationen, die Sie gelesen haben, nützlich finden, teilen Sie sie bitte mit Ihren Kollegen.
Wenn Sie über neue Updates und Artikel auf dem Laufenden bleiben möchten, abonnieren Sie den Newsletter auf derDatengesteuerte KonstruktionWebsite oder abonnieren SieLinkedInUndMedium.
In diesem Dokument werden allgemeine Themen aus dem Bereich Bauwesen und Datenprozesse behandelt, wobei auf historische und aktuelle Branchenpraktiken Bezug genommen wird. Alle Marken und eingetragenen Marken sind Eigentum ihrer jeweiligen Inhaber, und dieser Text ist weder mit Markeninhabern verbunden noch wird er von diesen unterstützt. Der Inhalt dient Informationszwecken und stellt keine rechtliche oder technische Beratung dar.
- Haftungsausschluss für Marken:
Alle in diesem Dokument erwähnten Produktnamen, Logos und Marken sind Eigentum ihrer jeweiligen Inhaber. Die Verwendung dieser Namen, Logos oder Marken stellt keine Billigung dar.
2.Erklärung zur Nichtverletzung:
Dieses Dokument dient ausschließlich Informationszwecken. Der dargestellte Inhalt stellt keine Verletzung von geschützten Marken, Patenten oder geistigem Eigentum dar und stellt auch keinen Eigentumsanspruch darauf dar.
3.Fair Use-Hinweis:
Dieses Material wird unter den Grundsätzen der fairen Nutzung für Bildungs-, Forschungs- und Informationszwecke bereitgestellt. Der Inhalt basiert auf öffentlich verfügbaren Informationen und erhebt keinen Anspruch darauf, geschütztes Wissen darzustellen oder zu reproduzieren.
4.Copyright-Anerkennung:
Bestimmte Abschnitte dieses Dokuments verweisen auf Materialien von Drittanbietern und werden entsprechend gekennzeichnet. Wenn es irgendwelche Bedenken bezüglich des Urheberrechts gibt, kontaktieren Sie uns bitte, um diese entsprechend zu klären.
5. Quellenangabe:
Die erwähnten spezifischen Frameworks, Formate oder Tools werden ihren jeweiligen Autoren oder Organisationen zugeschrieben. Ihre Aufnahme dient Analyse- und Kommentierungszwecken.
Weitere Artikel zu diesen Themen:
📰 Lobbyistenkriege und BIM-Entwicklung. Alle Teile
📰 Das Buch „DataDrivenConstruction. Navigieren im Datenzeitalter in der Bauindustrie“
