Unser Alltag ist digital und vernetzt, nicht nur privat: Das CRM-Tool teilt uns mit, dass eine E-Mail zu einem Deal mit Abschluss in der laufenden Woche eingegangen ist. Die Marketing-Software scannt Informationen bei Linkedin, um Absatzaussichten zu prüfen. Und der Google-Kalender weiß aus einer E-Mail im Gmail-Account, dass ein Termin um 14 Uhr bevorsteht und erinnert daran. Google Maps erfährt wiederum von der Google-Kontakte-App, wo der Termin stattfindet, und zeigt, welches Verkehrsmittel aufgrund der Verkehrslage das Richtige ist. Während das digitale Management im Alltag und in der Geschäftswelt weitestgehend reibungslos funktioniert, scheitert die verheißungsvolle BIM-Kollaboration bereits am Datenaustausch zwischen Planungsprogrammen verschiedener Anbieter und erst recht am Datenfluss zwischen Planern und Gewerken. Dabei lautet doch das oberste BIM-Gebot: Software muss miteinander kommunizieren. Wie das beispielhaft gehen kann, machen Google und Co vor. Ein Ansatz ist, das Format IFC mit APIs (Application Programming Interface) und Datenbanken in IFC Plus zu erweitern.
Es ist zwar relativ einfach, von Archicad in Archiphysik oder Artlantis Studio und andere Programme einer zusammenarbeitenden Anbietergruppe zu wechseln. Um von Archicad nach Revit zu kommen, müssen aber immer noch Welten überbrückt werden. Und: Um von der CAD-Software Daten in eine x-beliebige Statik- oder Haustechnik-Software, sind die Hürden noch größer. Weil dafür offene Dateiformate unerlässlich sind, die den Austausch zulassen und eine Zusammenarbeit ermöglichen, ist IFC aktuell das führende Datenaustauschformat beim digitalen Planen und Bauen.
Austauschformat IFC: Einbahnstraße statt Datenfluss
Ein Problem ist, dass das Datenaustauschformat IFC aktuell wie ein PDF verwendet wird, in einer Art Einbahnstraßen-Kommunikation. BIM-Modelle verlassen als IFC-Dateien die CAD-Umgebung und werden an Statiker, sonstige Fachingenieure, Fachplaner und Beteiligte weitergegeben. Jede nachträgliche Änderung am BIM-Modell, auf der Baustelle oder in der Ausschreibungssoftware, bedeutet eine neue Version des IFC Files. Im Idealfall kommen die verschiedenen IFC-File-Versionen eines einzigen Bauvorhabens wieder zurück zum zentralen BIM-Manager, der die einzelnen Versionen richtig und vollständig zu einem einzigen nativen CAD-File wieder zusammenzusetzen weiß. Beispiel: Ein Planer entscheidet sich im Planungsprozess etwa für ein Lüftungssystem von Wolf. Sämtliche Simulationen und Berechnungen sind mit diesem System durchgeführt worden. Im Idealfall geht das BIM-Modell als IFC-File nun in eine entsprechende Ausschreibungssoftware. Je nach Ausschreibe- und Vergabeprozess wird tatsächlich aber eine Lösung von Daikin bestellt. Wie kommt diese Information jetzt in das BIM-Modell? Vielleicht gibt es hunderte solcher Änderungen. Je nach AVA-Software gibt es eventuell digitale Wege zurück, die mal besser, mal schlechter funktionieren. Nur am Weg zurück ins CAD-System führt kein Weg vorbei. Dort muss eine aufwendige, komplizierte Konsolidierung stattfinden. Diese Praxis hat aktuell noch wenig mit einem immer aktuellen Data-Twin zu tun, an dem sich alle am Bau Beteiligten orientieren und arbeiten können – und damit auch reichlich wenig mit BIM.
BIM-Vision: Information statt Format
BIM verlangt eine Welt, wie sie Google mit seinen Apps vorlebt: Da sind alle aufkommenden Softwarelösungen miteinander verbunden und kommunizieren miteinander. Keine Frage nach Datenformaten, Anforderungsplänen und Bearbeitungsständen mehr, weil unterschiedlichste Programme ständig unbemerkt Daten miteinander austauschen. Das ist im Endeffekt über den gesamten Gebäudelebenszyklus möglich – und zwar viel offener und freier als das über die CAD-Systeme aktuell möglich ist, die nur von Fachleuten wie Architekten und Bauzeichnern bedient werden können. Technisch gesehen bietet das offene Datenaustauschformat IFC heute schon viele Möglichkeiten, einen Teil der Vision umzusetzen, in der Praxis bleiben sie aber bisher ungenutzt.
Da IFC ein geskriptetes Format ist, ist es möglich, ein Modell komplett aus dem Programmiercode zu erzeugen, sprich etwa ein ganzes Haus aus einem IFC-Code zu schreiben. Viel spannender ist aber, dass sämtliche Attribute aus verschiedensten Quellen befüllt werden können. Weil es eine Skript-Sprache ist, kann theoretisch jeder direkt in die Datei schreiben, um etwa Parameter und Attribute zu aktualisieren, zu ergänzen oder auszutauschen, ohne dass ein Umweg über ein CAD-Programm notwendig ist. Das schafft noch keinen Datenfluss à la Google, aber zumindest Augenhöhe zwischen allen Beteiligten, wo bisher noch eine Hegemonie der CAD-Planer besteht.
Bild: Shutterstock / www.bim-more.com / Scrivo Public Relations
IFC Plus: Mit APIs zum freien Datenverkehr à la Google
Damit eine flüssige Datenautobahn im Hintergrund auf Hochtouren laufen kann, braucht es sogenannte APIs (Application Programming Interface). Diese Werkzeugboxen sorgen dafür, dass Programmierer mit ihren Lösungen an Systeme andocken und Information auf allen Kanälen ausgetauscht werden können. Die nahtlose Vernetzung der Google-Apps funktioniert dank dieser APIs. Und genauso müsste und könnte es mit IFC im Bauprozess funktionieren. Ob in CAD, in einer Ausschreibungssoftware oder auf der Baustelle über einen Viewer mit einem iPad: Mit APIs ist es theoretisch an jeder Stelle des Prozesses möglich, etwa Vaillant-, Viessmann-, Daikin- oder Wolf-Daten einzubringen oder wieder zu entfernen. Weil IFC hervorragend an diese APIs angebunden werden kann und Daten direkt in IFC-Dateien integriert werden können, trägt diese Vision den Namen IFC Plus. Zur Verwirklichung dieser Vision ist es noch ein langer Weg, theoretisch und praktisch aber möglich. IFC lässt sich in Verbindung mit entsprechenden APIs so nutzen, dass es sich überall andocken und bearbeiten lässt – und damit von einem Datenaustauschformat zu einem wirklich freien Informationsaustauschformat wird, dass jedem am Bau Beteiligten mehr Autonomie verschafft.
Bild: Shutterstock / www.bim-more.com / Scrivo Public Relations
Mit Datenbanken zu neuer Informationsdichte
Diese neu gedachte IFC-Datei lässt sich dank der APIs mit allen denkbaren Datenquellen verbinden und sowohl einfach als auch benutzerfreundlich um optimierte Informationen wiederum strukturiert in verschiedene Level of Detail (LOD), Level of Information (LOI) oder Level of Information need (LoIn) erweitern. In Verbindung mit einer eigens dem Bauprojekt gewidmeten führenden Datenbank stünde zum ersten Mal eine BIM-IT-Infrastruktur zur Verfügung, die diesen Namen auch verdient. Denn jetzt könnten Informationen zum ersten Mal wirklich fließen – nicht mehr Dateien. Die eigene CAD-Planung wird an Produktdatenbanken von TGA-Herstellern sowie von Baustoffen- und Bauproduktherstellern angebunden, je nach Stand im Vergabeverfahren werden das digitale Bauvorhaben auf Knopfdruck aktualisiert und die Änderungen direkt im Digital Twin im CAD-System angezeigt. Auf der Baustelle werden kurzfristige Produktänderungen ergänzt und wiederum über einfache Zusatzfunktionen im Viewer allen angeschlossenen Datenabnehmern übermittelt. Jetzt wird BIM real. Erst dann klopft Google anerkennend auf die Schulter der allgemeinen BIM-Software. Denn: Endlich hat die Baubranche geschafft, wovon sie die ganze Zeit redet.
Bild: Shutterstock / www.bim-more.com / Scrivo Public Relations
Mit Datenbanken in alle Detailtiefen
Eine Schlüsselfigur in diesen Überlegungen: Hersteller von TGA, Baustoffen und allgemein Bauprodukten. Sie übersetzen all ihre Produkte und Systemvarianten, die sie üblicherweise in PIM-Systemen organisieren, mithilfe einer BIM-Infrastruktur wie „BIM and More“ in BIM-Objekte, sodass sie Fachplanern und Architekten in CAD-Programmen zur Verfügung stehen. Denn ohne diese Vorleistung werden sich keine nennenswerten Informationsumfänge in die klassischen BIM-Prozesse einbringen lassen. Erst dann können etwa TGA-Planer wirklich informationsdichte BIM-Modelle als beispielsweise Archicad- oder Revit-Dateien erstellen und gemäß unserer hier beschriebenen Vision, einmalig als IFC Plus-Datei mit einer führenden Bauprojekt-Datenbank im Hintergrund, ausgeben.
Generalunternehmer (GU), Fachgewerke, Statiker und alle anderen am Bau Beteiligten arbeiten nun damit, jeweils über ihre eigene IFC Plus-fähige Software an die führende Datenbank angebunden. Und falls für die Erfüllung ihrer Teilaufgabe weitere Datenbanken nötig sind, werden auch diese angebunden. Ein abschließendes Speichern in die führende Datenbank macht alle Arbeitsergebnisse sofort für alle anderen sichtbar und nutzbar. Ein weiterer Austausch von Dateien ist dann nicht mehr nötig.
BIM bleibt Zukunftsmusik, ist aber nicht unmöglich
Noch gibt es diese Möglichkeiten nicht – und sicher nicht morgen. Aber das sind die nächsten Schritte einer längerfristigen Entwicklung mit der Vision einer digital vernetzten Planungs- und Baubranche, die hinter Building Information Modeling stehen.
Trotz vieler Errungenschaften befindet sich der digitale Entwicklungsgrad des Bauwesens immer noch am Anfang der vielfach beschriebenen Revolution. Dass BIM keine Software, sondern eine kollaborative Methode ist, bleibt ohne Überlegungen wie IFC Plus nur ein weit verbreitetes Lippenbekenntnis. Sie befindet sich aktuell an einem Punkt, an dem vielleicht nur 5 % der digitalen Möglichkeiten im Bau erreicht sind. In den kommenden zehn Jahren arbeiten alle noch daran, die Grundfunktionalitäten hervorzubringen, wie etwa einen unbemerkten Datenfluss von einer Software zur anderen, damit BIM seiner Vision etwas näherkommt – und unserer Grunderfahrung in einer digital eng vernetzten Alltagswelt.
Bild: Shutterstock / www.bim-more.com / Scrivo Public Relations
INFO
Begriffserklärung
IFC
Über das Datenaustauschformat Industry Foundation Classes (IFC) lassen sich geometrische und alphanumerische Daten gemeinsam in einem Dateiformat austauschen. Es wird häufig in Verbindung mit BIM eingesetzt und federführend von buildingSMART International weiterentwickelt.
PIM
Über ein Produktinformationssystem (PIM) erfasst und pflegt die Industrie sämtliche Daten ihrer Produkte über deren gesamten Produktlifecycle sowie darüber hinaus. Aus dieser Datenquelle werden zentral alle Ausleitungskanäle zu Websites und Portalen, E-Commerce Anwendungen, Druckereien oder auch unter dem Akronym BIM in CAD-Systeme, gesteuert.
API
Ein Application Programming Interface (API) bietet zahlreiche Möglichkeiten, den Funktionsumfang eines Programmes zu erweitern. Zu den wichtigsten zählen das Hinzufügen neuer Funktionumfänge über sog. Plug-ins sowie das Aus- bzw. Einleiten von Daten.
Weitere Begriffserkärungen:
Die aus dem anglo-amerikanischen Raum stammende Einteilung in Level (Stufen) beschreibt in BIM-Daten die darin enthaltene Informationsdichte.
LOD
Der Level of Detail (LOD) beschreibt den Detaillierungsgrad eines 3D- oder BIM-Modells. Dieser kann von grob LOD100 bis realitätsgleich LOD 500 als Maßstab 1:1 reichen. Heute häufig als Level of Development oder Deployment zur Beschreibung des Fertigstellungsgrades eines BIM-Modells oder einer BIM-Planung bezeichnet.
LOI
Der Level of Information (LOI) beschreibt die vorhandene alphanumerische Informationsdichte eines BIM-Modells. Auch der LOI wird von 100 bis 500 eingeteilt.
LOG
Der Level of Geometry (LOG) wird häufig verwendet, um den Detaillierungsgrad eines 3D- oder BIM-Modells zu beschreiben. Vgl.: LOD.
Loln
Der Level of Information Need (Loln) ist die Weiterentwicklung des Level of Deployment und beschreibt die Anforderungen an den LOI und den LOG in der BIM-Planung.
Der Autor Matthias Uhl ist Experte im Bereich Building Information Modeling (BIM) und Gründer sowie Geschäftsführer von Die Werkbank IT GmbH, die mit der BIM-Infrastruktur „BIM and More“ Herstellern von Bauprodukten und Baustoffen die Übersetzung und Aufbereitung der Produktdaten in BIM-Objekte ermöglicht.
