Bildnachweis Titelbild: Link
IDS, mvdXML, Gherkin mit Python: drei Ansätze zur Prüfung von IFC-Modellen auf Konformität mit Austauschanforderungen. Alle drei stammen von buildingSMART und lösen dieselbe Klasse von Problemen – funktionieren dabei aber grundlegend unterschiedlich. Da ein systematischer Vergleich bislang fehlte, haben wir einen erarbeitet.
Wir haben alle drei Ansätze anhand von Anforderungen aus zwei Quellen getestet: der von bSI veröffentlichten IDS-Dokumentation sowie dem aIfc4Rail-Projekt — einer bSI-Initiative zur Erweiterung von IFC für den Eisenbahnbereich. Die zentrale Herausforderung bei aIfc4Rail war praxisnah: zu überprüfen, ob ein Bahnsignal innerhalb eines IFC-Modells korrekt georeferenziert ist – an einer bestimmten Station entlang einer benannten Trasse.
IDS: der schnellste Einstieg
IDS ist das jüngste der drei Werkzeuge und das zugänglichste. Sein Vokabular ist bewusst schmal gehalten — ein fester Satz an Element-Typen und Property-Prüfungen, der Existenz, Werte und vordefinierte Typen abdeckt. Diese Einschränkung ist Teil des Designs; der Standard wurde auf Basis der häufigsten Anforderungen aus realen Projekten entwickelt, nicht auf theoretischer Vollständigkeit. Die Unterstützung durch kommerzielle Werkzeuge ist breit, was erheblich ins Gewicht fällt, wenn Teammitglieder kein tiefes IFC-Schema-Wissen mitbringen.
Für viele Projekte ist IDS schlicht ausreichend. Ein Muster, das sich aus der Studie herauskristallisiert hat: IDS liest sich wie eine abgespeckte Version von mvdXML, mit einer kleinen Anzahl fest codierter funktionaler Bausteine aus der bSI-Spezifikation. Diese Einordnung hilft zu erklären, wo IDS seine Stärken hat und wo es an Grenzen stößt — diese Grenzen werden schnell sichtbar, sobald Anforderungen spezifischer werden als reine Existenz- und Property-Wert-Prüfungen.
mvdXML: mehr vom IFC-Gefüge, mit mehr Aufwand
mvdXML bewältigt, was IDS nicht kann. Es unterstützt Kardinalität, Eindeutigkeit und logische Regelkombinationen mit AND, OR, XOR, NAND, NOR und NXOR. Seine Struktur bildet das IFC-Schema selbst eng ab, was die Erstellung anspruchsvoller macht, gleichzeitig aber echte Kontrolle darüber gibt, was wie geprüft wird. Geometrie ist nach wie vor außerhalb des Geltungsbereichs — diese Grenze gilt für IDS und mvdXML gleichermaßen.
Der Standard ist älter und wurde erfolgreich für die Modellprüfung und Software-Zertifizierung eingesetzt. Anders als bei IDS, wo die Interpretation des IFC-Schemas in einer Dokumentation kodiert ist, die sich unabhängig von der Serialisierungsversion ändern kann, enthält mvdXML den notwendigen Graphen zum Parsen und Prüfen direkt im Datensatz selbst.
Gherkin: Alltagssprache, aber Programmierung erforderlich
Gherkin funktioniert anders als die anderen beiden Werkzeuge. Anforderungen werden in natürlicher Sprache formuliert — Given / When / Then-Schritte, die jeder im Projekt lesen kann, unabhängig von seinem IFC-Hintergrund. Diese Lesbarkeit ist real und spielt für die Kommunikation zwischen Fachexperten und IT-Implementierern eine wichtige Rolle.
Der Haken ist, dass Feature-Dateien nur die Logik enthalten. Für ihre Ausführung wird Python-Code benötigt, der die Schritt-Definitionen implementiert — und dieser Code muss die volle Komplexität des IFC-Schemas berücksichtigen. Selbst eine kurze Aussage wie Given an IfcGroup kann in der bSI-Referenzimplementierung zu 25 manuell geschriebenen Python-Zeilen führen. Gherkin erfordert stets Programmierung.
Es ist zudem das einzige der drei Werkzeuge, das geometrische Anforderungen verarbeiten kann, und das einzige ohne eine harte Obergrenze dessen, was sich ausdrücken lässt. Diese Flexibilität ist real — aber nur, wenn eine validierte Implementierung bereits vorhanden ist. Eine Feature-Datei ohne funktionierenden Python-Backend ist schlicht Text.
Der aIfc4Rail-Testfall: wo es interessant wird
Das Bahnbeispiel aus dem aIfc4Rail-Projekt ist ein guter Belastungstest für alle drei Werkzeuge. Anders als typische vertikale BIM-Modelle verfügt die Bahninfrastruktur über keine klar abgegrenzten räumlichen Grenzen. Neubauprojekte schließen stets an ein bestehendes Netz an; die meiste Arbeit in einem gewachsenen Netz betrifft den Austausch vorhandener Anlagen. Eine bestimmte Anlagenkategorie kann hochgradig granular modelliert sein, während benachbarte Objekte vereinfachte Darstellungen verwenden. Die Geometrie desselben Signals kann von einer groben Silhouette bis zur vollständigen Baugruppe auf Bauteilebene reichen.
Diese Heterogenität ist der Grund, warum der Vergleich relevant ist. Eine einfache Schlüssel-Wert-Prüfung — verfügt dieses Signal über einen Property Set mit einem Stationsnamen? — funktioniert in IDS problemlos. Sobald jedoch verifiziert werden muss, dass das Signal über ein IfcLinearPlacement korrekt mit einer Trasse verknüpft ist, oder dass das lineare Maß am Stationsreferenzpunkt exakt 69,395 m beträgt, gehen IDS die funktionalen Bausteine aus. mvdXML kann die strukturellen Beziehungen abdecken. Für Geometrie wird Gherkin benötigt.
Was wann einsetzen
IDS für einfache Schlüssel-Wert-Prüfungen. mvdXML, wenn die Anforderung mehr vom IFC-Gefüge berührt. Gherkin für Geometrie — sofern eine validierte Implementierung bereits vorhanden ist.
Diese Empfehlung ergibt sich direkt aus dem Vergleich in den Tabellen 2, 3, 4 und 5 des Beitrags. Es handelt sich nicht um eine Rangfolge. Alle drei Werkzeuge werden von bSI verantwortet und auf GitHub entwickelt. Sie adressieren unterschiedliche Punkte auf der Komplexitätskurve, und für viele reale Projekte lautet die richtige Antwort: mehr als eines davon.
Eine Frage, die der Beitrag nicht auflöst: Wer prüft den Prüfer? Ein belastbares Verfahren zur Überprüfung, ob verschiedene Implementierungen desselben IDS-, mvdXML- oder Gherkin-Regelwerks konsistente Ergebnisse liefern, existiert bislang nicht. Diese Lücke verdient Aufmerksamkeit.
Jaud, Š., Marie, S., & Pinzenöhler, A. (2025). The quest for the openBIM exchange requirements checking language: Comparing mvdXML, IDS and Gherkin. In Proceedings of the 2025 European Conference on Computing in Construction & CIB W78 Conference on IT in Construction, Porto, Portugal, 14.–17. Juli 2025.
