Digitale Herstellerkataloge in der TGA – Im Spannungsfeld der Interessen

Die Produkthersteller springen nur allzu gerne auf den BIM-Zug auf, denn so können sie hochdetaillierte 3D-Objekte ihrer Produkte in den Modellen platzieren. Die Softwarehersteller wiederum stöhnen unter der Last der großen Datenmengen und zahlreicher Herstellerkataloge. Und nicht zuletzt steht der Planer meist vor der Anforderung der herstellerneutralen Ausschreibung. Auf die aktuelle Lage aus Sicht der TGA-Fachplaner möchte ich im Folgenden eingehen.

Die Erwartungshaltung eines Fachplaners ist eindeutig – ich arbeite in meiner Planungssoftware und dort werden die Bauteile in ihrer Geometrie korrekt dargestellt und alle notwendigen Eigenschaften sind vorhanden. Spätestens aber wenn es um Datenaustausch geht (z.B. IFC), stößt man auf einige Hürden. Um zu verstehen, warum das so ist, lohnt sich ein Blick hinein in die Welt des elektronischen Produktdatenaustausches.

Wo liegt denn nun das Problem?

Seit der Einführung des computer aided design (CAD) versucht man, Objekte aus der realen Welt digital abzubilden. Schnell entwickelten die einzelnen Softwarehersteller dafür ihre eigenen Klassifikationssysteme – die Bauteile werden in Klassen strukturiert, die Beziehungen zueinander haben (z.B. Lüftungsgerät ist Teil des Systems Zuluft, Ventilator ist wiederum Teil von Lüftungsgerät). Da es aber eine schier unendliche Möglichkeit gibt, die Daten zu strukturieren, und die Softwarehersteller natürlich auch ihre Produkte verkaufen wollen, sind die Datenformate größtenteils nicht kompatibel (z.B. eine Revit-Datei und eine Nova-Datei) oder lassen sich lediglich referenzieren aber nicht bearbeiten (z.B. eine DWG-Datei in Revit).

Daraus erfolgten verschiedene Bestrebungen (hauptsächlich seitens der Nutzer) etwas Ordnung in das Chaos zu bringen. Zum einen mussten Bauteileigenschaften vereinheitlicht werden und zum anderen musste ein offenes Datenaustauschformat her. Die VDI 3805 von 2011 legte den Grundstein für den elektronischen Produktdatenaustausch in der technischen Gebäudeausrüstung und besagt: „Produktdaten gleichartiger Produkte müssen einen gleichen Aufbau besitzen“. Dies ermöglicht nun den Herstellern die Daten ihrer Produkte in einem einheitlichen Format zur Verfügung zu stellen, was mittlerweile von vielen Planungssoftwarelösungen eingelesen werden kann (sog. VDI-Datensätze). Jeder Softwarehersteller hat sozusagen eine Übersetzungstabelle (sog. Mapping) für den Import der VDI-Daten in sein eigenes Klassifikationssystem geschrieben.

Jetzt ist nur die Frage, wie bekommen wir die Daten wieder heraus?

Die Antwort auf diese Frage ist das von BuildingSMART definierte IFC-Datenformat. Dies ist sozusagen ein offen zugängliches Klassifikationssystem, in dem Gebäudedaten im Allgemeinen abgebildet werden können (Architektur, Tragwerksplanung, TGA etc.). Im Großen und Ganzen eine tolle Sache, aber genau hier liegt das Problem: wir haben beim Datentransfer immer verschiedene Klassifikationssysteme im Einsatz – die Informationen werden mehrfach erfasst und sind somit fehleranfällig. Außerdem führen die Klassifikationssysteme nur die Datensätze, die für die jeweilige Anwendung von Bedeutung sind; z.B. Berechnungsergebnisse in den nativen Formaten der Planungssoftware oder Herstellerbezeichnungen in der VDI 3805.

Beispielhafte Darstellung eines Übersetzungsprozesses zwischen Herstellerdatensatz (VDI 3805), nativem Klassifikationssystem (Plancal Nova) und offenem Austauschformat (IFC)

Was sind die Lösungsansätze für dieses Datenchaos?

Eine internationale Bestrebung ist das bsDD (building smart Data Dictionary); ein Online-Service, der Klassifikationssysteme und Eigenschaftssätze bereitstellt. Das tolle daran ist vor allen Dingen, dass die Bauteileigenschaften auch in verschiedenen Sprachen erhältlich sind und somit nicht nur für den deutschen Markt gemacht sind. Wie so oft müssen hier aber vor allem die Softwarehersteller aktiv werden und ein entsprechendes PlugIn implementieren. Außerdem gibt es das ganze bisher nur als Prototyp und die Datenlage für die TGA ist noch recht dünn.

Weiterhin gibt es noch die Initiative BIMeta. Hier haben sich einige deutsche TGA-Verbände zusammengeschlossen, um die Strukturierung digitaler Daten anzugehen. Die Idee hierbei ist, verschiedene Klassifikationssysteme (offene sowie herstellerspezifische) zu erfassen und in eine normalisierte Klassifikationsstruktur zu überführen. Aber auch dieses Projekt steht noch am Anfang und ist auf die Mitarbeit der Softwarehersteller angewiesen.

Eine gute Übersicht über die Lösungsansätze gibt übrigens das Positionspapier von buildingSMART aus dem Jahr 2020: 2020-10-30 BIM-Positionspapier TGA 14 Verbände.pdf (buildingsmart.de)

Gibt es ein Beispiel aus der Praxis?

Natürlich, denn diesen Artikel würde ich nicht schreiben, wenn alles funktionieren würde. Schon seit längerem versuche ich gemeinsam mit meinen Kollegen, die IFC-basierte Mengen- und Massenermittlung (sog. BIM2AVA) für die TGA zum Laufen zu bringen. Für diesen Prozess müssen eine Vielzahl von Eigenschaften an den Bauteilen vorhanden sein, um diese korrekt ausschreiben zu können. Auf den ersten Blick wird auch ein Großteil davon in der von uns eingesetzten Planungssoftware (Plancal Nova) geführt – aber nur, wenn auch ein geeigneter Herstellerdatensatz ausgewählt ist. Zum Beispiel dürfen nur Kataloge ausgewählt werden, die den Zusatz „mit Formstücken“ haben, sonst werden keine Materialinformationen an die Bögen geschrieben. Die Information „Material“ am 1-Strich-Bauteil landet bei dem 3D-Generierten Bauteil in der Eigenschaft „Bezeichnung“ – d.h. schon alleine intern arbeitet die Software nicht stringent. Außerdem ist die Materialbezeichnung nicht bei allen Katalogen eindeutig bzw. verweist auf den Hersteller (z.B. Prestabo) und man muss sich anderer Eigenschaften bedienen z.B. dem Material-Pfad (z.B. Rohrleitungssystem > C-Stahl > Rohre). Es fehlt also auch eine einheitliche Festlegung aller üblicher Rohrleitungsmaterialien, aus denen die Produkthersteller auswählen können. Eines der vielen weiteren Probleme zeigte sich bei der Einheitenumrechnung – in der IFC waren die Rohrleitungen plötzlich Kilometer lang.

Eigenschaftssatz eines Abwasserrohrs aus Plancal Nova betrachtet in iTWO

All diese Kinderkrankheiten führen dazu, dass die IFC-basierte Mengen- und Massenermittlung, zumindest für den Prozess Plancal Nova – iTWO, nur eingeschränkt und mit viel Know-How nutzbar gemacht werden kann. Und wie immer liegt es daran, dass kein Softwarenentwickler sich darüber Gedanken macht, dass die Kunden die Daten ja vielleicht in externen Anwendungen weiterverwenden werden wollen. Hoffen wir also, dass die Bestrebungen der Verbände zur Vereinheitlichung der Klassifikationssysteme schnelle Erfolge zeigen!

Ihr habt schon ähnliche Erfahrungen im Bereich Produktdatenaustausch in der TGA gemacht? Dann bin ich gespannt auf eure Kommentare.