Gebaeudehuelle 6-2020

31 gebäudehülle 7/8.20 fassade Ein Beispiel: Ein Planer entscheidet sich im Planungspro- zess etwa für eine Innenwandlösung von Rigips. Sämt- liche Simulationen und Berechnungen sind mit diesem System durchgeführt worden. Im Idealfall geht das BIM- Modell als IFC-File nun in eine entsprechende Ausschrei- bungssoftware. Je nach Ausschreibe- und Vergabeprozess wird tatsächlich aber eine Lösung von Knauf bestellt. Wie kommt aber diese Information jetzt in das BIM-Modell? Vielleicht gibt es hunderte derartiger Änderungen. Je nach AVA-Software gibt es eventuell digitale Wege zu- rück, die mal besser und mal schlechter funktionieren. Nur amWeg zurück ins CAD-System führt keine Varian- te vorbei. Dort muss eine aufwändige und komplizierte Konsolidierung stattfinden. Diese Praxis hat aktuell noch wenig mit einem immer aktuellen Digital Twin zu tun, an dem sich alle am Bau Beteiligten orientieren und arbei- ten können – und damit auch reichlich wenig mit BIM. bim-vision: ifc als informationsmodell BIM verlangt eine Welt, wie sie Google mit seinen Apps vorlebt: In dieser Welt sind alle aufkommenden Soft- warelösungen miteinander verbunden und kommunizie- ren miteinander. Da stellt sich nicht mehr die Frage nach Datenformaten, Anforderungsplänen und Bearbeitungs- ständen, weil unterschiedlichste Programme ständig un- bemerkt Daten miteinander austauschen. Das ist über den gesamten Gebäudelebenszyklus möglich – und zwar viel offener und freier als aktuell über die CAD-Systeme, die nur von Fachleuten wie Architekten und Bauzeich- nern bedient werden können. Technisch gesehen, bietet das offene Datenaustauschformat IFC heute schon zahl- reiche Möglichkeiten, einen Teil dieser Vision umzuset- zen, in der Praxis bleiben sie aber bisher noch ungenutzt. Da IFC ein geskriptetes Format ist, ist es möglich, ein Modell komplett aus dem Programmiercode zu erzeu- gen, sprich etwa ein ganzes Haus aus einem IFC-Code zu schreiben. Viel spannender ist aber, dass sämtliche Attri- bute aus verschiedensten Quellen befüllt werden können. Weil es eine Skript-Sprache ist, kann theoretisch jeder di- rekt in die Datei schreiben, um etwa Parameter und At- tribute zu aktualisieren, zu ergänzen oder auszutauschen, ohne dass ein Umweg über ein CAD-Programm notwen- dig ist. Das schafft noch keinen Datenfluss à la Google, aber zumindest Augenhöhe zwischen allen Beteiligten. mit apis zum freien datenverkehr à la google Damit eine flüssige Datenautobahn im Hintergrund auf Hochtouren laufen kann, braucht es sogenannte APIs (Application Programming Interfaces). Diese Werkzeug- boxen sorgen dafür, dass Programmierer mit ihren Lö- sungen an Systeme andocken und Information auf allen Kanälen ausgetauscht werden können. Die nahtlose Ver- netzung der Google-Apps funktioniert dank dieser APIs. Und genauso müsste und könnte es mit IFC im Baupro- zess funktionieren. Ob in CAD, in einer Ausschreibungs- Software oder auf der Baustelle über einen Viewer mit ei- nem iPad: Mit APIs ist es theoretisch an jeder Stelle des Prozesses möglich, Knauf-, Rigips- oder Schüco-Daten einzubringen oder wieder zu entfernen. Weil IFC her- vorragend 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 Verwirkli- chung dieser Vision ist noch ein langer Weg zu gehen. Aber er ist theoretisch und praktisch 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 wirk- lich freien Informationsaustauschformat wird, das jedem am Bau Beteiligten mehr Autonomie verschafft. mit datenbanken zu neuer informationsdichte Diese neu gedachte IFC-Datei lässt sich dank der APIs mit allen denkbaren Datenquellen verbinden und so- wohl einfach als auch benutzerfreundlich um optimier- te Informationen, wiederum strukturiert in verschiedene Level of Detail (LOD), Level of Information (LOI) oder Level of Information needed (LoIn), erweitern. In Ver- bindung mit einer eigens dem Bauprojekt gewidmeten führenden Datenbank stünde damit erstmals eine BIM- IT-Infrastruktur zur Verfügung, die diesen Namen auch verdient. Denn damit könnten zum ersten Mal wirklich Informationen fließen – nicht mehr nur Dateien. Die ei- gene CAD-Planung wird an Produktdatenbanken von Baustoffherstellern angebunden, je nach Stand im Ver- gabeverfahren wird das digitale Bauvorhaben auf Knopf- druck aktualisiert und die Änderungen direkt imDigital Twin im CAD-System angezeigt. Auf der Baustelle wer- den Produktänderungen ergänzt und über einfache Zu- satzfunktionen im Viewer allen angeschlossenen Daten- abnehmern übermittelt. So wird BIM real, und die Bau- branche kann umsetzen, wovon sie die ganze Zeit redet. mit datenbanken in alle detailtiefen Eine Schlüsselfunktion in diesen Überlegungen haben Hersteller von Baustoffen und Bauprodukten: Sie über- „IFC Plus ist der Weg und keine Einbahn- straße. IFC lässt sich in Verbindung mit entsprechenden APIs so nutzen, dass es sich überall ando- cken und bearbeiten lässt - und damit von einem Daten- austauschformat zu einem wirklich frei- en Informationsaus- tauschformat wird, das jedem am Bau Beteiligten mehr Au- tonomie verschafft.“ Matthias Uhl, BIM-Experte Fotos: © Shutterstock Informationen müssen fließen - und nicht Da- teien. Nur so lassen sich BIM-Modelle in alle Richtungen anreichern und reduzieren.