Lektion 2.59 min Lesezeit

IDS in einem Satz

IDS macht aus einem Satz im Pflichtenheft eine Regel, die jede Software prüfen kann. Diese Lektion zeigt, wie eine IDS-Datei aufgebaut ist, wie aus Text eine Spezifikation wird, was IDS leistet — und was bewusst ausserhalb liegt.

KonstrukteureIngenieureBIM-KoordinatorenBIM-Manager

Lernziel

Nach dieser Lektion kannst du erklären, was IDS ist und welches Problem es löst. Du kennst den Aufbau einer IDS-Datei — Spezifikation, Anwendbarkeit, Anforderungen, Facetten —, kannst einen Satz aus dem Pflichtenheft in eine prüfbare Regel übersetzen und weisst, welche Prüfungen IDS bewusst nicht abdeckt.

Praxisproblem

Ein BIM-Pflichtenheft, Seite 14, Absatz 3: „Tragende Wände sind mit Angabe des Feuerwiderstands zu liefern."

Der Satz ist klar. Jeder im Projekt versteht ihn. Und trotzdem passiert bei der vierten Lieferung Folgendes: Der Prüfer öffnet das Modell, klickt sich durch dreissig Wände, findet bei elf keinen Feuerwiderstand, bei vier einen Wert in einem anderen Feld als erwartet, und bei zwei steht „REI90" statt „REI 90". Zwei Stunden später hat er eine Liste, die beim nächsten Export schon wieder überholt ist.

Das Problem liegt nicht am Satz. Es liegt daran, dass der Satz für Menschen geschrieben ist und von einer Maschine geprüft werden müsste. Dazwischen steht niemand — ausser dem Prüfer, der sich durchklickt.

IDS schliesst diese Lücke. Es ist das Format, in dem derselbe Satz so aufgeschrieben wird, dass eine Software ihn gegen jedes Modell anwenden kann, in Sekunden, bei jeder Lieferung gleich.

1. Der eine Satz

IDS — Information Delivery Specification — ist der buildingSMART-Standard, um Informationsanforderungen an IFC-Modelle maschinenlesbar und prüfbar zu machen.

Auch hier trägt jedes Wort.

Informationsanforderungen: Es geht um das, was ein Modell enthalten muss — Klassen, Eigenschaften, Klassifikationen, Materialien. Nicht um Geometrie, dazu unten mehr.

An IFC-Modelle: IDS setzt auf dem IFC-Datenmodell auf. Was in Lektion 2.4 als Klasse, Property Set oder Typ eingeführt wurde, ist hier das Vokabular, in dem Anforderungen formuliert werden.

Maschinenlesbar: Eine IDS-Datei ist XML nach einem festen Schema. Sie ist nicht hübsch zu lesen, aber eindeutig zu verarbeiten.

Prüfbar: Das ist der Zweck. Eine Anforderung in IDS liefert für jedes betroffene Objekt ein Ergebnis — erfüllt oder nicht erfüllt — und nicht eine Interpretation.

Die Version 1.0 wurde 2024 als finaler Standard freigegeben. Wer heute damit arbeitet, ist nicht mehr Pionier.

2. Wie eine IDS-Datei aufgebaut ist

Eine IDS-Datei enthält eine oder mehrere Spezifikationen. Jede Spezifikation ist eine Regel und hat zwei Teile, die man sich als Frage und Bedingung merken kann.

Die Anwendbarkeit (Applicability) beantwortet: Auf welche Objekte zielt die Regel? Zum Beispiel: alle IfcWall, bei denen LoadBearing gleich true ist.

Die Anforderungen (Requirements) beantworten: Was müssen diese Objekte erfüllen? Zum Beispiel: ein Property FireRating in Pset_WallCommon, mit einem Wert aus einer definierten Liste.

Beide Teile werden mit denselben Bausteinen beschrieben, den Facetten. Es gibt sechs:

Facette	Prüft	Beispiel
Entity	IFC-Klasse und PredefinedType	`IfcWall`, `SOLIDWALL`
Attribute	Attribut des Objekts	`Name`, `Description`
Property	Eigenschaft in einem Property Set	`Pset_WallCommon.FireRating`
Classification	Klassifikation und Code	eBKP-H, Uniclass
Material	Zugewiesenes Material	„Beton"
PartOf	Zugehörigkeit zu einem Container	Geschoss, Gruppe, System

Das Zusammenspiel ist einfach: Facetten in der Anwendbarkeit filtern. Dieselben Facetten in den Anforderungen fordern. Mehr Mechanik hat IDS nicht — und das ist seine Stärke.

3. Von einem Satz zu einer Regel

Zurück zu Seite 14, Absatz 3. „Tragende Wände sind mit Angabe des Feuerwiderstands zu liefern." In drei Schritten wird daraus eine Spezifikation.

Schritt 1: Den Satz präzisieren. Was heisst „tragend" in IFC-Begriffen? Welche Werte sind erlaubt? Wo liegt die Eigenschaft? Aus dem Satz wird: Alle IfcWall mit Pset_WallCommon.LoadBearing = true müssen ein Property Pset_WallCommon.FireRating tragen, dessen Wert einer von REI 30, REI 60, REI 90 oder REI 120 ist.

Dieser Schritt ist der schwierigste, und er hat nichts mit Software zu tun. Er zwingt dazu, den Satz zu Ende zu denken. Die meisten Pflichtenhefte enthalten Dutzende Sätze, die diesen Schritt nie durchlaufen haben.

Schritt 2: Die Regel als IDS abbilden. Stark verkürzt sieht das so aus:

<specification name="Tragende Wände — Feuerwiderstand" ifcVersion="IFC4">
  <applicability>
    <entity><name><simpleValue>IFCWALL</simpleValue></name></entity>
    <property>
      <propertySet><simpleValue>Pset_WallCommon</simpleValue></propertySet>
      <baseName><simpleValue>LoadBearing</simpleValue></baseName>
      <value><simpleValue>true</simpleValue></value>
    </property>
  </applicability>
  <requirements>
    <property>
      <propertySet><simpleValue>Pset_WallCommon</simpleValue></propertySet>
      <baseName><simpleValue>FireRating</simpleValue></baseName>
      <value>
        <xs:restriction base="xs:string">
          <xs:enumeration value="REI 30"/>
          <xs:enumeration value="REI 60"/>
          <xs:enumeration value="REI 90"/>
          <xs:enumeration value="REI 120"/>
        </xs:restriction>
      </value>
    </property>
  </requirements>
</specification>

Niemand muss das von Hand schreiben. Regeleditoren erzeugen das XML im Hintergrund. Aber es lohnt sich, es einmal gesehen zu haben: Was oben steht, ist exakt der Satz von Seite 14 — nur ohne Spielraum.

Schritt 3: Die Regel auf ein Modell anwenden. Ein Prüfwerkzeug liest IFC und IDS, geht alle Wände durch, filtert die tragenden heraus und prüft jede auf das geforderte Property. Das Ergebnis ist ein Bericht pro Objekt: erfüllt, nicht erfüllt, mit Begründung. Was vorher zwei Stunden Klicken war, dauert Sekunden — und ist bei der fünften Lieferung identisch mit der vierten.

4. Was IDS leistet

Drei Dinge, die sich im Projektalltag bemerkbar machen.

Wiederholbarkeit. Dieselbe IDS-Datei, jede Lieferung, dasselbe Ergebnis. Keine Tagesform, keine Ermüdung bei der dritten Datei, kein „habe ich letztes Mal anders gelesen".

Eindeutigkeit. Eine Anforderung in IDS hat keinen Interpretationsspielraum. Entweder die Eigenschaft ist da und der Wert liegt in der Liste, oder nicht. Diskussionen in der Abnahmesitzung verlagern sich von „was gemeint war" zu „was vereinbart wurde" — und das ist die bessere Diskussion.

Übertragbarkeit. Eine IDS-Datei ist Standard. Sie funktioniert in jedem Werkzeug, das IDS 1.0 unterstützt. Ein Büro, das seine Anforderungen einmal in IDS gefasst hat, nimmt sie von Projekt zu Projekt mit. Die Datei wird mit jedem Projekt besser, und sie gehört dem Büro, nicht dem Werkzeughersteller.

In der Praxis werden solche Prüfungen mit spezialisierten IFC- und IDS-Werkzeugen durchgeführt. IFCLint ist ein Beispiel für einen browserbasierten Ansatz, bei dem IDS-Dateien erstellt, Modelle damit geprüft und die Ergebnisse als Bericht ausgegeben werden.

5. Was IDS bewusst nicht leistet

Hier ist Genauigkeit wichtig, weil IDS oft weiter gefasst wird, als es ist.

IDS prüft Strukturen und Werte — Klassen, Eigenschaften, Klassifikationen, Materialien, Zugehörigkeiten. Es prüft keine Geometrie. Ob eine Tür breit genug ist, ob zwei Rohre kollidieren, ob eine Wand mindestens zwölf Zentimeter dick ist, lässt sich in IDS nicht formulieren. Dafür braucht es Werkzeuge mit eigener Geometrie-Engine.

Daraus folgt eine Einordnung, die oft fehlt: IDS ist nicht die vollständige maschinenlesbare Form des Rahmenwerks zur Informationsbedarfstiefe. Von dessen drei Säulen — geometrische Informationen, alphanumerische Informationen, Dokumentation — deckt IDS die alphanumerische ab. Die normative Form für das Ganze ist ISO 7817-3 und befindet sich noch in Entwicklung. Wer sagt, IDS sei „die Umsetzung von LOIN", hat zwei Drittel weggelassen.

Das ist keine Schwäche. Es ist eine Abgrenzung, und sie ist sinnvoll: IDS tut eine Sache und tut sie eindeutig. Für die anderen Aufgaben gibt es andere Werkzeuge — meist die, die im Projekt ohnehin laufen.

6. Beispiel: Zehn Regeln, die ein Projekt tragen

Ein Verwaltungsbau, drei Fachplaner. Statt eines Pflichtenhefts mit vierzig Seiten erhält jeder Beteiligte eine IDS-Datei mit zehn Spezifikationen. Die ersten fünf gelten für alle Disziplinen, die übrigen jeweils für eine.

Für alle: Jedes Bauteil hängt an einem Geschoss. Jedes Bauteil hat einen gesetzten PredefinedType. Jede Wand, Decke, Stütze trägt IsExternal und LoadBearing. Jedes Bauteil hat einen Klassifikationscode nach dem vereinbarten System. Kein Bauteil ist ein IfcBuildingElementProxy.

Für die Architektur: Tragende Wände tragen FireRating. Türen tragen eine Angabe zur Feuerwiderstandsdauer.

Für das Tragwerk: Stützen und Träger tragen eine Materialzuweisung. Fundamente sind als IfcFooting klassifiziert, nicht als Decke.

Für die Haustechnik: Jedes Anlagenbauteil gehört zu einem System.

Das ist alles. Zehn Regeln, jede in einer Minute lesbar, jede in Sekunden prüfbar. Die Erfahrung aus solchen Projekten: Die ersten zwei Lieferungen scheitern an sechs bis acht Regeln. Ab der dritten laufen fast alle durch, weil die Fachplaner ihre Exporteinstellungen angepasst haben — einmal, nicht bei jeder Lieferung neu.

7. Typische Fehler

Pflichtenheft-Sätze ungeprüft übernehmen. Ein Satz, der nicht zu Ende gedacht ist, wird in IDS nicht besser — er wird nur schneller als unklar erkannt.
Zu viele Regeln auf einmal. Zweihundert Spezifikationen in der ersten Lieferung bringen zweihundert Fehlermeldungen und keine Verbesserung. Zehn bis fünfzehn, dann wachsen.
Geometrie in IDS erwarten. Mindestabstände, Durchgangsbreiten, Kollisionen — nicht in IDS. Wer es dort sucht, sucht am falschen Ort.
Property-Namen frei erfinden. Feuerwiderstand, Brandschutzklasse, FireRating sind drei verschiedene Dinge. Standardisierte Property Sets verwenden, wo es sie gibt; eigene dokumentieren.
IDS ohne IFC-Version denken. Eine IDS-Datei gilt für eine IFC-Version. Wer IFC4-Regeln auf eine IFC2x3-Datei anwendet, bekommt Fehler, die nichts mit dem Modell zu tun haben.
Die Datei nicht als Asset behandeln. Eine gepflegte IDS-Bibliothek ist Bürowissen in prüfbarer Form. Sie gehört versioniert, dokumentiert und von Projekt zu Projekt weitergetragen.

8. Mini-Checkliste

Bevor eine IDS-Datei ins Projekt geht:

Ist jede Anforderung zu Ende gedacht — Klasse, Property Set, Property, erlaubte Werte?
Ist die IFC-Version in der Spezifikation gesetzt und passt sie zur Liefervereinbarung?
Werden standardisierte Property Sets verwendet, wo es sie gibt?
Sind projektspezifische Property Sets dokumentiert und mit den Lieferanten abgestimmt?
Ist die Anzahl der Regeln für den Start überschaubar?
Ist klar, wer bei einem Fehlbefund zuständig ist und wie er zurückgemeldet wird?

Sind drei oder mehr Punkte offen, wird die erste Prüfung mehr Fragen aufwerfen als beantworten — nicht wegen des Modells, sondern wegen der Regeln.

9. Reflexionsfrage

Nimm einen beliebigen Satz aus einem Pflichtenheft, das du kennst, und versuche, ihn als IDS-Spezifikation zu formulieren: Auf welche Objekte zielt er? Welches Property Set, welche Eigenschaft, welche Werte?

Falls das nicht in zwei Minuten geht, liegt es selten an IDS. Es liegt am Satz. Und das ist die eigentliche Erkenntnis: IDS ist nicht nur ein Prüfformat. Es ist ein Test dafür, ob eine Anforderung überhaupt eine ist.

Merksätze

IDS ist der buildingSMART-Standard, um Informationsanforderungen maschinenlesbar und prüfbar zu machen — nicht mehr, aber auch nicht weniger.

Eine Spezifikation hat zwei Teile: Anwendbarkeit filtert, Anforderungen fordern. Beide sprechen dieselbe Sprache, die Facetten.

IDS prüft Strukturen und Werte, keine Geometrie. Es deckt die alphanumerische Säule der Informationsbedarfstiefe ab, nicht das Ganze.

Zehn gute Regeln bringen mehr als hundert Seiten Text — weil sie bei jeder Lieferung gleich geprüft werden.

Quellen und weiterführende Literatur

buildingSMART — Information Delivery Specification (IDS): buildingsmart.org/standards/bsi-standards/information-delivery-specification-ids
buildingSMART — IDS Technical Project: technical.buildingsmart.org/projects/information-delivery-specification-ids
buildingSMART — IDS auf GitHub (Schema, Beispiele): github.com/buildingSMART/IDS
buildingSMART — Industry Foundation Classes (IFC): technical.buildingsmart.org/standards/ifc
Akbas et al. (2025) — vergleichende Untersuchung zu IDS und LOINXML, ITcon Vol. 30.