Revit in der TGA – Austausch für Planer, Modellierer & BIM-Interessierte Beschreibung: Willkommen in der Gruppe Revit in der TGA! Diese Community richtet sich an alle, die Revit im Bereich der Technischen Gebäudeausrüstung (HKLS, Elektro, Sprinkler, MSR etc.) einsetzen oder sich dafür interessieren. Ob Einsteiger oder Profi – hier ist Platz für: - 💬 Erfahrungsaustausch zu Workflows, Familien, Templates & Best Practices - 🧰 Tipps & Tricks zur Modellierung, Koordination und Automatisierung - 🔄 Diskussionen zu Schnittstellen (IFC, BCF, Dynamo, etc.) - 📚 Empfehlungen zu Schulungen, Tools und Ressourcen - 🤝 Networking mit anderen TGA-Planern und BIM-Experten Ziel: Gemeinsam besser planen, modellieren und voneinander lernen – für eine zukunftsfähige TGA mit BIM! Link: https://www.linkedin.com/groups/13349050/

Revit und KG2000: Wie wir Entwässerungsrohre erfolgreich in der Lüftungsplanung integrieren... Die Herausforderung, das KG2000 Entwässerungsrohr in Revit für die Gebäudetechnik, speziell im Bereich Lüftung, nutzbar zu machen, war für mich zunächst sonderbar, ist jedoch kein Einzelfall – sondern ein Beispiel für die steigenden Anforderungen an BIM-konforme Planung. Wir haben die Entwässerungs-Bauteilfamilien des Herstellers sorgfältig analysiert und als Einlegebauteile für die Lüftung in einer Betonschalung adaptiert. So gewährleisten wir nahtlose Datenkompatibilität und eine präzise Integration in die TGA-Planung. Unsere Lösungsschritte im Detail: Datenaufbereitung: Import der originalen CAD-Daten des KG2000 Rohres. Anpassung in Revit: Adaptierung von bestehenden bzw. vom Rohrhersteller zur Verfügung gestellten Rohr-Formteilen zu Lüftung-Formteilen Validierung: Prüfung der Kompatibilität mit bestehenden TGA-Komponenten bzw. Lüftungsnetzen zur Nutzung der pneumatischen Informationen. Implementierung: Integration der angepassten Bauteile mittels angepasster Routing-Voreinstellung in das Gesamtmodell zur Lüftungsplanung. Qualitätssicherung: Testläufe im Projektkontext zur Sicherstellung der funktionalen Einsetzbarkeit. Persönlich habe ich erlebt, wie durch diese methodische Herangehensweise nicht nur Zeit gespart wurde, sondern auch Fehlerquellen deutlich reduziert werden konnten – ein echter Mehrwert für unsere Projekt-Begleitung. Unsere Arbeit war für typische Revit-Anwender in der TGA problemlos umsetzbar. Nutzen auch Sie die Vorteile einer präzisen Bauteilintegration in Revit! Kontaktieren Sie uns gerne für einen Workshop oder individuelle Beratung. #TGAPlanung #BIM #RevitIntegration

🧭 Warum 2D noch dominiert - Gewohnheit und Erfahrung: Viele technische Zeichner und Ingenieure sind seit Jahrzehnten mit 2D vertraut. Der Umstieg auf 3D erfordert nicht nur neue Softwarekenntnisse, sondern auch ein Umdenken im gesamten Planungsprozess. - Kosten- und Zeitdruck: In vielen Projekten zählt Geschwindigkeit. Wenn ein Büro mit 2D schneller Ergebnisse liefern kann, wird der Wechsel zu 3D als Risiko gesehen. - Fehlende Schulung: CAD-Software wie AutoCAD, Revit oder EPLAN bietet enorme Möglichkeiten – aber ohne gezielte Schulung bleiben viele Funktionen ungenutzt. - Unterschätzter Nutzen von 3D: Manche Geschäftsführer sehen nur den Mehraufwand, nicht den langfristigen Nutzen wie Kollisionsprüfung, Visualisierung oder BIM-Integration. 🧠 3D braucht mehr als Software – es braucht Strategie Die Aussage, dass 3D „dreifache Zeit“ beansprucht, ist oft ein Zeichen dafür, dass Prozesse nicht angepasst wurden. In einem gut strukturierten Workflow kann 3D sogar Zeit sparen: - Automatisierte Stücklisten und Dokumentation - Kollisionsprüfung mit anderen Gewerken - Bessere Kommunikation mit Bauherren und Architekten - Direkte Anbindung an BIM-Modelle und Facility Management 🛠️ CAD-Potenzial: 20% ist erschreckend wenig Wenn technische Zeichner nur 20% der CAD-Funktionen nutzen, liegt das Problem meist in: - Fehlender Weiterbildung - Nicht angepassten Benutzeroberflächen - Unklaren Standards im Büro - Mangelnder Motivation durch fehlende Wertschätzung 💡 Was wäre ein sinnvoller Weg nach vorn? - Schulungen und interne Workshops: Praxisnah, auf konkrete Projekte bezogen. - Pilotprojekte in 3D: Kleine Projekte, um Erfahrungen zu sammeln. - Mentoring-Systeme: Erfahrene CAD-Anwender helfen Kollegen. - Strategische Entscheidung auf Führungsebene: 3D muss als Investition gesehen werden, nicht als Kostenfaktor.

Revit ist grundsätzlich eine sehr mächtige BIM-Software, aber ihr Ruf hängt stark davon ab, wie gut die Implementierung und die Standards im Unternehmen sind. Probleme entstehen oft nicht wegen Revit selbst, sondern wegen: Schlecht vorbereiteter Projektvorlagen → führt zu Chaos bei Parametern und Familien. Unklare Anforderungen → CAFM-Parameter, IFC-Export, etc. werden nicht sauber definiert. Überladene Add-ins von Drittanbietern → „Nice-to-have“ kann die Performance und Übersichtlichkeit verschlechtern. Wir bieten Ihnen Lösungen.

Ü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)