Merkmale mit Benefits – der Vor-Merkmalserver von buildingSMART Deutschland

Die derzeitige Situation kann fast schon skurril und absurd genannt werden: Jeder, der sich auch nur etwas mit der Digitalisierung im Bauwesen beschäftigt, stöhnt über die aktuell große Anzahl an Initiativen, die sich mit einheitlichen Merkmalen zur Klassifikation von Bauteilen und Produkten beschäftigen. Und teilweise bringen diese ihre eigenen Server zur Publikation und Verwaltung der Daten mit.

Vor diesem Hintergrund wirft buildingSMART Deutschland nun ein weiteres System in den Ring. Ergibt das Sinn? Dass dies sehr sinnvoll ist, was im Detail dahintersteckt und warum dadurch Produktmerkmale erst praxistauglich gemacht werden, erläutert Dr. Kai Oberste-Ufer, Vorstandsmitglied von buildingSMART Deutschland.

Wer A sagt, muss auch B sagen: Für das Verständnis, warum buildingSMART Deutschland seinen Arbeitsgruppen ein eigenes Redaktionssystem zum Datenmanagement zur Verfügung stellt, ist es hilfreich, das Zusammenspiel und Funktionieren von Klassifikationssystemen und Merkmalservern zu verstehen.

Ein Klassifikationssystem definiert abstrakte Klassen von Objekten (auch als Kategorien oder Typen bezeichnet) und deren Eigenschaften (Merkmale, Englisch auch als Properties bekannt). Derartige Systeme beziehen sich auf einen Fachbereich (zum Beispiel nur die Technische Gebäudeausrüstung (TGA)) oder decken mehrere Fachbereiche (Domänen) ab. Jedes Klassifikationssystem bildet (idealerweise) ein in sich abgeschlossenes, geregeltes und konsistentes System. Beispiele für Klassifikationssysteme sind ECLASS (ECLASS ist ein Datenstandard für die Klassifizierung von Produkten und Dienstleistungen mithilfe von standardisierten ISO-konformen Merkmalen), eTIM (ETIM ist ein Produktklassifikationssystem zur Strukturierung von Produktdaten) oder IFC (die Industry Foundation Classes sind ein offener Standard im Bauwesen zur digitalen Beschreibung von Gebäudemodellen (Building Information Modeling)). Jedes Klassifikationssystem kann als Sprache betrachtet werden, mit der ein Fachbereich technisch beschrieben werden kann.

Hier das Beispiel zu einer Wand: IFC definiert eine Klasse („Entity“ im IFC-Kontext) „IfcWall“ zur Abbildung einer Wand im Gebäudemodell. Dieser Klasse IfcWall sind verschiedene Merkmale wie „Länge“ oder „Schallschutzklasse“ zugeordnet. Die Merkmale sind dabei zusätzlich noch in Gruppen zusammengefasst („Pset“ im IFC-Kontext). Jedes Merkmal besitzt neben dem Namen noch eine Vielzahl von weiteren Attributen wie „Datentyp“, „Einheit“ oder „Erlaubter Wertebereich“, die in ihrer Gesamtheit das Merkmal eindeutig definieren. Die ISO 23386 definiert insgesamt vierzig Attribute für Merkmale und 23 für Gruppen.

Heutzutage ist es allerdings wenig hilfreich, wenn man die Informationen eines Klassifikationssystems ausschließlich als PDF ablegt oder in gedruckter Form veröffentlicht. Digitale Prozesse verlangen digitale, von IT-Systemen verarbeitbare Daten und Informationen.

Hier kommen Merkmalsserver zum Einsatz: Man nimmt die Klassen und Merkmale eines existierenden Klassifikationssystems (siehe oben), legt die Daten strukturiert (idealerweise nach ISO 23386) in einer Datenbank auf einem Web-Server ab (daher der Name „Merkmalsserver“) und stellt sie Nutzern zur Verfügung. Der Zugriff auf die Daten erfolgt dabei entweder menschenlesbar über die klassische Suchmaske im Browser oder maschinenlesbar über eine technische Schnittstelle (API – Application Programming Interface), wenn die Daten direkt von IT-Systemen ausgelesen und weitergenutzt werden sollen.

Aufgabe eines Merkmalsservers ist es in erster Linie, die Informationen, die nach einem bestimmten System nach Bauteilen klassifiziert und beschrieben werden, in maschinenlesbarer Form zur Verfügung zu stellen. Will man als Anwender die Daten nutzen, kann man beispielsweise über ein Software-Plugin auf die Daten zugreifen und sie direkt in der eigenen Software verwenden. Ein Umweg über den Browser wird so vermieden. Das Plugin nutzt dabei die API des Merkmalsserver für die Kommunikation und den Datenaustausch.

Ein Beispiel für einen Merkmalserver ist das buildingSMART Data Dictionary (bSDD). Im bSDD werden strukturierte Daten in verschiedenen, voneinander abgeschlossenen Domänen verwaltet und über eine Webservice-API Nutzern zur Verfügung gestellt. Im bSDD ist beispielsweise auch das IFC-Schema als eine Klassifikation abgelegt. Daneben existieren weitere, ganz unterschiedliche Domänen mit internationalen Klassifikationssystemen oder Daten aus den buildingSMART-Arbeitsgruppen.

Wichtig ist dabei: In einem Merkmalsserver werden lediglich die Merkmale definiert, mit denen Bauteile, Produkte und Elemente beschrieben werden. Dort werden keine konkreten hersteller- oder projektbezogenen Informationen angelegt, insbesondere auch keine konkreten Bauprodukte einzelner Hersteller. Dies ist die originäre Aufgabe von Bauteildatenbanken oder Produktkatalogen.

Jetzt könnte man sagen: „Na, dann ist ja alles klar.“ Allerdings ist die Sache nicht so einfach: Ein Bauteil kann beispielsweise nach unterschiedlichen Systemen klassifiziert werden. Je nach Betrachter oder Phase im Lebenszyklus kann ein anderes Klassifikationssystem relevant werden. Doch welches ist das richtige? Welcher Merkmalsserver sollte genutzt werden? Und wie wird ein gemeinsames Verständnis aller am Projekt Beteiligten für die Daten erreicht?

Illustrieren lässt sich dies erneut an einem Beispiel: Ein Bauprodukt, beispielsweise eine Tür, wird aus Sicht des Herstellers mit dem Schwerpunkt auf die Fertigung, Logistik und Warenwirtschaft beschrieben. Hierfür bietet sich ein System wie ECLASS an. Im weiteren Projektverlauf wird das Bauprodukt dann aus Sicht des Planers klassifiziert und beschrieben, der den Schwerpunkt auf das Produkt im Kontext des Gebäudes setzt und dafür IFC als „Sprache“ nutzt, um das verwendete Bauteil zu beschreiben.

Es gibt also kein „richtig“ oder „falsch“, keinen absoluten Maßstab. Sichergestellt werden muss jedoch, dass man die Klassifikation aus System A in System B übertragen kann, dass alle Beteiligten dasselbe, eindeutige Verständnis für ein Bauteil haben. Erreichen lässt sich das durch das „Mappen“ der beiden Systeme. Bedeutet: Objekte sowie deren Eigenschaften aus der Klassifikation A werden auf die entsprechenden Objekte und Eigenschaften des Systems B abgebildet.

Das Konzept der Klassifikationssysteme stößt jedoch an seine Grenzen, wenn es um die Definition von Produktdatenvorlagen (PDT – Product Data Templates) oder die Definition von Anwendungsfällen beziehungsweise AIAs (Auftraggeber Informationsanforderungen) geht.

Die Merkmale, die man zur Beschreibung eines Bauproduktes in einem PDT nutzt, sollten sich im Idealfall auf bestehende Normen und Klassifikationssysteme beziehen und nicht ohne fach- und normgerechten Kontext definiert und verwendet werden. Hier müssen oftmals unterschiedliche Klassifikationssysteme zusammengeführt werden, um eine Beschreibung des Produktes zu erzielen.

Gleiches gilt für die Definition von Anwendungsfällen: Diese beschreiben, wie eine Prozessschritt ausgeführt werden soll – zum Beispiel die Errichtung einer Wand – und welche Informationen dafür verwendet werden sollen. Dabei nehmen unterschiedliche Personen verschiedene Rollen ein. Auch hier müssen verschiedene Systeme kombiniert werden, um den unterschiedlichen Sichtweisen und Anforderungen der Prozessbeteiligten gerecht zu werden.

Abhilfe schaffen hier Redaktionssysteme, die auf unterschiedliche Klassifikations-Server zugreifen können. Diese werden oftmals als Vor-Merkmalsserver bezeichnet und stehen mehr oder weniger öffentlich zur Verfügung.

Einen Vor-Merkmalserver kann man sich als Redaktionssystem für Merkmale vorstellen, das auf vorhandene Merkmalserver zugreift, die Daten kombiniert und Funktionen bereitstellt, um neue Inhalte zu erstellen und zu verwalten. Die Bedienung erfolgt dabei zumeist über eine komfortable Weboberfläche mit Funktionen zum Export und Import der Daten.

Aus Sicht des Nutzers (sowohl desjenigen, der neue Inhalte erstellt, als auch desjenigen, der auf Inhalte zugreift) bezieht sich das Präfix „Vor“ demnach darauf, dass dieses Redaktionssystem vor den eigentlichen Merkmalservern liegt. Der Vor-Merkmalserver ermöglicht sogar teilweise erst den Zugriff auf die eigentlichen Merkmalserver. Beispiel bSDD: Das bSDD verfolgt den „API First“-Ansatz. Das heißt, es bietet keine eigene redaktionelle Oberfläche zur Bearbeitung der Daten, sondern fokussiert sich auf die Bereitstellung einer API, an der andere Systeme andocken können.

Übertragen auf das Beispiel mit der Tür bedeutet dies, dass man die Eigenschaften für die Tür im Vor-Merkmalsserver definieren würde und dann dort jedem Merkmal ein entsprechendes Merkmal aus den anderen Klassifikationssystemen zuweisen würde (Mapping).

Ein Vor-Merkmal (auch wenn es den Begriff offiziell so nicht gibt) ist also das Merkmal eines Klassifikationssystems, das Beziehungen zu anderen Merkmalen aus anderen Klassifikationssystemen besitzt und in einem Vor-Merkmalserver gespeichert wird: Ein Merkmal mit Benefits.

Ein Vor-Merkmalserver schafft die Verbindung zwischen verschiedenen, bislang getrennten Informationsquellen für unterschiedliche Bauteile. Es versetzt alle Beteiligte am Gesamtprozess im Lebenszyklus eines Bauwerks (insbesondere auch deren Software) in die Lage, Informationen eindeutig und widerspruchsfrei auszutauschen.

buildingSMART Deutschland hat erkannt, dass ein eigenes Redaktionssystem im Sinne eines Vor-Merkmalserver eine sehr sinnvolle Ergänzung zur Unterstützung der Arbeit der buildingSMART-Arbeitsgruppen ist. Dieses Redaktionssystem ist die Grundlage, um Bauteilklassifikationen, Klassenkataloge sowie Produktmerkmale professionell zu managen und zu veröffentlichen.

Insbesondere drei Anwendungsfälle werden mit dem eigenen Redaktionssystem unterstützt: Die buildingSMART-Arbeitsgruppen bekommen ein professionelles Redaktionssystem an die Hand, damit die erarbeiteten Ergebnisse in kontrollierter Art und Weise verwaltet werden können und um die Daten mit bestehenden Klassifikationssystemen zu mappen sowie in andere Systeme publizieren zu können (beispielsweise ins bSDD oder nach BIM Deutschland).

buildingSMART Deutschland hat sich nach einer aufwändigen Evaluierungsphase für das Produkt BIMQ der AEC3 Deutschland GmbH entschieden. Dieses System ist für die meisten Anwendungsfälle der buildingSMART-Arbeitsgruppen die am besten passende Lösung. Es musste jedoch für den buildingSMART-Kontext um zwei Funktionen erweitert werden: Den Lese-Zugriff auf das buildingSMART Data Dictionary (bSDD), um bestehende Klassifikationen zu lesen, und um die Funktion, Daten zurück ins bSDD schreiben zu können.

Bis dato verwaltete jede Arbeitsgruppe ihre Daten (Merkmallisten, Klassifikationen) nach eigenem Ermessen. Mal wurde Excel verwendet, mal Word oder eine eigene Datenbanklösung. Für ein kontrolliertes und koordiniertes Arbeiten, einschließlich des Ergebnisabgleichs unter den einzelnen Arbeitsgruppen, war dies wenig förderlich. Auch verhindert diese Art des Arbeitens eine Veröffentlichung der Daten auf anderen Plattformen, zumindest in annehmbarer Zeit und mit vertretbarem Aufwand.

Im Unterschied zu anderen Vor-Merkmalssystemen ist das Redaktionssystem von buildingSMART Deutschland nicht frei im Netz verfügbar. Die Informationen und Ergebnisse können zum Beispiel nicht direkt über eine API abgerufen werden und in anderen IT-Systemen verwendet werden. Das System publiziert die Ergebnisse in andere, öffentliche Systeme wie beispielweise dem bSDD, wovon die Daten abgerufen werden können.

Wie lässt sich der Vor-Merkmalserver nun im Gesamtkontext der Digitalisierung des Bauwesens und insbesondere von Building Information Modeling einordnen?

Es ist unbestreitbar, dass Daten – seien es Klassifikationen von Bauteilen oder Produktdatenvorlagen – ein wesentlicher Baustein des digitalen Planens, Bauens und Betreibens sind und dass diese Daten (Produkt- und Prozessdaten etc.) innerhalb der Branche in einer festgelegten und abgesprochenen Weise strukturiert beziehungsweise klassifiziert werden sollten. Eine einheitliche Verwendung von Begriffen führt zu einem einheitlichen Verständnis. Und dies zu einer verlässlichen Kommunikation zwischen verschiedenen (IT-)Systemen.

buildingSMART Deutschland bietet mit dem Service „bSDD Data Management“ Bauproduktherstellern und Fachverbänden die Möglichkeit, ihre Daten und Klassifikationen im buildingSMART Data Dictionary zu publizieren. Verbandsmitgliedern steht das Redaktionssystem zur Verfügung, um Daten zu bearbeiten und zu veröffentlichen (insbesondere im bSDD oder beispielsweise auch im BIM-Portal des Bundes oder anderen Portalen). Das Ganze wird durch die Geschäftsstelle von buildingSMART Deutschland organisatorisch betreut und fachlich von seinen Arbeitsgruppen und den kooperierenden Partnern getragen. Diese Arbeiten schaffen die Grundlage für den Aufbau industrieweiter, einheitlicher Objekt- und Produktkataloge – und dies sowohl national als auch international.

Die Datenpflege erfolgt durch Vertreter der unterschiedlichen Arbeitsgruppen. Die Arbeitsgruppen sind es auch, die Besitzer der Daten sind und für deren Korrektheit, Vollständigkeit sowie die Einhaltung der Erarbeitungsregeln verantwortlich sind. 

Und wie sieht nun die Anwendung in der Praxis aus, welchen Nutzen bietet ein solches System aus Redaktionssystem von buildingSMART Deutschland und angeschlossenen Merkmalservern für Architekten, Ingenieure oder Hersteller in ihrer täglichen Praxis?

Gerade Planer und Architekt profitieren von dieser Kombination, da sie so Zugriff auf eine eindeutige Definition von Bauteilen und Eigenschaften haben und die Informationen mit anderen Beteiligten auf einer einheitlichen Basis austauschen können. Die Nutzung der Klassifikationen durch eine Planer-Software wird zukünftig durch komfortable Plugins noch einfacher, direkter und fehlerfreier erfolgen können.

Für Hersteller von Bauprodukten stellen Merkmal-Server eine verlässliche Quelle von Informationen dar, die ihnen genau mitteilt, mit welchen Eigenschaften Bauprodukte beschrieben werden sollen (zun Beispiel ein BIM-Objekt), damit sich diese nahtlos in den digitalen Planungsprozess einfügen lassen. Da dies auch die Definitionen der Planer sind, wird die Effizienz der Zusammenarbeit deutlich erhöht. Man denke nur an die automatisierte Verarbeitung von Kundenanfragen mit Daten aus dem Gebäudemodell oder an die interaktive Einbettung von zum Beispiel Produktkonfiguratoren per API in den Gesamtprozess.