Blog

Überblick über die Spezifikation des IFC-Datenmodells Während des gesamten Lebenszyklus einer Anlage werden fortlaufend Informationen gewonnen und mithilfe verschiedener Technologien zwischen einer Vielzahl von Menschen ausgetauscht. Von der ersten Idee für den Bau bis zum Löschen des Objekts von einer Karte nach dem Abriss hinterlässt ein Gebäude eine Spur von Informationen, die es über seinen gesamten Lebenszyklus hinweg begleiten. Diese Spur ist nicht sichtbar. Manche nennen sie einen goldenen Faden. Ich bezeichne diese Spur lieber als Informationsebene, die Bestandteil eines Informationsmanagement-Ökosystems ist. Wie auch immer man die Spur nennen mag, ihr Weg ist derzeit überaus lückenhaft und – offen gesagt – ein großes Durcheinander. Das Informationsmanagement-Ökosystem Der Zweck des Informationsmanagements besteht darin, Informationen als eigenständige Assets zu betrachten. Um den vollen Nutzen aus den Informationen ziehen zu können, müssen sie rationalisiert und zusammengeführt werden – und diese beiden Prozesse sind vollkommen softwareunabhängig. Zwei Arbeitsebenen Das Informationsmanagement-Ökosystem besteht aus zwei Ebenen. Zunächst gibt es die Management-Ebene, die wiederkehrende Zyklen von Informationsmanagement-Aktivitäten auf Grundlage von festgelegten Terminen beinhaltet. Diese Ebene wird in der ISO 19650 beschrieben. Als zweites gibt es die Informationsebene, in der die Komplexität der verschiedenen Informationsfacetten aufgeschlüsselt, strukturiert, geordnet und zusammengefügt wird, um eine Basisdatensprache für die Aktivitäten in der oben beschriebenen Management-Ebene und als Grundlage für die verwendete Technologie bereitzustellen. Die Informationsebene ist sehr komplex. Dieser Tatsache kann man nicht entkommen. Versuchen Sie nur einmal, eine einzelne Komponente einer Anlage zu beschreiben: Typ, Leistung, Materialien, Standort, Name und alle anderen damit verbundenen Daten sowie die Daten über diese Daten. Und dabei handelt es sich nur um eine einzelne Komponente. Vervielfachen Sie das nun, um Zehntausende oder Millionen von Komponenten und deren zahlreiche Verbindungen untereinander abdecken zu können. Diese Aufgabe ist in ihrer Komplexität absolut unüberschaubar! Die einzige Möglichkeit, vernetzte und für Maschinen interpretierbare Daten zu erzeugen, besteht darin, Datenmodelle als Teil der Informationsebene zu verwenden. Was ist eigentlich ein Datenmodell? Im Wesentlichen handelt es sich bei einem Datenmodell um eine Möglichkeit, Daten zu strukturieren und zusammenzuführen. Es schafft Ordnung und ermöglicht komplexe Verbindungen. Ein Datenmodell ist kein BIM-Modell im herkömmlichen Sinne. Es muss deshalb keine Geometrie enthalten. Allerdings benötigen wir ein standardisiertes Datenmodell, um über alle Bereiche hinweg eine einheitliche Datensprache bereitzustellen, sonst stoßen wir schnell auf Interoperabilitätsprobleme. Haben wir bereits ein solches Datenmodell? Ja, das haben wir! Es nennt sich Industry Foundation Classes oder IFC. Bei IFC handelt es sich um eine standardisierte Datenmodellspezifikation. Sie wird von buildingSMART International verwaltet und ist ein internationaler Standard (ISO 16739). IFC bietet für den Großteil der AEC-Branche ein nützliches Daten-Framework, das es ermöglicht, eine Vielzahl von Informationen miteinander zu verknüpfen. Zum Beispiel können Informationen über einen Heizkessel, der an ein Rohr angeschlossen ist und mit einem bestimmten System in Verbindung gebracht wird, zusammen mit den Informationen über den Raum und das Gebäude, in dem er sich befindet, sowie mit dem Bauprogramm, den Inbetriebnahmezertifikaten, den Leistungsmerkmalen, dem Kostenplan, den Klassifizierungen usw. verknüpft werden. IFC-Darstellung eines Heizkessels Diese Aufzählung kann beliebig fortgeführt werden. Wichtig ist vor allem, dass es in unserer Branche außer IFC nichts anderes gibt, das so viel erreichen kann, wenn es darum geht, Informationen über eine Vielzahl von Bereichen hinweg miteinander zu verknüpfen. IFC ist eine digitale Darstellung von baulichen Anlagen, die ein Computer verstehen kann. Warum brauchen wir IFC? Jede proprietäre Softwareanwendung verfügt über ein eigenes Datenmodell, das im Hintergrund läuft. Zu Austauschzwecken werden diese Daten in der Regel in benutzerdefinierte Dateiformate verpackt. Die Datenmodelle sind den jeweiligen Kundenbedürfnissen angepasst und oft mangelhaft entwickelt. Ihr alleiniges Ziel besteht darin, mit der Software zu funktionieren. Wenn wir Daten zwischen Softwarepaketen austauschen möchten, stoßen wir deshalb schnell auf Interoperabilitätsprobleme, weil die Pakete verschiedene Sprachen sprechen. Wenn Softwarepakete ein Standard-Datenmodell lesen und schreiben können, müssen sie das Mapping nur einmal erstellen und benötigen keine Punkt-zu-Punkt-Lösung für jede einzelne Permutation des Softwareaustauschs. IFC kann aber nicht nur bei der Übermittlung und dem Austausch von Konstruktionsinformationen eine wichtige Rolle spielen. Denken wir noch einmal an das oben beschriebene Informationsmanagement-Ökosystem: IFC als standardisiertes Datenmodell steht dort im Zentrum der Informationsebene. Deshalb kann es Datengrundlagen zur Unterstützung der in ISO 19650 beschriebenen Aktivitäten bereitstellen. IFC kann verwendet werden, um die Anforderungen an den Informationsaustausch zu strukturieren, die Daten zu übermitteln, die übermittelten Daten mit den Anforderungen abzugleichen und die Daten während und nach dem Projekt zu speichern. Da das Datenmodell so groß ist, muss es zum Austausch von Informationen aufgeschlüsselt werden. Dazu werden gefilterte Teile des IFC-Schemas verwendet, die als Modell-Ansichts-Definitionen (Model View Definitions, MVD) bezeichnet werden. Dieser Ansatz wird derzeit von buildingSMART neu entwickelt, um ihn mithilfe von Information Delivery Specifications (kurz: IDS) flexibler zu gestalten. Je weiter die Digitalisierung fortschreitet, desto mehr Datenmodelle werden von den Organisationen geschaffen. Solange es keine standardisierte Grundlage dafür gibt, werden diese Datenmodelle völlig unterschiedlich strukturiert, und folglich wird der Austausch von Informationen zwischen ihnen genauso schwierig sein, wie er schon jetzt zwischen unterschiedlicher Software ist – allerdings in einem noch viel größeren Maßstab. Die Technologie allein bietet kein Patentrezept zur Lösung dieses Problems! Grundlegendes zu IFC Der IFC-Standard ist kostenlos und kann über die buildingSMART-Website aufgerufen werden. Momentan gibt es zwei offizielle Versionen: 1. IFC2x3 TC1 (IFC2x3) – entspricht der ISO 16739:2005 2. IFC4 ADD2 TC1 (IFC4) – entspricht der ISO 16739-1:2018 IFC 2x3 ist die vorherrschende Version. Die IFC4-Implementierung innerhalb von Softwareanwendungen hat seit kurzem zugenommen, und zusammen mit der vorgeschlagenen Veröffentlichung von IFC 4.3 im Jahr 2022/2023 müssen wir als Branche den Übergang zu IFC 4.3 im nächsten Jahr einleiten. Die Kommunikation des Datenmodells erfolgt mithilfe eines Schemas. Dieses Schema stellt eine Datenmodellierungssprache bereit, um ein Datenmodell (häufig auf grafische Weise) darzustellen, sodass der Betrachter sehen kann, was das Datenmodell enthält und welche Teile miteinander verbunden sind. IFC kann mit mehreren Schemata visualisiert werden. Das derzeit wichtigste Schema ist EXPRESS-G. Geplant ist ein Umstieg auf UML (Unified Modeling Language, deutsch: vereinheitlichte Modellierungssprache) ab IFC5. Um die Daten aus einem Datenmodell übertragen zu können, benötigen wir zusätzlich ein Austauschformat. IFC verwendet üblicherweise das textbasierte STEP-Dateiformat (STEP Physical File, SPF). Da dieses Format die Dateierweiterung „.ifc“ trägt, hat das zu der falschen Annahme geführt, dass es sich bei IFC nur um ein Dateiformat handelt. Textbasiert bedeutet, dass die Modelldateien mit einem Standard-Texteditor wie Notepad geöffnet werden können. Es gibt noch andere Austauschformate wie z. B. XML und JSON, und weitere befinden sich derzeit in der Entwicklung. Das sind unter anderem RDF/XML, Turtle und JSON-LD, bei denen der Schwerpunkt weniger auf dem Austausch von Dateien, sondern vielmehr auf dem Austausch von Daten liegt. Bestandteile des IFC-Datenmodells Einfach gesagt, besteht IFC aus drei Teilen: Entitäten, Attributen und Beziehungen. Die Entitäten sind die Hauptklassen und verhalten sich im Datenmodell wie Knoten. Das bedeutet, es sind die Entitäten, die miteinander verbunden werden. Die meisten Entitäten können als Objekte betrachtet werden – nicht nur als physische Objekte wie Wände und Kessel, sondern auch als andere Objekte wie z. B. Geometrie, Prozesse, Eigenschaften, Materialien usw. Dadurch ergibt sich die Möglichkeit, Kosten-, Ressourcen- und Konstruktionsplanungen mithilfe von IFC durchzuführen. Eine besonders wichtige Entität ist IfcBuildingElementProxy, die für Objekte verwendet werden kann, für die keine passende Entität zur Verfügung steht. Sie funktioniert wie eine Template-Entität, die alle geeigneten Attribute und Beziehungen identifiziert. Dadurch besteht außerdem die Möglichkeit, das Objekt genauer zu definieren (weitere Informationen im Absatz „Vordefinierte Typen“). Mithilfe von Attributen werden Entitäten genauer definiert, indem ihnen Basisdaten wie „name“, „description“ und „globalID“ zugeordnet werden. Attribute ermöglichen es auch, Verbindungen zu anderen Entitäten herzustellen, da sie sich wie eine Art Anhänger verhalten. Beziehungen wiederum verbinden Entitäten über die eben beschriebenen Attribute und sind im IFC-Schema selbst Objekte. Die Beziehungen sind der wichtigste Bestandteil des Schemas und werden in Zukunft sogar noch wichtiger, je vernetzter unsere Welt wird. Vordefinierte Typen, Eigenschaften und externe Referenzen Es gibt ein paar weitere Begriffe, mit denen sich Nutzer vertraut machen müssen. Ein besonders wichtiges Attribut ist z. B. der vordefinierte Typ. Dieses Attribut ermöglicht es, eine Entität genauer zu beschreiben: Vordefinierte Typen für die Entität IfcSanitaryTerminalType sind z. B. TOILETPAN, SINK, WASHHANDBASIN usw. In der Pickliste für vordefinierte Typen werden diese ebenfalls in Großbuchstaben aufgelistet. Der vordefinierte Typ USERDEFINED sollte nur dann verwendet werden, wenn kein geeigneter vordefinierter Typ vorhanden ist. USERDEFINED muss zwar als vordefinierter Typ angegeben werden, aber die Entität kann anschließend mithilfe der Attribute ElementType oder ObjectType genauer definiert werden. IFC ermöglicht auch die Zuordnung von Eigenschaften zu Objekten. Bevor eine solche Zuordnung durchgeführt werden kann, muss die Eigenschaft einem Eigenschaftensatz zugeordnet werden. Ein Eigenschaftssatz ist ein Container mit Eigenschaften, die etwas gemeinsam haben; innerhalb des IFC-Schemas werden Eigenschaftssätze mit dem Präfix „Pset_“ gekennzeichnet. Benutzerdefinierte Eigenschaften können zu benutzerdefinierten Eigenschaftssätzen hinzugefügt werden, aber es sollte immer zuerst überprüft werden, ob die Eigenschaften bereits in Branchenwörterbüchern oder in einem Lexikon vorhanden sind. Zu guter Letzt betrachten wir die externen Referenzen. Uns ist bewusst, dass nicht alle Informationen in IFC-Modellen erfasst werden, deshalb bietet IFC auch die Möglichkeit, extern referenzierte Informationsquellen mit IFC-Objekten zu verknüpfen. Bei den externen Referenzen handelt es sich um: Klassifizierung: Ermöglicht die Zuordnung von Klassifizierungssystemen wie Uniclass zu Objekten Bibliotheken: Ermöglichen die Verknüpfung von Daten aus externen Datenbanken mit Objekten (z. B. Hersteller von Produktdaten) Dokumente: Ermöglichen die Zuordnung von Dokumenten zu Objekten (z. B. kann einem Kessel ein Inbetriebnahmezertifikat zugeordnet werden) Zusammenfassend würde ich zwar nicht behaupten, dass IFC perfekt ist – aber wenn wir als Branche eng zusammenarbeiten, können wir IFC in unserer sich ständig verändernden digitalen Landschaft stärken, verbessern und stetig weiterentwickeln. Diejenigen, die mit digitalen Informationen arbeiten, müssen natürlich die Grundlagen des Standards kennen. Aber der Großteil der Menschen muss nicht einmal wissen, dass IFC überhaupt existiert, da es unauffällig im Hintergrund abläuft. Tatsächlich würde ich so weit gehen zu sagen, dass ich IFC – je besser ich es verstehe – als eine der größten Errungenschaften für die digitale Baubranche ansehe. Vorteile von IFC IFC hat viele Vorteile. Es ist kostenlos, standardisiert und für fast jeden Zweck zu verwenden. Dazu gehören unter anderem die Fähigkeiten: Daten-Frameworks für Informationsmanagement-Aktivitäten bereitzustellen wiederholbare Prozesse und Softwarekonfigurationen während der Datenübermittlung zu ermöglichen die Langlebigkeit und Nachhaltigkeit der Daten zu gewährleisten Probleme mit geistigem Eigentum und Lock-in-Effekte zu umgehen über die Zuordnung von Beziehungen komplexere Abfragen zu unterstützen und so bessere Einblicke für die Entscheidungsfindung zu ermöglichen durch Standardisierung eine einfachere Anbindung an externe Datensätze zu ermöglichen (z. B. für komplexe Anwendungsfälle wie Smart Cities) neue Entwicklungen wie z. B. maschinelles Lernen zu beschleunigen Dieser Artikel erschien zuerst im IFC Special Report, der von buildingSmart UK and Ireland und dem AEC Magazine erstellt wurde. Autor/in Emma Hooper Bond Bryan Digital Emma Hooper ist Spezialistin für digitale Informationen bei Bond Bryan Digital. Sie ist Mitglied des BSI-Ausschusses (British Standards Institute), der die Standards für digitales Bauen entwickelt, sowie Autorin der ISO 19650-Leitlinie, Botschafterin der UK BIM Alliance und Mitglied des buildingSMART UK & Ireland-Ausschusses. (www.bondbryandigital.co.uk)

Wie ein Großteil der Welt sind wir schockiert und traurig über die Krise in der Ukraine und verurteilen die ungerechte und unmenschliche Invasion Russlands auf das Schärfste. Unsere Herzen und Gedanken sind beim ukrainischen Volk. Und unsere Hauptsorge gilt der Sicherheit und dem Wohlergehen unserer Mitarbeiter und der breiteren Autodesk-Community – in der Ukraine und in Russland – von denen viele sich uns anschließen, um sich diesem Konflikt zu widersetzen und zum Frieden aufzurufen. Autodesk stellt sein Geschäft in Russland mit sofortiger Wirkung ein und hält sich weiterhin vollständig an alle derzeit geltenden Sanktionen. Wir werden weitere Beschränkungen für unser Geschäft in der Region in Betracht ziehen, sollten sich die Sanktionen ausweiten und sich die Situation weiterentwickeln. Inmitten des Schocks und der Traurigkeit dieser Krise schöpfen wir ein Gefühl von Stolz und Inspiration, wenn wir Menschen auf der ganzen Welt sehen, die sich versammeln, um die Betroffenen zu unterstützen. Dazu gehören auch die vielen Autodesk-Mitarbeiter, die ihre Zeit und Ressourcen einsetzen, um auf jede erdenkliche Weise zu helfen – von Spenden an humanitäre Organisationen, die der Ukraine helfen, über das Erheben ihrer Stimme gegen die russische Invasion bis hin zu Freiwilligenarbeit bei der Suche nach Unterkünften für Flüchtlinge, die vor dem Konflikt fliehen. Diese Woche hat die Autodesk Foundation finanzielle Unterstützung für ukrainespezifische Hilfsmaßnahmen zugesagt. Die Mittel gehen an das IKRK (Internationales Komitee vom Roten Kreuz) und UNHCR (Hochkommissariat der Vereinten Nationen für Flüchtlinge). Darüber hinaus werden wir jede Spende von Autodesk-Mitarbeitern im März an eine von fünf Organisationen, die sich auf die humanitäre und Flüchtlingskrise in und um die Ukraine konzentrieren, im Verhältnis 2:1 verdoppeln