Zurück zum BIM- & IFC-Blog
Validierung · 2026-06-28 · 20 Min.
IFC Model Checker: Der vollständige Leitfaden zu IFC-Validierung, Modellqualität und IDS
Leitfaden zum IFC Model Checker: Schema, Modellqualität (44 Regeln + Health Score) und IDS sind drei unabhängige Ebenen. Wer sie verwechselt, riskiert gescheiterte Lieferungen. Die vollständige Aufschlüsselung für BIM-Koordinatoren.
IFC Model Checker: Der vollständige Leitfaden zu IFC-Validierung, Modellqualität und IDS — IFC Viewer Online article cover
- 3 — unabhängige Validierungsebenen
- 44 — Modellqualitätsregeln
- 6 — IDS-Facetten (buildingSMART 1.0)
- 0 — hochgeladene Bytes – nur im Browser
Jedes Gespräch über eine IFC-Lieferung stößt irgendwann an dieselbe Wand. Der Tragwerksplaner sagt, die Datei habe den Validator bestanden. Der BIM-Koordinator sieht, dass die Hälfte der Eigenschaftssätze fehlt, und fragt, welcher Validator gemeint war. Die Auftraggeber-Informationsanforderungen (AIA) des Kunden legen IDS-Anforderungen fest, die niemand geprüft hat. Die gemeinsame Datenumgebung (CDE) weist den Upload zurück. Drei Wochen später ist allen unklar, was „valide“ überhaupt bedeutet.
Die Verwirrung ist verständlich – das Wort „Validierung“ beschreibt drei völlig unterschiedliche Vorgänge, die sich nur den Namen teilen. Sie zu entwirren ist eine der folgenreichsten Aufgaben, die ein BIM-Koordinator für ein Projekt übernehmen kann.
Drei völlig unterschiedliche Validierungsprobleme
Denken Sie an einen Bauantrag. Der Bauamtsmitarbeiter prüft unabhängig voneinander drei Dinge: ob die Pläne lesbar und vollständig sind (Dateiintegrität), ob der Entwurf die Bauvorschriften erfüllt (Qualität und Konformität) und ob er die spezifischen Vorgaben des Auftraggebers erfüllt (Projektanforderungen). Ein lesbarer Plan kann die Brandschutzvorschriften komplett ignorieren. Ein brandschutzkonformer Entwurf kann die akustischen Vorgaben des Auftraggebers völlig verfehlen. Das sind getrennte Fragen mit getrennten Antworten.
Level 1 — IFC-Integrität
Ist die Datei ein gültiges IFC gemäß ISO 10303-21 und ISO 16739-1? Sind die GlobalIds eindeutig und formatkonform? Ist die räumliche Hierarchie stimmig? Binäre Prüfung auf Schemaebene.
Level 2 — Modellqualität
Sind die Daten für die Koordination tatsächlich brauchbar? Sind die Eigenschaftssätze befüllt? Folgen die Elemente den Namenskonventionen? Sind Klassifizierungen vorhanden? Das ist maßgeblich für reale Lieferungen – nicht die Schemakonformität.
Level 3 — IDS-Validierung
Erfüllt das Modell die vertraglichen Informationsanforderungen dieses Projekts? AIA- und AIR-Anforderungen (AIR: Asset-Informationsanforderungen) werden als maschinenlesbare IDS-Spezifikationen kodiert und facettenweise gegen jedes Element geprüft.
Diese drei Ebenen sind völlig unabhängig voneinander. Eine Datei kann nach Level 1 schemakonform sein und trotzdem für die Koordination unbrauchbar, weil keine Eigenschaftssätze exportiert wurden. Eine IDS-Prüfung kann für alle deklarierten Anforderungen bestehen, während das Modell 400 doppelte GUIDs enthält. Ein Health Score von 91 sagt nichts darüber aus, ob die Brandschutzanforderungen des Auftraggebers kodiert und erfüllt sind. Jede Ebene beantwortet eine andere Frage – alle drei werden vor einer formalen Lieferung benötigt.
Level 1: IFC-Dateiintegrität – Ist das eine gültige IFC-Datei?
Level 1 ist die Schemaprüfung. Sie beantwortet eine binäre Frage: Entspricht diese Datei dem IFC-Schema (ISO 16739-1) und dem physischen Dateiformat (ISO 10303-21 STEP)? Die meisten IFC-Parser akzeptieren Dateien, die die Level-1-Prüfung nicht bestehen, stillschweigend – sie sind bewusst tolerant konzipiert, weil eine strikte Zurückweisung zu viele Arbeitsabläufe stören würde. Diese Toleranz verbirgt den Schaden, bis er weiter unten in der Kette sichtbar wird.
Was die Level-1-Integritätsprüfung abdeckt
- Eindeutigkeit der GlobalId: Jede IfcRoot-Entität muss eine eindeutige, 22 Zeichen lange GlobalId nach dem Base-64-Alphabet von IFC besitzen. Doppelte GlobalIds sind ein Schemaverstoß, den Parser akzeptieren, der aber BCF-Workflows, die CDE-Versionierung und FM-Anlagenregister stillschweigend beschädigt.
- Formatkonformität der GlobalId: Das erste Zeichen einer gültigen IFC-GlobalId kodiert nur die Werte 0–3 (zwei signifikante Bits einer 128-Bit-UUID). Skripte, die UUIDs naiv abschneiden, erzeugen ein führendes Zeichen außerhalb dieses Bereichs – laut Spezifikation ungültig, von den meisten Parsern toleriert, von strengen Validatoren abgelehnt.
- Vollständigkeit der räumlichen Hierarchie: Das IFC-Schema schreibt IfcProject → IfcSite → IfcBuilding → IfcBuildingStorey vor. Fehlende Knoten (ein Building direkt unter Project, physische Elemente direkt in IfcSite) sind Schemaverstöße mit realen Folgen für die nachgelagerten Prozesse.
- Integrität der IfcRelAggregates-Kette: Die Beziehungsentitäten, die den räumlichen Baum aufbauen, müssen auf existierende Entitäten verweisen. Verwaiste Referenzen – bei denen eine Beziehung auf eine gelöschte oder fehlende Entität zeigt – zerstören die Baumnavigation in jedem nachgelagerten Tool.
- IfcRelContainedInSpatialStructure: Physische Elemente müssen einem räumlichen Element zugeordnet sein (typischerweise IfcBuildingStorey). Elemente ohne Containment-Beziehung sind verwaist – in der räumlichen Navigation der meisten Tools unsichtbar.
- Genau ein IfcProject: Jede gültige IFC-Datei muss genau ein IfcProject als Wurzel der Hierarchie enthalten. Teilmodelle, die es weglassen, lassen sich fehlerfrei parsen, haben aber keinen räumlichen Anker.
- FILE_NAME- und FILE_DESCRIPTION-Kopffelder: Der STEP-Dateikopf trägt Metadaten zur Nachverfolgbarkeit. ISO 19650-2 verlangt, dass diese befüllt sind – die meisten Tools lassen sie als leere Zeichenketten stehen.
- Geometriegültigkeit: nicht-mannigfaltige Meshes, Flächen mit Nullfläche, Körper mit umgekehrter Normalenausrichtung, selbstüberschneidende Randdarstellungen, die in empfangenden Tools keine gültigen Volumenkörper ergeben.
Was Level 1 NICHT prüft
- Ob Eigenschaftssätze befüllt oder korrekt sind – ein schemakonformes Modell ohne einen einzigen Pset besteht Level 1.
- Ob Elementnamen irgendeiner projektspezifischen Namenskonvention folgen.
- Ob Klassifizierungscodes vorhanden, korrekt oder konsistent sind.
- Ob Mengenanforderungen für den LOD (IfcElementQuantity ab LOD 300) erfüllt sind.
- Ob das Modell irgendeine projektspezifische oder vertragliche Informationsanforderung erfüllt.
Der buildingSMART Validation Service für Level 1
Der buildingSMART IFC Validation Service (validate.buildingsmart.org) ist die maßgebliche Referenz für die Schemakonformität nach Level 1 – er nutzt dieselbe Engine, die auch für die Zertifizierung von IFC-Software eingesetzt wird. Nutzen Sie ihn, wenn: Sie die IFC-Ausgabe eines eigenen Exporters zertifizieren müssen, Sie eine Datei untersuchen, die von verschiedenen Parsern uneinheitlich behandelt wird, oder eine Vertragsklausel ausdrücklich ein buildingSMART-Schemazertifikat verlangt.
Was er nicht tut: Datenqualität prüfen, Namenskonventionen validieren, die Vollständigkeit von Eigenschaftssätzen kontrollieren, ISO-19650-Metadatenfelder prüfen oder beurteilen, ob das Modell irgendeine Projektanforderung erfüllt. Er ist ein Schema-Werkzeug, kein Freigabetor für die Projektlieferung.
Untersuchen Sie ein komplexes IFC-Modell aus der Praxis – alle drei Validierungsebenen
Ein mehrgeschossiges Bürogebäude, exportiert aus Revit. Öffnen Sie den Reiter „Validierung“, um den vollständigen 44-Regel-Qualitätsbericht und den Health Score zu sehen. Laden Sie anschließend eine IDS-Spezifikation, um die Level-3-Prüfung am selben Modell zu erleben.
IFC4 · 14 MB
Interaktiven IFC-Viewer öffnen
Level 2: Modellqualitätsprüfung – die Ebene, die Lieferungen tatsächlich bestimmt
Die Modellqualitätsprüfung ist die Ebene, die die meisten BIM-Koordinatoren meinen, wenn sie von „IFC-Validierung“ sprechen – auch wenn sie sie selten so nennen. Sie beantwortet praktische Fragen: Sind die Daten vorhanden? Sind sie korrekt? Sind sie konsistent? Kann jemand weiter unten in der Kette dieses Modell tatsächlich für Koordination, Kostenplanung oder FM nutzen?
Anders als Level 1 ist die Qualitätsprüfung nicht binär. Ein Modell besteht nicht einfach oder fällt durch – es hat ein Qualitätsprofil über Dutzende Dimensionen hinweg. Der Health Score (0–100) fasst diese Dimensionen zu einer einzigen Zahl zusammen, die sich in den BIM-Abwicklungsplan (BAP) schreiben, über Revisionen hinweg verfolgen und Transmittals als Nachweis der Lieferqualität beifügen lässt.
Was die 44-Regel-Qualitätsprüfung abdeckt
Zentrale Strukturregeln (18)
Doppelte GUIDs, verwaiste Elemente, falsches Containment, defekte Aggregate, fehlendes IfcProject, leere Elementnamen, ungültige Geschosszuordnung. Die Regeln, die in der Praxis die meisten CDE-Ablehnungen verursachen.
Räumliche Struktur + Dateikopf (11)
ISO-19650-Metadatenfelder am IfcProject, Befüllung von Autor und Organisation in FILE_NAME, Standortplatzierung gegenüber gemeinsamen Koordinaten, Zuordnung von Elementen zu Geschossen, Vollständigkeit der Geschosse.
LOD, Klassifizierung, MEP (9)
Vorhandensein von IfcElementQuantity ab LOD 300, IfcRelAssociatesClassification an Tragwerks- und Architekturelementen, Konnektivität der MEP-Systeme, übermäßige Nutzung von Proxy-Elementen (IfcBuildingElementProxy als Anteil am Modell in %).
Geometrie + Geschossintegrität (6)
Gültigkeit der Bounding-Box von Elementen, korrekte Reihenfolge der Geschosshöhen, Elemente unterhalb der Geländeebene, fehlende Bodenplatte im Geschoss, Versatz des Koordinatenursprungs zum WCS, Kollisionsprüfung (optionale Regel, standardmäßig deaktiviert).
Der Health Score: Modellqualität als einzelne Kennzahl
Der Health Score nutzt eine logarithmische Gewichtung der Abzüge. Schemafehler wiegen dreimal so schwer wie Warnungen; Warnungen wiegen dreimal so schwer wie Hinweise. Das 1.000. Vorkommen desselben Problems zieht deutlich weniger Punkte ab als das 10. – so wird verhindert, dass große, dichte Modelle bei gleicher zugrunde liegender Problemdichte willkürlich schlechter dastehen als kleine, dünn besetzte Modelle. Ein Modell mit 800 Namenswarnungen kann einen Score von 83 erreichen; ein Modell mit 12 defekten räumlichen Referenzen erreicht 41. Ausschlaggebend für den Score ist der Schweregrad, nicht die Menge.
- 31/100 — Kritisch – strukturelle Fehler, nicht liefern
- 58/100 — Schlecht – erhebliche Nacharbeit erforderlich
- 74/100 — Mittelmäßig – nur für interne Prüfungen akzeptabel
- 87/100 — Gut – bereit für die Lieferung in die CDE
- 96/100 — Exzellent – Qualität für ISO-19650-Meilensteine
Was die Modellqualitätsprüfung NICHT leistet
- Projektspezifische Informationsanforderungen prüfen – das ist Level 3 (IDS). Die Qualitätsregeln sind generische Best-Practice-Prüfungen, keine AIA.
- Das Modell reparieren – die Qualitätsprüfung erzeugt einen Bericht. Die Nacharbeit erfolgt in der Autorensoftware oder, für Eigenschafts- und GUID-Korrekturen, in einem IFC-Eigenschaftseditor.
- Das Schemakonformitätszertifikat liefern, das die Zertifizierungsprogramme von buildingSMART verlangen – das ist Level 1 über den buildingSMART Validation Service.
- Ihnen sagen, ob das Modell geometrisch korrekt ist – einige Prüfungen der Geometrieintegrität sind enthalten, aber ein Qualitätsprüfer ist kein Werkzeug für Kollisionsprüfung oder BIM-Modellierung.
Level 3: IDS-Validierung – Austauschanforderungen als maschinenlesbarer Code
IDS (Information Delivery Specification) ist ein buildingSMART-Standard zur Kodierung projektspezifischer Informationsanforderungen in einem maschinenlesbaren XML-Format. Es ist das fehlende Bindeglied zwischen einer AIA – die als Word-Dokument vorliegt – und einer Validierungs-Engine, die ein Modell systematisch dagegen prüfen kann. IDS 1.0 wurde 2023 offizieller buildingSMART-Standard.
Was buildingSMART IDS eigentlich ist
Eine IDS-Datei ist ein XML-Dokument, das eine oder mehrere Spezifikationen enthält. Jede Spezifikation hat einen Anwendbarkeitsbereich (auf welche Elemente trifft das zu?) und einen Anforderungsbereich (was müssen diese Elemente aufweisen?). Die Engine prüft jedes Element im Modell, das die Anwendbarkeitskriterien erfüllt, kontrolliert, ob es alle Anforderungen erfüllt, und meldet bestanden oder nicht bestanden – pro Element, pro Spezifikation. Das Ergebnis ist eine maschinell erzeugte Nachweiskette der vertraglichen Konformität.
Die buildingSMART-Referenztestsuite enthält 100 offizielle Testfälle, die das erwartete Verhalten jeder konformen IDS-Engine definieren – sie sind die Spezifikation in ausführbarer Form. Eine IDS-Engine, die alle 100 Testfälle besteht, hat nachgewiesen, dass sie .ids-Spezifikationen standardkonform interpretiert.
Die sechs IDS-Facetten
- Entity: Schränkt Anwendbarkeit oder Anforderungen nach IFC-Entitätstyp ein (IFCWALL, IFCDOOR, IFCBEAM), optional auch nach vordefiniertem Typ. Das ist der Filter, mit dem die meisten Spezifikationen beginnen.
- Attribute: Prüft IFC-Attributwerte, die direkt an der Entität sitzen – Name, Description, ObjectType, Tag, PredefinedType. Attribute unterscheiden sich von Eigenschaftssätzen und werden anders geprüft.
- Property: Prüft eine benannte Eigenschaft innerhalb eines benannten Eigenschaftssatzes (Pset_WallCommon.FireRating, Pset_DoorCommon.IsExternal). Die am häufigsten genutzte Facette. Unterstützt Einschränkungen des Datentyps und Musterabgleich bei Werten.
- Classification: Prüft, ob Elemente über IfcRelAssociatesClassification eine Klassifizierungsreferenz tragen – Uniclass 2015, OmniClass, NBS oder ein eigenes Schema. Kann den Namen des Klassifizierungssystems und das Codemuster einschränken.
- Material: Prüft, ob Elementen über IfcMaterial, IfcMaterialLayerSet oder IfcMaterialConstituentSet ein Material zugewiesen ist. Kann optional den Materialnamen einschränken – nützlich für Brandschutz- oder Nachhaltigkeitsanforderungen.
- PartOf: Prüft, ob Elemente an einer geforderten räumlichen oder logischen Beziehung teilhaben – einem Geschoss zugeordnet, in ein Gebäudesystem aggregiert, in einem bestimmten Gebäude verortet. Die Facette, die die Einhaltung der räumlichen Hierarchie für bestimmte Elementtypen durchsetzt.
<?xml version="1.0" encoding="UTF-8"?>
<ids:ids xmlns:ids="http://standards.buildingsmart.org/IDS"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://standards.buildingsmart.org/IDS ids_09.xsd">
<ids:info>
<ids:title>Stage 3 Architecture — EIR Data Requirements</ids:title>
<ids:description>Fire safety and classification requirements.</ids:description>
<ids:ifcVersion>IFC4</ids:ifcVersion>
</ids:info>
<ids:specifications>
<!-- All walls must carry a fire rating property -->
<ids:specification name="Wall FireRating required" minOccurs="1">
<ids:applicability>
<ids:entity>
<ids:name><ids:simpleValue>IFCWALL</ids:simpleValue></ids:name>
</ids:entity>
</ids:applicability>
<ids:requirements>
<ids:property dataType="IFCLABEL">
<ids:propertySet><ids:simpleValue>Pset_WallCommon</ids:simpleValue></ids:propertySet>
<ids:baseName><ids:simpleValue>FireRating</ids:simpleValue></ids:baseName>
</ids:property>
</ids:requirements>
</ids:specification>
<!-- Structural walls must carry a Uniclass 2015 classification -->
<ids:specification name="Structural wall classification" minOccurs="0">
<ids:applicability>
<ids:entity>
<ids:name><ids:simpleValue>IFCWALL</ids:simpleValue></ids:name>
<ids:predefinedType><ids:simpleValue>SOLIDWALL</ids:simpleValue></ids:predefinedType>
</ids:entity>
</ids:applicability>
<ids:requirements>
<ids:classification>
<ids:system><ids:simpleValue>Uniclass 2015</ids:simpleValue></ids:system>
</ids:classification>
</ids:requirements>
</ids:specification>
</ids:specifications>
</ids:ids>
AIA → IDS: Der Übersetzungsschritt, den die meisten Teams überspringen
Eine AIA legt fest, welche Informationen der Auftraggeber benötigt. Eine IDS kodiert diese Anforderungen so, dass eine Maschine sie prüfen kann. Die Übersetzung zwischen beiden ist der Schritt, den fast niemand macht – weil er jemanden erfordert, der sowohl die Informationsanforderungen als auch das IDS-XML-Schema gut genug versteht, um eine Spezifikation zu schreiben, die genau das prüft, was die AIA verlangt, nicht mehr und nicht weniger.
Die Folge: Teams verzichten entweder ganz auf IDS und verlassen sich bei der Lieferung auf eine informelle manuelle Prüfung, oder sie verwenden eine generische IDS-Datei, die ihre tatsächliche AIA nicht widerspiegelt. Beides erzeugt trügerische Sicherheit. Eine IDS-Prüfung, die gegen eine generische Spezifikation besteht, sagt nichts darüber aus, ob die spezifischen Anforderungen Ihres Auftraggebers erfüllt sind.
Profilbasiertes IDS: ein praktischer Ausgangspunkt
Nicht jedes Team schreibt IDS von Grund auf neu. Ein praktischer Ansatz ist es, eine Bibliothek wiederverwendbarer IDS-Profile zu pflegen: eines für die Architektur in Stage 3, eines für MEP in Stage 4, eines für die Tragwerksübergabe. Jedes Profil deckt die häufigsten Anforderungen für diese Phase und dieses Gewerk ab und wird projektspezifisch um kundenspezifische Ergänzungen erweitert. IDS-Profile lassen sich direkt in die Validierungs-Engine laden und kombinieren – Sie können mehrere .ids-Dateien gegen dasselbe Modell laufen lassen und die Ergebnisse zusammenführen.
Wie die drei Ebenen zusammenspielen – die Validierungs-Pipeline
Die drei Ebenen bilden ein Qualitätstor, das ein Modell nacheinander durchläuft. Jede Ebene hat einen eigenen Rhythmus: Level 1 läuft bei jedem Export (eine Plausibilitätsprüfung), Level 2 läuft vor jedem CDE-Upload (das Qualitätstor), Level 3 läuft vor formalen Liefermeilensteinen (die Vertragsprüfung). Sie in falscher Reihenfolge auszuführen verschwendet Zeit – es bringt nichts, IDS gegen eine Datei mit defekter räumlicher Hierarchie laufen zu lassen.
┌──────────────────────────────────────────────────────┐
│ EXPORT IFC from authoring tool │
│ (Revit, ArchiCAD, Tekla, Allplan, Vectorworks…) │
└───────────────────────┬──────────────────────────────┘
│
▼
┌──────────────────────────────────────────────────────┐
│ LEVEL 1 — IFC Integrity │
│ • GlobalId uniqueness & format (leading char 0–3) │
│ • Spatial hierarchy: Project→Site→Building→Storey │
│ • IfcRelAggregates chain integrity │
│ • IfcRelContainedInSpatialStructure (no orphans) │
│ • Exactly one IfcProject │
│ • FILE_NAME header traceability fields │
└─────────┬────────────────────────────────────────────┘
Fail ◄────┤ Fix in authoring tool (or IFC property editor)
│ Pass
▼
┌──────────────────────────────────────────────────────┐
│ LEVEL 2 — Model Quality (44 rules) │
│ • Naming conventions / empty element names │
│ • Property set completeness (Pset_WallCommon etc.) │
│ • ISO 19650 metadata (IfcProject.LongName etc.) │
│ • Classification presence and consistency │
│ • LOD quantity sets, proxy audit, MEP connectivity │
│ → Health Score 0–100 │
└─────────┬────────────────────────────────────────────┘
Score<80 ◄┤ Fix properties / names in IFC editor or authoring tool
│ Score ≥ 80
▼
┌──────────────────────────────────────────────────────┐
│ LEVEL 3 — IDS Validation │
│ • Project-specific EIR / AIR requirements │
│ • .ids specification(s) for this milestone │
│ • Six facets: entity, attribute, property, │
│ classification, material, partOf │
└─────────┬────────────────────────────────────────────┘
Fail ◄────┤ Fix per IDS issue report → export BCF → remediate
│ All requirements met
▼
┌──────────────────────────────────────────────────────┐
│ DELIVER TO CDE │
│ Attach: Health Score report + IDS pass certificate │
└──────────────────────────────────────────────────────┘
Die Vergleichstabelle: Level 1 vs. Level 2 vs. Level 3
| Dimension | L1: IFC-Integrität | L2: Modellqualität | L3: IDS-Validierung |
|---|
| Beantwortete Frage | Ist die Datei ein gültiges IFC-Schema? | Sind die Daten für die Koordination brauchbar? | Erfüllt sie die projektbezogenen Informationsanforderungen? |
| Standard | ISO 10303-21 (STEP), ISO 16739-1 (IFC) | BIM-Best-Practice, ISO-19650-Normen | buildingSMART IDS 1.0 (XML-Schema) |
| Festgelegt von | buildingSMART (festes Schema) | BIM-Team / AIA (projektvereinbarte Regeln) | Auftraggeber (pro Projekt) |
| Ergebnis | Bestanden / nicht bestanden + Liste der Schemafehler | Health Score 0–100 + priorisierte Liste der Probleme | Bestanden / nicht bestanden pro Spezifikation |
| Kann andere ersetzen? | Nein | Nein | Nein – alle drei werden benötigt |
| Rhythmus | Bei jedem IFC-Export | Vor dem CDE-Upload | Vor dem Liefermeilenstein |
| Besteht, fällt aber bei einer anderen Ebene durch? | Keine Psets, keine Namen → L1 bestanden, L2 nicht bestanden | Brandschutzklasse fehlt (IDS-Spezifikation) → L3 nicht bestanden | Doppelte GUIDs, defekte Hierarchie |
| Beispielhafte Tools | bSmart Validator, IFC Viewer Online | IFC Viewer Online, Solibri, IfcOpenShell | IFC Viewer Online (IDS-Engine), Solibri |
Wann Sie den buildingSMART Validation Service nutzen sollten – eine ehrliche Einschätzung
Der buildingSMART IFC Validation Service prüft Dateien gegen das offizielle Schema mithilfe einer mehrteiligen Engine: STEP-Dateisyntax, EXPRESS-Regeln des IFC-Schemas, informelle, aus der Spezifikation abgeleitete Aussageregeln sowie normative IFC-Einschränkungsregeln. Er ist das Referenzwerkzeug für die Schemakonformität nach Level 1.
Nutzen Sie ihn, wenn
- Sie den IFC-Export eines eigenen Exporters zertifizieren: Der buildingSMART-Checker liefert das Referenzergebnis, das für die Software-Zertifizierung verwendet wird. Kein anderes Tool kann dieses Ergebnis im Zertifizierungskontext ersetzen.
- Sie eine uneinheitliche Parser-Behandlung diagnostizieren: Wenn eine Datei in einem Tool sauber öffnet und in einem anderen Fehler wirft, stellt der buildingSMART-Checker fest, welches Verhalten schemakonform ist. Das ist diagnostisch wertvoll, selbst wenn die Datei sonst nutzbar ist.
- Eine Vertragsklausel es verlangt: Manche Beschaffungsspezifikationen verweisen auf die buildingSMART-Schemakonformität als Lieferanforderung. In diesem Fall erfüllt das Zertifikat des offiziellen Dienstes die Klausel.
- Sie eine IDS-Datei selbst validieren: Der buildingSMART-IDS-Schemavalidator prüft, ob Ihre .ids-Datei ein gültiges IDS-Dokument ist – unabhängig davon, ob sie gegen ein Modell ausgeführt wird.
Verwenden Sie ihn nicht als Ersatz für
- Die Modellqualitätsprüfung – der Dienst prüft nicht die Vollständigkeit von Eigenschaftssätzen, Namenskonventionen, Klassifizierung oder irgendeine andere Datenqualitätsregel.
- Die projektspezifische Validierung – Schemakonformität sagt nichts darüber aus, ob das Modell die AIA des Auftraggebers erfüllt.
- Die Bestätigung der Lieferbereitschaft vor der CDE – ein schemakonformes Modell mit leeren Psets und leeren Namen besteht den buildingSMART-Checker und fällt bei jedem sinnvollen Qualitätstor durch.
Cloud-IFC-Validator vs. browserbasierter IFC-Validator
Der Unterschied zwischen Cloud-Validierung (Datei wird auf einen entfernten Server hochgeladen) und browserbasierter Validierung (Datei wird lokal per WebAssembly verarbeitet) ist wichtiger, als die meisten Teams erkennen – besonders bei Behörden-, Verteidigungs- und sensiblen kommerziellen Projekten.
Browserbasierte Validierung
- Die IFC-Datei verlässt das Gerät nie
- DSGVO-konform per Design – keine Datenübertragung
- Funktioniert offline: Baustellenbesuche, eingeschränkte Netzwerke
- Kein Upload-Kontingent und keine Dateigrößenbeschränkung
- Sofortiges Feedback – keine Netzwerklatenz
- Gleichbleibende Leistung, unabhängig von der Serverlast
- Kein Konto, kein API-Schlüssel und kein Abonnement erforderlich
- Funktioniert in eingeschränkten Behördennetzwerken
Cloud-Validierung
- Datei wird zur Verarbeitung auf einen entfernten Server hochgeladen
- Auftragsverarbeitungsvertrag (AVV) nach DSGVO erforderlich
- Geeignet für automatisierte CI/CD-Validierungspipelines
- Zentrales Prüfprotokoll über Projekte und Teams hinweg
- API- und Webhook-Integration für die Automatisierung von Lieferungen
- Skaliert horizontal für die Stapelverarbeitung von Modellen
- Kann headless ohne Browsersitzung laufen
- Ergebnisse über frühere Durchläufe hinweg abfragbar
Wann Cloud-Validierung sinnvoll ist
- Automatisierte CI/CD-Pipelines: wenn die Validierung automatisch ausgelöst werden soll, sobald ein Modell committet oder hochgeladen wird – ähnlich wie Softwareteams bei jedem Code-Push automatisierte Tests ausführen. Cloud-APIs mit Webhooks sind hier die richtige Architektur.
- Organisationsweite Prüfung: wenn ein BIM-Manager eine zentrale Aufzeichnung der Validierungsläufe über mehrere Projekte und Teams hinweg benötigt. Cloud-Dienste können Daten über Durchläufe hinweg aggregieren und Trends aufzeigen – etwas, das lokale Tools nicht leisten.
- Stapelverarbeitung: die Prüfung einer Bibliothek bestehender Modelle – etwa aller IFC-Dateien, die in den letzten zwei Jahren in eine CDE geliefert wurden – ist im Cloud-Batch-Modus praktikabel, manuell im Browser dagegen kaum durchführbar.
- Unkritische Modelle: Bei Projekten, deren Datenschutzanforderungen einen Cloud-Upload nicht ausschließen, bieten Cloud-Validatoren eine CI/CD-Integration, die browserbasierte Tools nicht erreichen.
Wann browserbasiert die bessere Wahl ist
- Behörden- und Verteidigungsprojekte: Modelle für öffentliche Infrastruktur, Verteidigungsanlagen und sicherheitsrelevante Anlagen unterliegen regelmäßig Datenschutzauflagen, die einen Upload zu Drittanbietern ausschließen. Browserbasierte Validierung ist hier die einzige konforme Option.
- Sensible Wohn- und Gewerbeprojekte: BIM-Modelle enthalten oft Bewohnerinformationen, Eigentümeradressen und Anlagenmetadaten, die nach Artikel 4 der DSGVO als personenbezogene Daten gelten. Diese ohne gültigen AVV und Rechtsgrundlage auf einem Drittanbieterserver zu verarbeiten, ist nicht konform.
- Einsatz vor Ort: Eine 200-MB-IFC-Datei lädt über eine 4G-Verbindung langsam und unzuverlässig hoch. Die Browser-Validierung verarbeitet sie lokal in Sekunden, unabhängig von der Upload-Bandbreite.
- Vorab-Validierung vor dem Cloud-Upload: Selbst wenn ein Team einen Cloud-Validator als formales Tor nutzt, fängt eine vorgeschaltete browserbasierte Prüfung offensichtliche Probleme ohne Upload ab – das senkt Cloud-Nutzungskosten und Upload-Häufigkeit.
Sechs Validierungsfehler, die BIM-Teams machen – und was sie wirklich bedeuten
Fehler 1: „IDS bestanden – das Modell ist gut“
IDS validiert nur das, was die .ids-Spezifikation deklariert. Wenn Ihre Datei FireRating an Wänden verlangt, Ihre AIA aber auch IsExternal an Türen, Uniclass-Codes an Tragwerkselementen und Mengensätze an Decken vorschreibt – und diese nicht in die Spezifikation aufgenommen wurden –, meldet die Engine, alle Anforderungen seien erfüllt, während die Hälfte Ihrer AIA ungeprüft bleibt. Ein bestandener IDS-Check ist eine vertragliche Bestätigung gegen eine bestimmte Spezifikation. Er ist kein allgemeines Qualitätszertifikat.
Fehler 2: „Der buildingSMART-Checker sagt, es ist valide“
Schemakonformität ist die Untergrenze, nicht die Obergrenze. Eine Datei, in der jedes Element Name='' hat und keinen einzigen Eigenschaftssatz besitzt, ist völlig schemakonform. Ein Modell ohne IfcElementQuantity, ohne Klassifizierung, bei dem jedes physische Element direkt in IfcSite statt in einem Geschoss liegt, ist ebenfalls völlig schemakonform. Ein bestandener buildingSMART-Check bedeutet, dass die STEP-Datei korrekt formatiert ist – er sagt nichts darüber aus, ob die Daten brauchbar sind.
Fehler 3: „Ich kann es in einem Viewer öffnen, also ist es in Ordnung“
IFC-Viewer sind bewusst tolerant konzipiert – sie sollen Geometrie unabhängig von der Datenqualität anzeigen. Ein Viewer, der schemaungültige oder datenarme Dateien nicht öffnet, wäre unbrauchbar. Dass die Geometrie korrekt gerendert wird, sagt nichts über die Vollständigkeit der Eigenschaftssätze, Namenskonventionen, GUID-Stabilität, Klassifizierung oder irgendeine der 44 Qualitätsdimensionen aus. Eine Datei zu betrachten ist grundsätzlich etwas anderes, als sie zu validieren.
Fehler 4: Nur die Geometrie prüfen, die Eigenschaftsdaten ignorieren
Ein verbreiteter Reflex ist es, die IFC zu öffnen, das 3D-Modell zu betrachten, und wenn das Gebäude richtig aussieht, die Datei für fertig zu erklären. Die Geometrie macht nur rund 30 % dessen aus, was eine IFC-Datei brauchbar macht. Eigenschaftssätze, Klassifizierungen, Elementnamen, Typzuweisungen und Mengensätze sind das, was FM-Systeme, Kostenmanager und CDE-Anlagenregister tatsächlich verwenden. Eine geometrisch korrekte Datei mit leeren Eigenschaftssätzen scheitert bei der Übergabe.
Fehler 5: Nur einmal validieren – kurz vor dem Liefertermin
Wer die Validierung als letzten Schritt vor der CDE-Übergabe behandelt, muss Probleme unter Druck und ohne Puffer beheben. Ein Modell mit 800 am Tag vor dem Termin entdeckten Validierungsproblemen wird entweder mit bekannten Mängeln geliefert oder verpasst den Termin. Der richtige Rhythmus: Level 1 nach jedem Export, Level 2 vor jeder internen Prüfung (mindestens wöchentlich), Level 3 zwei Wochen vor jedem formalen Meilenstein.
Fehler 6: Die GUID-Stabilität über mehrere Re-Exporte hinweg ignorieren
Doppelte GUIDs innerhalb einer Datei sind ein Level-1-Problem und von jedem Validator erkennbar. Aber GUID-Instabilität über mehrere Re-Exporte hinweg – bei der dasselbe Element bei jedem Export des Modells eine andere GlobalId erhält – bleibt bei der Validierung einer einzelnen Datei unsichtbar. Wenn GlobalIds zwischen Revisionen driften, wird jeder BCF-Kommentar, jede CDE-Elementreferenz und jede FM-Anlagenkennung stillschweigend zu einer toten Referenz. Das erfordert einen Vergleich zweier Revisionen und eine Prüfung der Exporteinstellungen – nicht nur die Validierung einer einzelnen Datei.
Ein praktischer Validierungs-Workflow für BIM-Koordinatoren
- Nach jedem IFC-Export: eine Level-1-Prüfung durchführen. Dauert in jedem browserbasierten Validator unter 30 Sekunden. Doppelte GlobalIds, verwaiste Elemente und Brüche in der räumlichen Hierarchie beheben, bevor sie sich über Revisionen hinweg summieren.
- Vor jeder internen Prüfung (wöchentlich oder pro Sprint): eine vollständige Level-2-Qualitätsprüfung durchführen. Den Health-Score-Trend überprüfen. Ein über Revisionen hinweg sinkender Score bedeutet, dass neue Probleme entstehen – die Ursache finden, bevor sich ein Muster verfestigt.
- Beim Empfang eines Fachmodells von Dritten: Level 1 und Level 2 vor dem Zusammenführen ausführen. Ein empfangenes Modell kann Probleme mitbringen, die Sie in das Koordinationsmodell übernehmen – erkennen Sie sie sofort, nicht erst drei Wochen später in der Koordination bei einer defekten Föderation.
- Zwei Wochen vor jeder formalen Meilenstein-Lieferung: alle drei Ebenen ausführen. Ziel: Health Score ≥ 80 vor IDS. Zwei Wochen geben Zeit zur Nacharbeit ohne Druck. Frühzeitig melden – den Puffer nicht aufbrauchen.
- Vor dem Upload in die CDE: Level 2 und Level 3 ausführen. Das Health-Score-Zertifikat und den IDS-Prüfbericht dem Transmittal beifügen. Das schafft eine dokumentierte Nachweiskette und gibt dem Informationsmanager alles, was für die Annahme der Lieferung nötig ist.
- Nach jedem Versions-Upgrade der Autorensoftware oder einer Änderung der Exporteinstellungen: die GUID-Stabilitätsbasis durch den Vergleich zweier aufeinanderfolgender Exporte neu festlegen. Ein Revit-Upgrade oder eine geänderte Exportkonfiguration kann das Verhalten bei der GlobalId-Erzeugung stillschweigend verändern.
Expertentipps
Nach Punktabzug priorisieren, nicht nach Anzahl
Beheben Sie Probleme nicht nach ihrer Anzahl, sondern nach ihrer Auswirkung auf den Health Score. Drei fehlende IfcProject-Metadatenfelder können 15 Punkte kosten. Achthundert Namenswarnungen kosten unter Umständen zusammen nur 8 Punkte. Nutzen Sie die Aufschlüsselung nach Schweregrad, um nach Wirkung zu priorisieren.
Exporteinstellungen in einer Vorlage fixieren
Jedes Mal, wenn Exporteinstellungen manuell neu konfiguriert werden, besteht die Gefahr, in eine abweichende Konfiguration abzudriften. Erstellen Sie in Ihrer Autorensoftware eine benannte IFC-Exportkonfiguration, übernehmen Sie sie in die Projektvorlage und dokumentieren Sie die erforderlichen Einstellungen im BAP. Konfigurationsdrift ist die Hauptursache der meisten „hat letztes Mal funktioniert“-Exportprobleme.
AIA zu Projektbeginn in IDS übersetzen
Übersetzen Sie die kritischsten AIA-Klauseln in den ersten zwei Projektwochen in eine IDS-Spezifikation. Selbst eine unvollständige .ids-Datei – fünf oder sechs Spezifikationen – ist besser als eine vollständige manuelle AIA-Prüfung zum Liefertermin, und sie deckt systematische Datenlücken früh auf, wenn sie noch günstig zu beheben sind.
Jedes Fachmodell vor dem Zusammenführen validieren
Probleme aus einem Fachmodell können sich in einer Föderation mit Problemen eines anderen überlagern oder verschleiern. Saubere Eingaben validieren, sauber zusammenführen. Wird die Validierung erst am Koordinationsmodell nach der Föderation durchgeführt, ist es schwerer, Probleme dem richtigen Urheber zuzuordnen.
Häufig gestellte Fragen
Bedeutet ein bestandenes Level 1, dass ich Level 2 überspringen kann?
Nein. Level 1 und Level 2 messen völlig unterschiedliche Eigenschaften einer Datei. Eine schemakonforme Datei (Level 1) kann null Eigenschaftssätze, leere Elementnamen, keine Klassifizierung und keine ISO-19650-Metadaten haben – und bei der Qualitätsprüfung (Level 2) trotzdem nur 20 Punkte erreichen. Sie brauchen immer beides. Level 1 heißt „die Datei ist korrekt verpackt“, Level 2 heißt „der Inhalt des Pakets entspricht dem Bestellten“.
Ersetzt IDS den buildingSMART Validation Service?
Nein. IDS prüft projektspezifische Informationsanforderungen (Level 3). Der buildingSMART Validation Service prüft die Schemakonformität (Level 1). Beide arbeiten auf völlig unterschiedlichen Ebenen und beantworten unterschiedliche Fragen. Ein Modell, das IDS besteht, aber die Schema-Validierung nicht besteht, wäre ein logischer Widerspruch – die Integrität nach Level 1 ist Voraussetzung für eine aussagekräftige Prüfung nach Level 3.
Welche IDS-Facetten sollte ich bei einer Standard-BIM-Lieferung priorisieren?
Die Facette Property deckt 70–80 % der realen AIA-Anforderungen ab – die meisten Auftraggeber wollen bestimmte Eigenschaftssatzwerte für bestimmte Elementtypen befüllt sehen. Classification deckt den größten Teil des Rests ab, bei Projekten, die nach Uniclass oder OmniClass klassifizieren. Die Facette Entity taucht in fast jeder Spezifikation als Filter für die Anwendbarkeit auf. Material und PartOf adressieren spezifische vertragliche Anforderungen. Beginnen Sie mit Entity + Property, ergänzen Sie Classification, wenn Ihre AIA es verlangt, und bauen Sie von dort aus weiter aus.
Kann ich eine IFC validieren, ohne sie irgendwohin hochzuladen?
Ja. Browserbasierte Validatoren verarbeiten die Datei vollständig in Ihrem Browser mithilfe von WebAssembly. Die IFC-Bytes verlassen Ihr Gerät nie – alle 44 Qualitätsregeln, die Health-Score-Berechnung und die vollständige IDS-Engine laufen clientseitig. Bei Modellen mit Einschränkungen bei der Datenverarbeitung – Behördenanlagen, sensible Wohndaten, Verteidigungsinfrastruktur – ist das oft die einzige konforme Option.
Welchen Health-Score-Schwellenwert sollte ich im BAP festlegen?
≥ 80 ist der Standardschwellenwert für die Lieferung in die CDE und die Entwurfskoordination. ≥ 90 für Lieferungen ab LOD 300 in der Ausführungsplanung und formale ISO-19650-Meilensteine. ≥ 70 ist für interne Prüfungen in der Konzeptphase akzeptabel. Unter 60 hat das Modell strukturelle Qualitätsprobleme und sollte unter keinen Umständen an eine externe Partei geliefert werden.
Kann ein einzelnes Tool alle drei Validierungsebenen abdecken?
Manche Tools schon. IFC Viewer Online deckt Level 1 ab (Integritätsregeln einschließlich GUID-, Hierarchie- und Dateikopf-Prüfungen), Level 2 (44-Regel-Qualitätsprüfung mit Health Score) und Level 3 (IDS-1.0-Engine, validiert gegen alle 100 offiziellen bSI-Testfälle). Solibri deckt Level 2 und Level 3 mit einer ausgefeilteren Regel-Engine ab, jedoch ohne browserbasierte Verarbeitung. Der buildingSMART Validation Service deckt nur Level 1 ab. IfcOpenShell lässt sich für Level 1 und Level 2 skripten.
Zusammenfassung
Schemakonform ist nicht projektkonform. Projektkonform ist nicht AIA-konform. Alle drei Validierungsebenen werden benötigt – und sie zu vermischen ist die Hauptursache der meisten gescheiterten formalen Lieferungen.
IFC Viewer Blog
Level 1: Bei jedem Export ausführen
Schemaintegrität, Eindeutigkeit und Format der GlobalId, räumliche Hierarchie. Dauert 30 Sekunden. Erkennt die strukturellen Fehler, die BCF, CDE-Versionierung und FM-Anlagenregister nachgelagert stillschweigend beschädigen.
Level 2: Jede CDE-Lieferung als Tor absichern
44 Qualitätsregeln, Health Score, Namenskonventionen, Vollständigkeit der Eigenschaftssätze, ISO-19650-Metadaten. Fordern Sie ≥ 80 in Ihrem BAP und Ihrer AIA. Das ist die Ebene, die ein Modell brauchbar macht – nicht nur parsebar.
Level 3: Vor jedem Meilenstein verifizieren
IDS-Spezifikationen, die Ihre AIA und AIR maschinenlesbar kodieren. Übersetzen Sie die kritischen Klauseln zu Projektbeginn, nicht in der Woche vor der Lieferung. Ein bestandener IDS-Check ist eine dokumentierte vertragliche Nachweiskette.
Führen Sie eine vollständige Qualitätsprüfung an Ihrem aktuellen Modell durch – in jedem Browser unter 30 Sekunden, ohne Upload. Lesen Sie anschließend den Leitfaden zum IFC Health Score, um zu verstehen, wie der Score berechnet wird und welchen Schwellenwert Sie in Ihrem BAP festlegen sollten. Müssen bei einer empfangenen Datei Eigenschaftswerte oder GUIDs korrigiert werden, behandelt der Leitfaden zum kostenlosen Online-IFC-Editor die zerstörungsfreie Bearbeitung von Eigenschaften ohne Umweg über die Autorensoftware. Und für die häufigsten strukturellen Fehler, die zu Ablehnungen nach Level 1 führen, siehe die 7 häufigsten IFC-Validierungsfehler.
IFC Model Checker: Der vollständige Leitfaden zu IFC-Validierung, Modellqualität und IDS