IDS 1.0 verstehen — was der Standard ist und wie eine erste Regel aussieht

In den meisten BIM-Projekten ist das Pflichtenheft ein Word-Dokument. Drei bis fünfzig Seiten, in denen steht, welche Bauteile geliefert werden müssen, welche Eigenschaften gefüllt sein sollen, welche Klassifizierungen wir verwenden. Geschrieben für Menschen, geprüft am Bildschirm. Das funktioniert, wenn der Prüfende konzentriert bleibt. Aber jeder, der schon vier IFC-Lieferungen am Stück gegen so ein Dokument geprüft hat, weiss: ab der dritten Datei beginnt der Blick zu wandern.

Die Frage ist nicht, ob das Pflichtenheft falsch ist. Die Frage ist, wie wir es maschinenlesbar machen. Genau dafür gibt es seit 2024 einen offenen Standard: die Information Delivery Specification, kurz IDS. In diesem Beitrag erkläre ich, was IDS leistet, wie eine IDS-Datei aufgebaut ist und wie eine erste konkrete Regel aussieht.

Was IDS leistet

IDS ist eine XML-Sprache, mit der man BIM-Anforderungen so aufschreibt, dass eine Software sie automatisch prüfen kann. Standardisiert wird sie von buildingSMART International. Die Version 1.0 wurde am 4. Juni 2024 als finaler Standard freigegeben. Wer heute damit arbeitet, ist nicht mehr Pionier.

Drei Begriffe werden im BIM-Alltag oft durcheinandergebracht. So sind sie zu unterscheiden:

• MVD (Model View Definition) — beschreibt, was eine Software an IFC exportieren muss. Aus Sicht des Software-Herstellers.
• IDM (Information Delivery Manual) — beschreibt prozessual, wer in welcher Phase welche Information liefert. Aus Sicht des Projekt-Workflows.
• IDS — ist die maschinenlesbare Brücke zwischen IDM und IFC. Was im IDM textuell vereinbart wurde, prüft IDS technisch.

Konkret: Wer als Bauherr oder Generalplaner schreibt „Alle tragenden Wände müssen einen Feuerwiderstand haben", kann denselben Satz in IDS so formulieren, dass jede Lieferung automatisch dagegen geprüft wird. Niemand scrollt mehr von Hand durch das Modell.

Wie eine IDS-Datei aufgebaut ist

Eine IDS-Datei ist im Kern XML. Nicht hübsch zu lesen, aber stabil zu verarbeiten. Sie besteht aus mehreren sogenannten Specifications, und jede Specification hat zwei Teile:

• Applicability — auf welche Modellelemente die Regel angewendet wird. Beispiel: alle IfcWall mit LoadBearing = True.
• Requirements — was diese Elemente erfüllen müssen. Beispiel: ein Property FireRating muss vorhanden sein und einen Wert aus einer definierten Liste haben.

Stark verkürzt sieht das in IDS-XML so aus:

<specification name="Tragende Wände — Feuerwiderstand">
  <applicability>
    <entity name="IfcWall" />
    <property propertySet="Pset_WallCommon"
              baseName="LoadBearing" value="True" />
  </applicability>
  <requirements>
    <property propertySet="Pset_WallCommon"
              baseName="FireRating">
      <value>
        <enumeration values="REI30,REI60,REI90,REI120" />
      </value>
    </property>
  </requirements>
</specification>

Pset_WallCommon ist ein in IFC fest definiertes Property-Set. LoadBearing und FireRating sind Standard-Properties darin. Wer eigene oder projekt-spezifische Properties verwendet, gibt einfach das passende Property-Set an.

Zwei Punkte, die wichtig sind:

• IDS prüft Strukturen und Werte, nicht Geometrien. Die Frage „Hat diese Wand ein FireRating?" lässt sich gut abbilden. „Schneidet diese Wand das Fenster?" hingegen nicht. Dazu unten mehr.
• IDS-Dateien sind versionierbar und teilbar. Eine gepflegte IDS-Bibliothek wächst mit jedem Projekt mit. Sie ist ein Asset, das man von einem Projekt ins nächste mitnimmt.

Eine erste Regel — Schritt für Schritt

Beispiel: „Tragende Wände müssen einen Feuerwiderstand haben." So wird daraus eine fertige IDS-Regel.

Schritt 1 — Anforderung präzise formulieren. Im Pflichtenheft steht typischerweise „Tragende Wände sind mit Feuerwiderstand zu kennzeichnen". Für eine maschinenlesbare Regel reicht das nicht. Was heisst „tragend" in IFC-Begriffen? Welche Werte sind zulässig? Wo liegt das Property? Aus dem Satz wird:

Alle Elemente vom Typ IfcWall mit Pset_WallCommon.LoadBearing = True müssen ein Property Pset_WallCommon.FireRating haben, dessen Wert in der Liste REI30, REI60, REI90, REI120 liegt.

Schritt 2 — Regel als IDS abbilden. Das geht entweder per Hand im XML-Editor (möglich, aber fehleranfällig) oder über einen Regeleditor, der das XML im Hintergrund erzeugt. Am Ende liegt eine .ids-Datei vor, die jedes konforme Werkzeug lesen kann.

Schritt 3 — Regel gegen ein IFC-Modell prüfen. Die .ids-Datei wird zusammen mit der .ifc-Datei geladen. Ein Validator geht durch alle IfcWall-Instanzen, filtert die tragenden heraus und prüft, ob FireRating vorhanden und im erlaubten Bereich liegt. Ergebnis: ein Bericht, der pro Element ausweist, was passt und was nicht — mit Begründung.

Was vorher pro IFC-Lieferung Stunden manueller Stichproben gekostet hat, geht in dieser Form in Sekunden. Und vor allem: reproduzierbar bei jeder neuen Lieferung.

Was IDS noch nicht löst

So nützlich der Standard ist — universell ist er nicht. Drei Dinge gehören explizit nicht zum Aufgabenfeld von IDS.

• Geometrische Prüfungen. Mindesthöhe, Mindestabstand, Türdurchgangsbreite — alles, was metrisch gemessen werden muss, lässt sich in IDS nicht abbilden. Dafür braucht es Werkzeuge mit eigener Geometrie-Engine, oft im Zusammenspiel mit BCF-Workflow.
• Kollisionserkennung. Clash Detection ist ein verwandtes, aber eigenes Thema. IDS sagt nichts über räumliche Beziehungen.
• Fachlogik mit Querverbindung. „Eine Wand mit FireRating REI90 sollte mindestens 12 cm dick sein" verbindet Geometrie und Eigenschaften — und liegt damit ausserhalb von IDS 1.0.

Diese Lücken sind aus meiner Sicht kein Versagen des Standards, sondern eine bewusste Abgrenzung. IDS ist die Sprache für strukturierte Anforderungs-Prüfungen. Für die übrigen Aufgaben gibt es andere Werkzeuge — meistens genau die, die im BIM-Stack ohnehin schon laufen.

Fazit

Seit der 1.0-Freigabe ist IDS kein Forschungsthema mehr. Der Standard ist da, die Tools auch. Der Übergang vom Word-Pflichtenheft zur IDS-Bibliothek ist keine Einmal-Aktion, sondern ein gradueller Prozess. Die meisten Projekte, die ich begleite, fangen mit zehn bis fünfzehn Regeln an und wachsen Schritt für Schritt mit der Erfahrung.

Wer eine erste Regel selber ausprobieren möchte, kann das unter ifclint.com direkt im Browser tun. Bestehendes IFC-Modell hochladen, eine IDS-Datei mitliefern oder im Regeleditor zusammenklicken — und prüfen lassen. Das Ergebnis kommt als BCF-Report heraus, direkt zur Übergabe an Planer und Fachgewerke.

Hintergrund zu den dahinterliegenden Qualitätsfragen finden Sie in „Warum IFC-Qualitätssicherung über Erfolg oder Scheitern von BIM-Projekten entscheidet" und „Die 10 häufigsten Fehler in IFC-Modellen".