Jeder, der mit BIM zu tun hat, ist schonmal mit dem Thema Modell View Definition (MVD) in Berührung gekommen. Ob nun unbewusst durch eine IFC-Ausgabe aus einem Autorenwerkzeug oder bewusst durch den gezielten Einsatz von MVDs für strukturierte Informationsanforderungen an IFC-Dateien, ist an der Stelle gar nicht so wichtig. Dieser Artikel zeigt auf, worin die Herausforderungen in der täglichen Anwendung bestehen.

Was ist denn eine MVD?

Zusammengefasst ist eine Modell View Definition ein definierter Ausschnitt eines Datenmodells, welcher in einer MVD-XML beschrieben werden kann. Dieser kann genutzt werden, damit bei der Ausgabe eines Datenmodells von einer Autorensoftware in das IFC-Schema, nur ein definierter Teil des Modells übergeben wird. Die MVD definiert dadurch die Inhaltsgrenzen der Ausgabe und sorgt dafür, dass die ausgegebenen Informationen auf eine gezielte Verwendung abgestimmt werden. Sehr bekannte MVDs sind die IFC2x3 Coordination View 2.0 oder der IFC4 Reference View, welche für den Gesamtmodellaustauch einer Fachdisziplin verwendet werden.
Eine genaue Definition befindet sich auf der BuildingSmart International Seite, welche auch die Entwickler des Standards sind.

Warum ist MVD ein Thema?

Mir fällt in meiner Arbeitspraxis auf, dass dieses Konzept nur sehr wenigen wirklich bewusst ist und selbst wenn, wird eine MVD nur extrem selten für individuelle Definitionen von Informationsanforderungen benutzt. Das ist schade, weil das Grundkonzeptkonzept eigentlich richtig gut ist. Denn die Definition einer MVD-XML ermöglicht es auf klare Anforderungen nur mit dem Teilset eines Informationsmodells zu antworten, welches auch wirklich benötigt wird.
Interessant dabei ist, dass dies auch komplementär zu den LOIN-Konzepten, welche das Thema Informationsanforderungen noch globaler und ohne IFC betrachten. (Siehe dazu auch meinen Beitrag im Magazin von Ernst &Sohn aus 2020.)
Die Konzepte für klare Informationsanforderungen sind verfügbar, werden bisher aber bisher wenig genutzt bzw. sind häufig auch gar nicht bekannt. Das wirft die Frage auf, warum das so ist. Meiner Meinung nach scheitert die breite Anwendung von MVDs an diesen 2 wesentlichen Punkten. An dieser Stelle weise ich gern auf die Kommentarfunktion unter dem Beitrag hin. 😉

Punkt 1: Fehlende Implementierung in Softwaresystemen

Auch wenn dieser Punkt im ersten Moment sehr plakativ wirkt, stellt er aber ein mehrschichtiges Problem dar. Selbstverständlich können in einigen Autorenwerkzeugen MVDxmls eingelesen und erzeugt werden – auch die von BuildingSmart veröffentlichten StandardMVDs zur IFC-Ausgabe sind häufig implementiert. Das Problem ist auf Softwareseite eher die Bedienung, wenn keine StandardMVDxmls genutzt werden. Es ist zwar technisch möglich neue MVDs zu erstellen, aber es ist in keinem mir bekannten Programm wirklich nutzerfreundlich. Vor allem dann nicht, wenn eine MVDxml als Vorlage zur Nutzung eingeladen werden soll.
Neben der erstellenden Softwareseite liegen die Probleme auch in der Empfängerseite. Selbst wenn nach der StandardMVD ausgegeben wurde, ist es sehr selten, dass der Anwendungsfall für den die MVD gedacht ist, auch direkt funktioniert. Wir hatten das Beispiel mit der IFC2x3 Structural Analysis View und den Statikprogrammen (speziell auch Dlubal). Wir haben das aufgegeben und sind klassisch mit Nachbauen unterwegs – was fairerweise nicht nur Nachteile hat.
Auch die Erstellung von MVDXMLs ist bisher nur mit „Spezialsoftware“ zur Informationsverwaltung möglich, was ebenfalls nicht gerade zur Verbreitung des MVD-Ansatzes beiträgt.

Punkt 2: Wissen um MVDs und die Anwendung davon.

Ein Grundproblem des MVD-Konzeptes ist die fehlende Verbreitung und das Wissen um die Möglichkeiten. Damit meine ich nicht die Nutzung der Standard-MVDs, die für IFC-Ausgaben immer wichtig sind und eine Anwendung finden, sondern das Konzept der Nutzung von MVDs für sauberen Informationsübertrag für einen speziellen Anwendungsfall. Das findet selbst bei meiner Arbeit keine Anwendung, da es bisher nicht praktikabel ist.

Weiterhin ist die Voraussetzung für die Definition von MVDs auch die Kenntnis der eigenen Informationsanforderungen und das getrennt nach den verschiedenen Anwendungsfällen. Erst danach kann eine MVD beschrieben werden die dann auch noch für die Autorensoftware und Empfängersoftware verwendbar sein muss. Dadurch verliert das Konzept leider sehr viel an direktem Praxisbezug.

Werden die Problemstellungen angegangen?

Die Probleme in der Verbreitung und Anwendung von MVDs sind bekannt. Auch der BuildingSmart ist sich dessen bewusst und wird darauf in der weiteren Entwicklung von IFC reagieren.

Spätestens in IFC5 wird das MVD-Konzept nicht mehr weitergeführt und stattdessen durch die IDS-Initiative ersetzt werden. Dieses Konzept erfordert aber ebenfalls als Grundlage die Kenntnisse der eigenen Informationsanforderungen bzw. ein Commitment auf definierte Standards. Auch wenn die technische Implementierung in erster Linie ein Softwarethema bleiben wird, müssen wir uns diesem Thema in Zukunft stellen.

Einen sehr guten Artikel zum Thema BCF hat Léon van Berlo geschrieben und ist dabei vor allem auf das Problem von MVDs aus Softwareimplementierungssicht eingegangen: Mit dem Grundproblem, dass mehr Standardisierung von MVDs dazu führt, dass Softwarehersteller mehr Standards implementieren müssen.

Julien Beyer

Julien ist BIM-Enthusiast der ersten Stunde. Für das Studium des Bauingenieurwesens an der HTWK Leipzig, hat es ihn in die große Stadt verschlagen. Von seiner Kindheit auf dem Land hat er seine Bodenständigkeit mitgebracht, die ihm auch in der Hektik des Alltags ein guter Begleiter ist. Er sieht stets das Gute im Menschen und gibt alles – gern auch im Team – damit gute Ideen nicht nur Visionen bleiben. Wenn er nicht gerade als BIM-Manager der S&P Gruppe die kleinen und großen Herausforderungen der BIM Implementierung löst oder in diversen Gremien versucht, pragmatische Lösungsansätze in Hilfen, Standards und Normen zu übernehmen, liebt er seine VR-Brille, mit der er auch privat gern in virtuelle Welten abtaucht.