Zurück zum BIM- & IFC-Blog
Validierung · 2026-10-01 · 12 Min.
IDS erklärt: So prüfen Sie ein IFC-Modell gegen eine Information Delivery Specification
IDS macht aus „das Modell muss die Feuerwiderstandsklasse enthalten“ – einem Satz in einem PDF – eine Datei, die eine Maschine prüfen kann. Was die sechs Facetten wirklich testen, wo die meisten IDS-Dateien scheitern und wie Sie eine gegen Ihr IFC im Browser ausführen.
IDS erklärt: So prüfen Sie ein IFC-Modell gegen eine Information Delivery Specification — IFC Viewer Online article cover
Jede je geschriebene AIA enthält einen Satz wie „alle Türen müssen ihre Feuerwiderstandsklasse ausweisen“. Und in jedem Projekt wird dieser Satz gleich geprüft: Jemand öffnet das Modell, klickt ein paar Türen an und beschließt, dass es wohl passt. Die Anforderung ist präzise. Die Prüfung ist ein Bauchgefühl.
IDS – die Information Delivery Specification – schließt genau diese Lücke. Es ist ein kleines XML-Format, von buildingSMART als IDS 1.0 standardisiert, das Informationsanforderungen so formuliert, dass eine Maschine sie testen kann. Anforderung einmal schreiben, die .ids-Datei jedem Auftragnehmer geben – und aus „passt wohl“ wird „412 von 418 Türen bestehen; hier sind die sechs, die es nicht tun“.
Das Wichtigste
- IDS prüft Informationen, nicht Geometrie: Klassen, Attribute, Eigenschaften, Klassifikationen, Materialien und Beziehungen.
- Jede Spezifikation hat zwei Hälften – für welche Elemente sie gilt und was diese Elemente haben müssen. Die meisten fehlerhaften IDS-Dateien scheitern an der ersten Hälfte.
- Eine IDS ist ein Vertragsdokument. Sie gehört versioniert neben den BAP und wird vor Modellierungsbeginn verschickt, nicht nach der ersten Zurückweisung.
Anatomie einer Spezifikation
Eine IDS-Spezifikation liest sich wie ein Satz: Für jedes Element, das zur Anwendbarkeit passt, verlange die Anforderungen.
Eine IDS-Datei ist eine Liste von Spezifikationen. Jede liest sich wie ein Satz mit Subjekt und Prädikat: „Für jedes Element, das hierauf passt, verlange jenes.“ Das Subjekt ist die Anwendbarkeit, das Prädikat sind die Anforderungen.
<specification name="Doors carry a fire rating" ifcVersion="IFC4">
<applicability minOccurs="1">
<entity><name><simpleValue>IFCDOOR</simpleValue></name></entity>
</applicability>
<requirements>
<property dataType="IFCLABEL">
<propertySet><simpleValue>Pset_DoorCommon</simpleValue></propertySet>
<baseName><simpleValue>FireRating</simpleValue></baseName>
</property>
</requirements>
</specification>
Laut gelesen ist es genau der AIA-Satz: Jede IfcDoor muss ein FireRating in Pset_DoorCommon haben, gespeichert als Label. Das minOccurs="1" in der Anwendbarkeit fügt eine zweite, leicht übersehene Aussage hinzu: Das Modell muss mindestens eine Tür enthalten. Ohne sie besteht ein Modell ganz ohne Türen – was selten gemeint war.
Die sechs Facetten und was jede wirklich prüft
| Facette | Prüft | Typische Anforderung | Häufige Falle |
|---|
| Entity | IFC-Klasse und vordefinierter Typ | Wände sind IfcWall, nicht IfcBuildingElementProxy | Subtypen vergessen: IfcWallStandardCase ist in IFC2x3 eine IfcWall |
| Attribute | Direkte IFC-Attribute (Name, Description, Tag…) | Jeder Raum hat Name und LongName | Ein leerer String ist vorhanden, aber ungültig – nicht fehlend |
| Property | Eine Eigenschaft in einem Property Set, mit Datentyp und Wert | Pset_WallCommon.IsExternal ist TRUE oder FALSE | Richtiger Wert, falscher Datentyp (ein Label statt eines Booleans) |
| Classification | Eine Klassifikationsreferenz und ihr Code | Jedes Element hat einen Uniclass-Ss-Code | Den Code prüfen, aber nicht das System, zu dem er gehört |
| Material | Ein zugeordneter Materialname oder eine Materialkategorie | Tragende Stützen deklarieren ein Material | Materialien am Typ, nicht an der Instanz |
| PartOf | Eine Beziehung zu einem übergeordneten Element | Jedes Element ist einem Geschoss zugeordnet | Aggregation mit räumlicher Zuordnung verwechseln |
Jede Facette kann in der Anwendbarkeit (zur Auswahl von Elementen) oder in den Anforderungen (um etwas von ihnen zu verlangen) stehen.Zwei dieser Fallen verdienen einen genaueren Blick, denn sie erklären die meisten Fehlalarme, die beim ersten IDS-Lauf gemeldet werden.
Typ oder Instanz
Eigenschaften können am Typ statt an der Instanz hängen. Ein IDS-Prüfwerkzeug muss dem Typ folgen, sonst lässt es korrekte Elemente durchfallen.
Revit, ArchiCAD und Tekla schreiben Eigenschaften und Materialien routinemäßig an das Typobjekt (IfcWallType) statt an jede einzelne Wand. Die IDS-Semantik ist eindeutig: Vom Typ geerbte Informationen zählen für die Instanz. Ein Prüfwerkzeug, das nur die Instanz betrachtet, lässt in einem einwandfreien Modell jede Wand durchfallen. Meldet ein IDS-Lauf, dass 100 % Ihrer Elemente eine Eigenschaft nicht haben, die Sie im Eigenschaftenfenster sehen, ist das fast immer der Grund – und der Fehler liegt beim Prüfwerkzeug, nicht bei Ihnen.
Vordefinierte Typen mit USERDEFINED
Ist ein vordefinierter Typ USERDEFINED, steht der eigentliche Typ in ObjectType (an Instanzen) oder ElementType (an Typen). Eine Entity-Facette, die IFCWALL mit dem vordefinierten Typ PARAPET verlangt, muss auf eine Wand passen, deren PredefinedType USERDEFINED und deren ObjectType PARAPET ist. Werkzeuge, die die rohe Enumeration vergleichen, übersehen sie alle.
Fünf Fehler, die eine IDS nutzlos machen
- Zu breite Anwendbarkeit. „Alle Elemente müssen einen Uniclass-Code haben“ erfasst Öffnungen, Annotationen und räumliche Elemente, die niemand klassifiziert. Beschränken Sie Spezifikationen auf die Klassen, um die es in der Anforderung wirklich geht.
- Werte ohne Datentyp. Eine Anforderung FireRating = „EI 60“ sagt nichts darüber, wie der Wert gespeichert sein muss; derselbe Text als Beschreibung in einem anderen Pset fällt trotzdem durch. Sagen Sie, was Sie meinen – einschließlich Datentyp.
- Exakte Werte, wo ein Muster gemeint war. Echte Daten enthalten „EI60“, „EI 60“ und „EI-60“. Verwenden Sie ein xs:pattern oder eine Aufzählung und legen Sie die kanonische Schreibweise im BAP fest.
- Eine einzige Riesenspezifikation. Vierzig Anforderungen in einer Spezifikation ergeben ein einziges Bestanden/Nicht bestanden pro Element und einen Bericht, mit dem niemand arbeiten kann. Eine Anforderung pro Spezifikation, verständlich benannt, macht das Ergebnis lesbar.
- Die IDS nach dem Modell schreiben. Eine IDS, die mit der ersten Zurückweisung kommt, ist eine neue Anforderung. Eine IDS, die mit der Beauftragung kommt, ist eine Anforderung. Nur die zweite ist durchsetzbar.
Die vertragliche Seite dieses letzten Punkts – welche Klauseln eine IDS verbindlich machen und was passiert, wenn eine Lieferung sie nicht erfüllt – behandeln BAP-Klauseln, die schlechte IFC-Lieferungen wirklich verhindern und IFC-Abnahmekriterien.
Eine IDS gegen Ihr Modell ausführen – Schritt für Schritt
- IFC öffnen Ziehen Sie das Modell in den Viewer. Es wird in Ihrem Browser verarbeitet; nichts wird hochgeladen.
- .ids-Datei laden Öffnen Sie das IDS-Panel und wählen Sie Ihre Datei – oder starten Sie mit einer der mitgelieferten Beispielspezifikationen, wenn Sie das Format erst kennenlernen möchten.
- Prüfung starten Jede Spezifikation wird mit allen sechs Facetten ausgewertet. Große Modelle zeigen den Fortschritt nach Phasen an und lassen sich jederzeit abbrechen.
- Ergebnis nach Spezifikation, Element oder Klasse lesen Gruppieren Sie Fehler so, wie Sie sie beheben wollen. Jeder Fehler nennt seinen Grund im Klartext: Eigenschaft fehlt, falscher Wert, falscher Datentyp, falsche Klasse.
- In 3D ansehen Hervorheben färbt fehlerhafte Elemente im Modell ein; Isolieren blendet alles andere aus. Beides ist ein Klick – und so wird aus einer Liste von GlobalIds ein Gespräch mit dem Modellierer.
IDS über Revisionen hinweg
Ein einzelner IDS-Lauf ist eine Momentaufnahme. Was ein Koordinator wirklich braucht, ist der Verlauf: Hat Revision 7 die Fehler aus Revision 6 behoben, und hat sie neue eingeführt? Da das Ergebnis nach GlobalId geschlüsselt ist, lässt sich dieselbe Spezifikation über zwei Modellversionen vergleichen – was nur funktioniert, wenn Ihre GlobalIds zwischen Exporten stabil sind. Sind sie es nicht, beheben Sie das zuerst: warum sich IFC-GUIDs bei jedem Export ändern. Den Vergleich selbst behandelt zwei Versionen eines IFC-Modells vergleichen.
Wo IDS aufhört
IDS prüft keine Geometrie. Es sagt Ihnen nicht, dass zwei Kanäle kollidieren, dass eine Tür für einen Rollstuhl zu schmal ist oder dass das Modell zwei Kilometer neben seinem Vermessungspunkt liegt. Es prüft auch nicht, ob ein IFC strukturell intakt ist – eine Datei mit doppelten GlobalIds oder defekten Platzierungen kann eine IDS fehlerfrei bestehen.
Das ist keine Schwäche, sondern Umfang. Nutzen Sie IDS für Informationsanforderungen, einen Model Checker für Struktur und Geometrie, und legen Sie beide Berichte der Lieferung bei. Den gesamten Ablauf beschreibt eine IFC-Datei validieren.
IDS erklärt: So prüfen Sie ein IFC-Modell gegen eine Information Delivery Specification