Zurück zum BIM- & IFC-Blog
Datenschutz & Sicherheit · 2026-06-28 · 19 Min.
Browserbasierte IFC-Validierung vs. Cloud: Die Architekturentscheidung, die BIM-Teams falsch treffen
Offline-IFC-Validierung per WebAssembly – nichts wird hochgeladen, funktioniert auch auf der Baustelle. Browser- vs. Cloud-IFC-Validator: Datenschutz, DSGVO, Uploadgeschwindigkeit, Offline-Nutzung und wann welche Architektur gewinnt.
Browserbasierte IFC-Validierung vs. Cloud: Die Architekturentscheidung, die BIM-Teams falsch treffen — IFC Viewer Online article cover
- 0 Byte — bei der Browser-Validierung hochgeladen
- 40 Sek. — für 50 MB Upload bei 10 Mbit/s
- 44 — clientseitig geprüfte Regeln
- 10× — schnellere Wiederholungsladevorgänge dank OPFS-Cache
Wenn ein BIM-Koordinator fragt: „Wo kann ich meine IFC-Datei validieren?“, bekommt er meist eine URL als Antwort. Ein Cloud-Dienst. Modell hochladen, warten, Bericht erhalten. Das ist das gängige Denkmodell für die IFC-Validierung – und für einen erheblichen Teil der Projekte, in denen es angewendet wird, die falsche Wahl.
Es gibt zwei grundlegend verschiedene Architekturen für die IFC-Validierung. Den Unterschied zu verstehen – und zu wissen, welche für welches Projekt richtig ist – wird zunehmend zu einer professionellen Kernkompetenz für BIM-Manager und digitale Bauteams. Mit der Wahl der Architektur entscheiden Sie in einem Schritt über Datenschutz, Geschwindigkeit, regulatorische Konformität und Offline-Verfügbarkeit.
Zwei grundverschiedene Architekturen
Diese Unterscheidung ist kein Produktdetail. Sie ist eine Frage danach, wo die Verarbeitung stattfindet – und das bestimmt alles Weitere.
ARCHITECTURE A — Cloud Validation
══════════════════════════════════
Your Machine Internet Cloud Server
──────────── ──────── ────────────
① Open IFC file
│
│ ② UPLOAD ──────────────────────────────► Server receives file
│ 50 MB → ~40 s at 10 Mbps │
│ 250 MB → ~3 min at 10 Mbps ③ Server parses IFC
│ 1 GB → ~13 min at 10 Mbps │
│ ④ Validation runs
│ │
│ ⑤ RESULTS ◄───────────────────────────────────────┘
│
⑥ View report
Data custody: Your machine → Transit (TLS) → Third-party server
ARCHITECTURE B — Browser-Based Validation
══════════════════════════════════════════
Your Machine Internet
──────────── ────────
① Open IFC file
│
② WASM binary loads (Nothing uploaded.
│ Nothing leaves the device.
③ Web Worker: IFC parsing Ever.)
│
④ 44 validation rules run
│
⑤ Health Score calculated
│
⑥ WebGL renders 3D model
│
⑦ Results: instant, local
OPFS cache: parsed geometry persists → repeat load ~10× faster
Data custody: Your machine only
Bei Architektur A wird die IFC-Datei von einer Infrastruktur verarbeitet, die Sie nicht kontrollieren. Sie durchquert ein Netzwerk, liegt auf einem fremden Server und wird von Software verarbeitet, die Sie nicht selbst betreiben. Bei Architektur B läuft dieselbe Validierungslogik in Ihrem Browser – mittels WebAssembly, kompiliert aus demselben C++-Code, der auch native Desktop-BIM-Tools antreibt. Nichts verlässt das Gerät, und es ist kein Dritter an der Verarbeitung beteiligt.
Warum IFC-Modelle sensible Informationen enthalten
Der Reflex, IFC-Dateien wie PDFs zu behandeln – teilbar, hochladbar, überall archivierbar – unterschätzt, was in einem komplexen Gebäudemodell steckt. Eine IFC-Datei ist eine strukturierte Datenbank mit Objektinformationen. Bei vielen Projektarten sind diese Informationen tatsächlich sensibel, zugangsbeschränkt oder als vertraulich eingestuft.
Regierungsgebäude und öffentliche Infrastruktur
Gerichte, Behörden, Rechenzentren, kritische Versorgungseinrichtungen. Daten zu strukturellen Schwachstellen, Layouts der Notfallsysteme und Pläne der Sicherheitsinfrastruktur, eingebettet als IFC-Geometrie und -Eigenschaften.
Flughäfen und Verkehrsknotenpunkte
Geometrie der Sicherheitskontrollen, Grenzverläufe des Luftseitenbereichs, Platzierung von Videoüberwachung und Sensorik, Verläufe der Notfallsysteme. In den meisten Rechtsordnungen der Luftsicherheit und der nationalen Geheimhaltung unterworfen.
Krankenhäuser und Gesundheitswesen
Infrastruktur der Patientenwege, Redundanz der medizinischen Gasversorgung, Layouts der Intensivstationen. Unterliegt den NHS-IG-Vorgaben (Großbritannien) und HIPAA (USA). Strukturdaten sicherheitsrelevanter Systeme.
Schiene und kritischer Nahverkehr
Tunnelgeometrie, Leit- und Sicherungstechnik, Fluchtwege, Topologie der Stromversorgung. Häufig als kritische nationale Infrastruktur eingestuft, mit ausdrücklichem Verbot des Uploads zu Dritten.
Industrie- und Verfahrensanlagen
Anordnung der Prozessanlagen, Geometrie der Gefahrstoffeinhausung, Platzierung der Sicherheitssysteme. In der EU der COMAH-/Seveso-III-Regulierung unterworfen. Kommerziell sensible Prozessdaten.
Verteidigung und Militär
In den meisten Ländern durch Vorschriften der Verteidigungsbeschaffung ausdrücklich beschränkt. IFC-Dateien militärischer Infrastruktur dürfen ohne spezifische Sicherheitsfreigabe und vertragliche Zustimmung rechtlich nicht auf kommerzielle Cloud-Dienste hochgeladen werden.
Über den Projekttyp hinaus enthalten IFC-Dateien Metadaten, die nach mehreren Rechtsrahmen als sensibel gelten. Das Feld FILE_NAME im STEP-Dateikopf enthält Namen von Autor und Organisation. IfcProject-Eigenschaften tragen Kunden- und Projektkennungen. Raumplanungsmodelle können Belegungszahlen und Personalverteilung enthalten. Eigenschaftssätze können Systemkapazitäten, Baukonstruktionsdaten und Betriebsmerkmale eines Gebäudes offenlegen – genau die Art von Informationen, die Industriespionage lohnend macht.
Der Blickwinkel DSGVO und Datenumgang
Artikel 4 DSGVO definiert personenbezogene Daten weit gefasst – er umfasst jede Information, die sich auf eine identifizierte oder identifizierbare natürliche Person bezieht. Im BIM-Kontext betrifft das: Namen von Nutzern in Raumzuweisungen, Kontaktdaten des Eigentümers in den IfcProject-Metadaten, Personenzahlen in Brandschutz-Evakuierungsberechnungen und mitunter Objektreferenzcodes, sofern sie sich über andere Datensätze auf identifizierbare Personen zurückführen lassen.
In der Praxis verfügen die meisten großen AEC-Unternehmen und öffentlichen Stellen über Datenschutzrichtlinien, die das Hochladen von Projektmodellen auf nicht freigegebene Drittanbieterdienste formal untersagen. Auf Koordinatorenebene werden diese Richtlinien häufig ignoriert, weil sie in einem Dokumentenmanagementsystem liegen und die Validator-URL in einem Community-Forum geteilt wurde. Browserbasierte Validierung macht Konformität zum Weg des geringsten Widerstands – sie eliminiert die Upload-Entscheidung vollständig.
Wie WebAssembly browserbasierte BIM-Tools verändert hat
Um zu verstehen, warum die Browser-Validierung heute technisch überzeugend ist, muss man wissen, was sich geändert hat. Vor 2017 zog kein BIM-Softwarehersteller ernsthaft in Betracht, einen echten IFC-Parser im Browser laufen zu lassen. Der Browser konnte nur JavaScript ausführen, und JavaScript ist die falsche Sprache, um das STEP-Format nach ISO 10303-21 in Produktionsgeschwindigkeit zu parsen.
Vor WebAssembly – die Situation bis 2017
- Das Parsen von IFC-Dateien erforderte serverseitige Verarbeitung – Cloud-Validatoren existierten nicht als Komfortlösung, sondern als einzig tragfähige Architektur. Es gab keine leistungsmäßig konkurrenzfähige Alternative.
- Browserbasierte IFC-Viewer nutzten vorverarbeitete Zwischenformate (JSON-Geometrieauszüge, vereinfachte Meshes) statt IFC in Echtzeit zu parsen. Was man sah, war nicht die IFC-Datei – es war eine serverseitig erzeugte Annäherung.
- Eine 50-MB-IFC-Datei brauchte in reinem JavaScript Minuten zum Parsen und brachte auf speicherschwachen Rechnern Tabs zum Abstürzen. Eine 200-MB-Datei war im Browser praktisch unmöglich.
- Das 3D-Rendering steckte mit WebGL noch in den Anfängen – GPU-beschleunigt, aber begrenzt auf Szenenkomplexitäten, die JavaScript bewältigen konnte. Große Tragwerksmodelle mit Hunderttausenden Elementen waren unpraktikabel.
- Web Worker boten Thread-Isolation, aber keine Möglichkeit, kompilierten nativen Code auszuführen. Die Leistung war durch die Garbage-Collection-Pausen von JavaScript und das Single-Thread-Ausführungsmodell begrenzt.
Nach WebAssembly – was heute möglich ist
WebAssembly (WASM) ist ein binäres Befehlsformat für eine stapelbasierte virtuelle Maschine, die im Browser nahezu mit nativer Geschwindigkeit läuft. Code in C, C++ oder Rust wird zu WASM kompiliert und läuft in jedem modernen Browser mit etwa 60–90 % der nativen Geschwindigkeit – ohne Plugins, ohne Installation, mit vollständiger Speicherisolation und garantierter Sandbox. WASM wurde 2019 zum W3C-Standard und ist in allen gängigen Browsern verfügbar.
Konkret für IFC: web-ifc – der von der Bibliothek @thatopen/components verwendete Parser – ist von C++ zu WebAssembly kompiliert. Er parst das IFC-STEP-Format in derselben Geschwindigkeitsklasse wie native Desktop-Bibliotheken. Eine 50-MB-IFC-Datei wird auf einem aktuellen Laptop in unter 10 Sekunden geparst, in einem Browser-Tab, ohne dass ein Server beteiligt ist. Dieselbe Leistungsklasse, mit der Solibri oder Navisworks eine lokale Datei laden – nur eben im Browser.
WASM: C++-Geschwindigkeit im Browser
web-ifc ist von C++ zu WebAssembly kompiliert. Das Parsen des IFC-STEP-Formats läuft mit 60–90 % der nativen Geschwindigkeit – derselben Leistungsklasse wie Desktop-BIM-Tools. Ein 50-MB-Modell wird auf einem aktuellen Laptop in unter 10 Sekunden geparst.
Web Worker: echte Parallelität
Das WASM-Parsen läuft in einem eigenen Web Worker – einem separaten Betriebssystem-Thread. Die Browser-Oberfläche bleibt auch bei aufwendigem Laden des Modells reaktionsfähig. Die Validierung läuft in einem parallelen Worker und liefert Ergebnisse, während die Geometrie noch lädt.
OPFS: dauerhafter lokaler Cache
Das Origin Private File System ist eine browsereigene Speicher-API, pro Ursprung isoliert und für Server nicht erreichbar. Nach dem ersten Laden wird die geparste Geometrie im OPFS abgelegt. Wiederholte Ladevorgänge sind rund 10-mal schneller – kein erneutes Parsen, kein erneuter Upload.
WebGL / WebGPU: GPU-Rendering
Three.js abstrahiert WebGL für leistungsstarkes 3D-Rendering. Die fragmentbasierte Szenenverwaltung bewältigt Modelle mit Hunderttausenden Elementen bei interaktiven Bildraten. WebGPU-Unterstützung für die nächste Rendering-Generation ist in Vorbereitung.
Der OPFS-Cache: Warum wiederholte Ladevorgänge den Workflow verändern
Das Origin Private File System ist eine browsereigene Speicherebene, die auf den aktuellen Web-Ursprung beschränkt ist. Andere Ursprünge, andere Browser-Tabs und – entscheidend – entfernte Server haben keinen Zugriff auf ihren Inhalt. Es bleibt über Browser-Sitzungen hinweg bestehen. Für IFC-Workflows löst OPFS die schmerzhafteste Reibung bei aufwendigen Modell-Tools: die Kosten des wiederholten Parsens.
Eine 250-MB-IFC-Datei, die von Grund auf neu geparst wird, braucht auf einem aktuellen Rechner 20–40 Sekunden. Dieselbe Datei aus dem OPFS-Cache lädt in 2–3 Sekunden. Für einen BIM-Koordinator, der dasselbe Projektmodell mehrmals täglich öffnet, macht OPFS den Unterschied zwischen einem Tool, das sich schnell anfühlt, und einem, bei dem man wartet. Und weil der OPFS-Speicher pro Ursprung isoliert ist und im lokalen Dateisystem liegt, erreichen die zwischengespeicherten Modelldaten nie einen Server – sie genießen dieselbe Datenschutzgarantie wie die Browser-Validierung selbst.
Der Upload-Engpass – echte Zahlen
Der am meisten unterschätzte Kostenfaktor der Cloud-IFC-Validierung ist die Upload-Zeit. In Produktvergleichen bleibt sie unsichtbar, im tatsächlichen Arbeitsablauf dominiert sie. So sieht der Upload gängiger IFC-Dateigrößen bei realistischen Verbindungstypen aus – und so schneidet die lokale Browser-Verarbeitung im Vergleich ab:
| IFC-Dateigröße | Büro (10 Mbit/s Upload) | 4G mobil (3 Mbit/s) | Baustelle (1 Mbit/s) |
|---|
| 50 MB | ~40 Sekunden | ~2 Min. 15 Sek. | ~7 Minuten |
| 250 MB | ~3 Min. 20 Sek. | ~11 Minuten | ~33 Minuten |
| 1 GB | ~13 Minuten | ~45 Minuten | ~2 Std. 15 Min. |
| 2 GB | ~27 Minuten | ~1 Std. 30 Min. | ~4 Std. 30 Min. |
Nur Upload-Zeit – die serverseitige Verarbeitung kommt jeweils hinzu: 50 MB +5–15 Sek. · 250 MB +30–90 Sek. · 1 GB +2–6 Min. · 2 GB +5–15 Min. Browser-Validierung: in allen Fällen 0 Sek. Upload.Ein 250-MB-Modell: Minuten, bevor die Prüfung überhaupt beginnen kann
- Browser, lokales Parsen (kein Upload): 0.7 Min. — 20–40 Sek. beim ersten Parsen auf einer aktuellen Workstation
- Upload aus dem Büro (10 Mbit/s): 3.3 Min.
- Upload über 4G (3 Mbit/s): 11 Min.
- Upload von der Baustelle (1 Mbit/s): 33 Min.
Nur die Upload-Zeit für serverbasierte Tools; deren Verarbeitung kommt mit weiteren 30–90 Sek. hinzu.
Eine 250-MB-IFC-Datei – ein typisches Koordinationsmodell für ein mittelgroßes Gewerbeprojekt – braucht über eine schnelle Büroverbindung mehr als 3 Minuten zum Hochladen. Über 4G sind es 11 Minuten. Für einen BIM-Koordinator, der mehrmals täglich Prüfungen vor der Lieferung durchführt, summiert sich allein die Upload-Zeit zu Stunden reiner Wartezeit pro Woche. Die Validierung selbst nimmt nur einen Bruchteil der Upload-Zeit in Anspruch.
Auf Baustellen, wo 4G-Verbindungen die Norm sind und sich Baubüros und BIM-Tablets die Bandbreite teilen, bedeutet der Upload einer 1-GB-IFC-Datei eine 45-minütige Wartezeit, bevor auch nur eine Validierungsregel läuft. Die browserbasierte Validierung verarbeitet dieselbe Datei lokal in 90–180 Sekunden, ganz ohne Netzwerkabhängigkeit – und dank OPFS-Caching bei späteren Sitzungen in 2–5 Sekunden.
Der vollständige Vergleich: Browser- vs. Cloud-IFC-Validierung
| Dimension | Browser-Validierung | Cloud-Validierung |
|---|
| Datenschutz | ✅ Datei verlässt nie das Gerät | ⚠️ Datei wird auf Server hochgeladen |
| Datenhoheit | ✅ Keine Verwahrung durch Dritte | ⚠️ Datenverwahrung durch Dritte |
| DSGVO-Konformität | ✅ Konform per Architektur | ⚠️ Erfordert AVV + Rechtsgrundlage |
| Sensible Projekte | ✅ In vielen Fällen einzige Option | ❌ Oft untersagt |
| Geschwindigkeit (klein <50 MB) | ✅ Nahezu sofort | ⚠️ Verzögerung durch Upload + Verarbeitung |
| Geschwindigkeit (groß >250 MB) | ✅ Kein Upload-Nachteil | ❌ Upload-Engpass |
| Wiederholtes Laden | ✅ OPFS-Cache (~10× schneller) | ❌ Jedes Mal vollständiger Re-Upload |
| Upload-Zeit | ✅ Null | ❌ Proportional zur Dateigröße |
| Offline-Verfügbarkeit | ✅ Vollständige Offline-Unterstützung | ❌ Erfordert Internet |
| Einsatz vor Ort | ✅ Funktioniert mit 4G oder offline | ❌ Langsam / unzuverlässig vor Ort |
| Internetabhängigkeit | ✅ Keine (nach erstem Laden) | ❌ Bei jedem Durchlauf erforderlich |
| Stapelverarbeitung | ❌ Manuell, eine nach der anderen | ✅ API-/Stapelautomatisierung |
| CI/CD-Integration | ❌ Nicht geeignet | ✅ Native Webhook-/API-Anbindung |
| Prüfpfad im Team | ⚠️ Nur lokal | ✅ Zentralisierter Verlauf |
| Organisationsweites Reporting | ⚠️ Nicht aggregiert | ✅ Dashboard über alle Projekte |
| Sicherheit (Daten) | ✅ Kein Übertragungs-/Serverrisiko | ⚠️ Risiko bei Übertragung + Server |
| Sicherheit (Vorfall) | ✅ Kein Server, der kompromittiert werden kann | ⚠️ Abhängig vom Cloud-Anbieter |
| Sehr große Dateien >2 GB | ⚠️ Begrenzt durch Geräte-RAM | ✅ Server verfügt über mehr RAM |
| Kosten | ✅ Kostenlos bis günstig | ⚠️ Nutzungsbasiert oder Abonnement |
| Infrastrukturaufwand | ✅ Keiner – läuft im Browser | ✅ Vom Anbieter verwaltet |
| Einrichtungsaufwand | ✅ URL öffnen, Datei ziehen | ⚠️ Konto/API-Schlüssel erforderlich |
Wo die Cloud-Validierung wirklich im Vorteil ist
Ein Vergleich, der nur eine Seite hervorhebt, ist Parteinahme. Die Cloud-IFC-Validierung hat in bestimmten Kontexten echte Vorteile – und dort die Browser-Validierung einzusetzen, wäre die falsche Entscheidung.
Automatisierte CI/CD-Pipelines
Automatisch ausgelöste Validierung bei jedem Modell-Commit – analog zu Unit-Tests in der Softwareentwicklung. Cloud-APIs mit Webhook-Antworten sind die einzige Architektur für headless Automatisierung. In einer serverseitigen Pipeline gibt es keine Browser-Sitzung, in der WASM laufen könnte.
Stapelverarbeitung auf Portfolioebene
Die Prüfung Hunderter bestehender IFC-Dateien über ein ganzes Projektportfolio hinweg – eine Altdatenmigration, ein CDE-Archiv-Audit – ist über Cloud-Batch-APIs praktikabel, manuell im Browser Datei für Datei dagegen nicht.
Zentralisiertes Team-Reporting
Ein BIM-Manager braucht einen einzigen Überblick über die Validierungshistorie mehrerer Projekte und Ersteller – Score-Trends, Häufigkeit von Problemen, Konformität im Zeitverlauf. Cloud-Dienste aggregieren das. Browser-Tools liefern nur lokale Ergebnisse.
CDE-Gateway-Integration
Manche CDEs validieren eingehende IFC-Uploads automatisch, bevor sie sie annehmen. Das ist von Natur aus eine serverseitige Operation – der CDE-Server verarbeitet die Datei, nicht der Browser eines Nutzers. Cloud-Validierungs-APIs sind hier der Integrationspunkt.
Browser-Validierung – am besten geeignet für
- Regierungs- und öffentliche Projekte
- Verteidigung, Infrastruktur und Flughafen-BIM
- Modelle von Krankenhäusern und Gesundheitseinrichtungen
- Industrieanlagen und Verfahrenstechnik
- Modelle mit DSGVO- oder Datenbeschränkungsrichtlinien
- Validierung vor Ort und offline
- Vorprüfung vor der formalen Cloud-Einreichung
- Einzelne Koordinatoren und kleine Teams
Cloud-Validierung – am besten geeignet für
- Automatisierte CI/CD-Validierungspipelines
- Portfolioweite Qualitäts-Audits im Stapel
- Zentralisierte BIM-Qualitätsdashboards
- CDE-Gateway und automatisierte Lieferfreigaben
- Unkritische kommerzielle Projekte im großen Maßstab
- Workflow-Automatisierung für Unternehmen mit mehreren Teams
- API-gestützte Integration mit anderen Systemen
- Sehr große Dateien jenseits des lokalen Geräte-RAM
Fünf Irrtümer über die browserbasierte IFC-Validierung
Irrtum 1: „Browser-Anwendungen sind langsamer als die Cloud“
Das stimmte 2015. Heute nicht mehr. WebAssembly-Code läuft in einem modernen Browser mit 60–90 % der nativen C++-Geschwindigkeit. Die IFC-Parsing-Engine (web-ifc) ist aus C++ kompiliert – dieselbe Leistungskategorie wie die Bibliotheken hinter Solibri, den IFC-Importern von Autodesk und IfcOpenShell. In Kombination mit einer Upload-Latenz von null ist die Browser-Validierung bei typischen Modellgrößen häufig schneller als die Cloud, besonders bei Verbindungen mit weniger als 50 Mbit/s Upload.
Der Irrtum hält sich, weil Browser-JavaScript (langsam, mit Garbage Collection) mit nativen kompilierten Anwendungen (schnell) verglichen wird. Moderne Browser-BIM-Tools führen die aufwendige Verarbeitung nicht in JavaScript aus – sie führen kompiliertes WASM mit nahezu nativer Geschwindigkeit aus, während JavaScript nur den Ablauf orchestriert. Der Unterschied zwischen JS und WASM ist so bedeutend wie der zwischen Python und C++.
Irrtum 2: „Man muss eine IFC-Datei hochladen, um sie zu validieren“
Das ist falsch. Beim Öffnen einer IFC-Datei in einem browserbasierten Validator erzeugt der Browser ein File-Objekt im lokalen Speicher – zugänglich für WASM und JavaScript in diesem Browser-Kontext, aber nicht an einen Netzwerk-Endpunkt übertragen, sofern der Code nicht ausdrücklich eine fetch- oder XHR-API aufruft. Sie können das selbst prüfen: Öffnen Sie den Netzwerk-Tab der Entwicklertools (F12 → Netzwerk) und bestätigen Sie, dass beim Öffnen und Validieren eines Modells kein Upload stattfindet.
Irrtum 3: „Große IFC-Dateien lassen sich nicht im Browser verarbeiten“
Moderne Browser können auf typischer Workstation-Hardware mehrere Gigabyte RAM belegen. Eine 250-MB-IFC-Datei belegt im Speicher 250 MB – das liegt deutlich innerhalb dessen, was ein Browserprozess auf einem Rechner mit 16 GB zuteilen kann. Web Worker erweitern dies um Speicherzugriff außerhalb des Hauptthreads. Bei Dateien über 500 MB macht ein in Blöcken erfolgendes räumliches Laden die Browser-Verarbeitung selbst unter engeren Speicherbedingungen praktikabel. OPFS sorgt dafür, dass ein einmal geparstes großes Modell in späteren Sitzungen nie erneut geparst werden muss.
Irrtum 4: „Die Cloud ist immer sicherer“
Sicherheit ist mehrdimensional, kein einzelnes Merkmal. Cloud-Dienste verschlüsseln Daten in der Regel bei der Übertragung (TLS 1.3) und im Ruhezustand (AES-256), was passives Abhören adressiert. Sie schaffen aber Angriffsflächen, die die Browser-Verarbeitung vollständig ausschließt: Kompromittierung des Servers, falsch konfigurierte Speicher-Buckets, Zugriff durch Mitarbeitende des Cloud-Anbieters, Supply-Chain-Angriffe auf die Infrastruktur des Anbieters und Verstöße gegen den Datenstandort, falls sich der Server außerhalb der vertraglich vorgeschriebenen Rechtsordnung befindet.
Eine Datei, die das Gerät nie verlässt, ist keinerlei netzwerkbasierter Bedrohung ausgesetzt. Die richtige Sicherheitsfrage lautet nicht „welche Architektur ist absolut gesehen sicherer?“, sondern „welche Bedrohungsmodelle sind für dieses Projekt relevant?“. Für das Gebäudemodell eines Verteidigungsministeriums eliminiert die Browser-Verarbeitung den Upload-Angriffsvektor vollständig. Für ein unkritisches kommerzielles Projekt, bei dem zentralisierte Protokollierung wichtig ist, können Cloud-Kontrollen der richtige Kompromiss sein.
Irrtum 5: „Browser-Validierung ist nicht unternehmenstauglich“
Unternehmenstaugliche Software zeichnet sich durch Zuverlässigkeit, Funktionstiefe und institutionelle Unterstützbarkeit aus – nicht durch die Bereitstellungsarchitektur. Figma, AutoCAD Web, Google Earth und Microsoft Office für das Web sind unternehmenstaugliche Anwendungen, die per WebAssembly und modernen Web-APIs im Browser laufen. Dieselbe WASM-Laufzeitumgebung, dieselben Web Worker und dieselbe WebGL-Infrastruktur, die diese Anwendungen antreiben, treiben auch die browserbasierte IFC-Validierung an. „Browserbasiert“ ist eine architektonische Entscheidung darüber, wo die Verarbeitung stattfindet – keine Qualitätsobergrenze.
Problembehandlung bei der Browser-Validierung
Modell lädt, aber die Validierung wirkt langsam
Die Validierung läuft in einem separaten Web Worker und blockiert die Benutzeroberfläche nicht – das 3D-Modell sollte interaktiv bleiben, während die Validierung im Hintergrund läuft. Wirkt der gesamte Ladevorgang langsam, prüfen Sie, ob das Modell aus dem OPFS-Cache (schnell) lädt oder von Grund auf neu geparst wird (bei großen Dateien langsamer). Beim ersten Laden benötigt eine 200-MB-Datei selbst lokal 20–40 Sekunden zum Parsen. Nachfolgende Ladevorgänge aus dem Cache dauern 2–5 Sekunden.
Speichermangel bei sehr großen Dateien
Dateien über 400–500 MB können auf Rechnern mit 8–16 GB RAM den Browser-Speicher erschöpfen. Symptome: Der Browser-Tab stürzt ab oder reagiert nicht mehr. Lösungen: andere Browser-Tabs schließen, um Speicher freizugeben, einen Rechner mit 16 GB RAM oder mehr verwenden, oder ein föderiertes Modell vor dem Laden in gewerkespezifische Dateien aufteilen. Für Dateien, die dauerhaft über 500 MB liegen, ist die Cloud-Validierung möglicherweise die geeignetere Architektur – Server-Hardware bietet in der Regel mehr RAM-Spielraum.
OPFS-Cache wächst mit der Zeit stark an
OPFS speichert für jedes geladene Modell geparste Geometriefragmente. Bei einem Projektteam, das über Wochen viele Modelle lädt, kann der Cache auf mehrere Gigabyte anwachsen. Der Cache-Manager des Validators zeigt alle zwischengespeicherten Dateien mit ihrer Größe an und erlaubt das gezielte Löschen. Auch über die Speichereinstellungen des Browsers lässt sich der gesamte Ursprungsspeicher leeren. Der Cache liegt auf dem lokalen Gerät und ist für keinen entfernten Server zugänglich.
Validierungsergebnisse unterscheiden sich zwischen Browser und Cloud
Unterscheiden sich die Ergebnisse, liegt die häufigste Ursache darin, dass unterschiedliche Regelsätze angewendet werden. Die Browser-Validierung (44 Qualitätsregeln) und die Cloud-Schemaprüfung (Konformität mit ISO 10303-21) prüfen unterschiedliche Dinge – nicht dieselben Regeln an unterschiedlichen Orten. Die Unterscheidung zwischen Ebene 1 (Schemaprüfung), Ebene 2 (Qualitätsprüfung) und Ebene 3 (IDS) erklärt der Leitfaden zu den Validierungsebenen. Ein IDS-Ergebnis sollte zwischen zwei spezifikationskonformen Engines, die dieselbe .ids-Datei gegen dasselbe Modell ausführen, identisch sein.
Wo IFC Viewer Online in diese Architektur passt
IFC Viewer Online ist eine browserbasierte Umsetzung von Architektur B. Der IFC-Parser (web-ifc, zu WASM kompiliert), die Validierungs-Engine mit 44 Regeln, die Berechnung des Health Score, die IDS-1.0-Prüf-Engine, das BCF-Panel und der 3D-Renderer (Three.js über WebGL) laufen alle im Browser. Nichts wird hochgeladen. Die Architektur erzwingt das auf Implementierungsebene – es gibt keinen serverseitigen Endpunkt, an den Modelldaten gesendet werden könnten.
WASM-Parsing in einem Web Worker
web-ifc (C++ → WASM) läuft in einem eigenen Worker-Thread. Die Benutzeroberfläche bleibt beim Laden großer Modelle reaktionsfähig. Eine 50-MB-Datei wird in unter 10 Sekunden geparst, eine 200-MB-Datei in 20–40 Sekunden. Erstes Ergebnis: immer lokal.
OPFS-Caching für wiederholtes Laden
Geparste Geometriefragmente bleiben nach der ersten Sitzung im OPFS erhalten. Wiederholte Ladevorgänge sind rund 10-mal schneller – kein erneutes Parsen, keine Netzwerkabhängigkeit. Der Cache ist auf den Browser-Ursprung beschränkt und für entfernte Server nicht zugänglich.
44 Qualitätsregeln + IDS 1.0
44 Modellqualitätsregeln (strukturelle Integrität, ISO 19650, Psets, Klassifikation, LOD, MEP) plus eine buildingSMART-IDS-1.0-Engine, getestet gegen alle 100 offiziellen bSI-Testfälle – alles clientseitig.
Zerstörungsfreies Bearbeiten von Eigenschaften
Elementnamen, Werte von Eigenschaftssätzen und GlobalIds lassen sich auf erhaltenen IFC-Dateien bearbeiten, ohne den Umweg über die Autorensoftware – und ohne Upload auf einen Server.
Expertenempfehlungen: die richtige Architektur wählen
Die Wahl zwischen Browser- und Cloud-Validierung ist eine Governance-Entscheidung auf Projektebene, keine Frage der Werkzeugpräferenz. Hier die Entscheidungslogik für die häufigsten Szenarien:
- Regierungs-, Verteidigungs-, Flughafen-, Bahn-, Krankenhaus- und Industrieanlagenprojekte: Hier sollte die browserbasierte Validierung die Standardannahme sein. Prüfen Sie vor jeder Cloud-Erwägung, ob die Datenschutzrichtlinie Ihrer Organisation den Modell-Upload überhaupt gestattet. Regelt die Richtlinie das nicht, gehen Sie von einem Upload-Verbot aus und holen Sie eine Klärung bei Ihrem Datenschutzbeauftragten ein.
- Kommerzielle Projekte ohne Datenklassifikation: Beide Architekturen sind tragfähig. Nutzen Sie die Cloud für zentralisierte Prüfpfade und CI/CD-Integration. Nutzen Sie den Browser für Geschwindigkeit, Datenschutzpräferenz und Offline-Fähigkeit.
- Tägliche Qualitätsprüfungen einzelner Koordinatoren vor der Lieferung: Die Browser-Validierung ist schneller, einfacher, benötigt kein Konto und eliminiert die Upload-Wartezeit. Führen Sie sie lokal durch, bevor Sie formal im CDE einreichen.
- Portfolio-Audits oder CDE-Konformitätsbewertungen über viele Modelle hinweg: Cloud-Stapelverarbeitung ist hier das richtige Werkzeug. 200 Modelle über eine Cloud-API laufen zu lassen und einen konsolidierten Qualitätsbericht zu erhalten, ist im Browser nicht praktikabel.
- Automatisierte Lieferfreigabe innerhalb eines CDE: Cloud-Validierung mit API-Anbindung ist hier die einzig praktikable Architektur. In einem automatisierten serverseitigen Workflow steht kein Browser-Kontext zur Verfügung.
- Hybrider Workflow: Nutzen Sie die browserbasierte Validierung als tägliches Qualitätstor (schnell, privat, kein Konto erforderlich), und reservieren Sie die Cloud für die formale CDE-Einreichung, wo Prüfpfad, API-Anbindung oder Stapelautomatisierung einen echten Mehrwert bieten. Diese Architekturen ergänzen sich.
Häufig gestellte Fragen
Ist browserbasierte IFC-Validierung wirklich privat?
Ja, sofern korrekt implementiert. WebAssembly läuft in einer isolierten Browser-Sandbox. Das File-Objekt mit den IFC-Daten wird im lokalen Browser-Speicher erzeugt. Damit diese Daten einen Server erreichen, müsste der Code ausdrücklich eine Netzwerk-API aufrufen. Ein korrekt implementierter Browser-Validator tut das für die IFC-Datei nicht. Prüfen Sie das selbst: Öffnen Sie den Netzwerk-Tab der Entwicklertools (F12 → Netzwerk) und bestätigen Sie, dass beim Öffnen und Validieren eines Modells kein Upload stattfindet.
Kann die Browser-Validierung offline laufen?
Ja, mit einer Einschränkung: Die Anwendung selbst muss mindestens einmal online geladen werden – die WASM-Binärdatei und die JavaScript-Bundles werden beim ersten Besuch heruntergeladen. Danach kann eine Progressive Web App vollständig offline laufen. Im OPFS zwischengespeicherte Modelle laden ohne jeden Netzwerkzugriff. Für Baustellenbesuche mit unzuverlässiger Verbindung sichert das Laden der Anwendung und das Vorab-Zwischenspeichern des Projektmodells am Vorabend die Offline-Verfügbarkeit am nächsten Tag.
Wo liegt die praktische Dateigrößengrenze für die Browser-Validierung?
Auf Hardware mit 16 GB RAM (einer typischen aktuellen Workstation oder einem High-End-Laptop) lassen sich Dateien bis 400–500 MB zuverlässig verarbeiten. Auf Rechnern mit 8 GB liegt die praktische Grenze bei etwa 200–250 MB, bevor Speicherdruck zu Instabilität führt. Das OPFS-Caching macht das wiederholte Parsen überflüssig – der volle Verarbeitungsaufwand fällt also nur beim ersten Laden an. Für Dateien, die dauerhaft über 500 MB liegen, bietet die Cloud-Validierung unter Umständen mehr Spielraum.
Birgt WebAssembly Sicherheitsrisiken?
WASM läuft in derselben Sandbox-Umgebung wie JavaScript – ohne Browser-APIs, die denselben Sicherheitsrichtlinien wie jeder andere Webinhalt unterliegen, hat es keinen Zugriff auf Dateisystem, Betriebssystem oder Netzwerk. Die relevante Sicherheitsfrage betrifft nicht die WASM-Laufzeitumgebung selbst, sondern welche Netzwerkaufrufe die Anwendung tatsächlich ausführt – und ein korrekt implementierter Browser-Validator führt für die IFC-Datei keine aus.
Lassen sich beide Architekturen im selben Projektworkflow kombinieren?
Ja – das ist häufig sogar die praktikabelste Lösung. Koordinatoren führen die Browser-Validierung lokal als Vorprüfung vor jeder formalen Einreichung durch. Das CDE-Gateway nutzt die Cloud-Validierung über eine API für den Prüfpfad und die automatisierte Abnahme. Die Browser-Prüfung ist schnell und privat, die Cloud-Prüfung liefert den offiziellen Nachweis und das organisationsweite Reporting. Beide Architekturen decken unterschiedliche Bedürfnisse ab und ergänzen sich.
Zusammenfassung
Wohin eine IFC-Datei während der Validierung gelangt, ist kein technisches Detail. Es ist eine Datenmanagement-Entscheidung, die für einen großen Teil der AEC-Projekte über die regulatorische Konformität entscheidet.
IFC Viewer Blog
Sensible Projekte: browserorientiert
Regierungs-, Verteidigungs-, Gesundheits- und Infrastrukturprojekte sollten standardmäßig auf die Browser-Validierung setzen. Sie ist oft nicht nur die bequemere, sondern die einzig konforme Option. Daten verlassen das Gerät nie.
Automatisierung und Stapelverarbeitung: Cloud
CI/CD-Pipelines, Portfolio-Audits und zentralisiertes Reporting erfordern eine Cloud-Architektur. Eine Browser-Sitzung kann nicht an headless automatisierten Workflows teilnehmen oder Ergebnisse teamübergreifend aggregieren.
Tägliche Validierung: Der Browser gewinnt bei der Geschwindigkeit
Keine Upload-Zeit, durch OPFS beschleunigtes wiederholtes Laden und kein Konto erforderlich. Für die Prüfungen vor der Lieferung, die den täglichen Workflow eines Koordinators prägen, ist die Browser-Verarbeitung bei allen gängigen Modellgrößen schneller als die Cloud.
Was die 44 Qualitätsregeln tatsächlich prüfen – und wie sie sich zur Schemavalidierung und zu IDS verhalten – erklärt der vollständige Leitfaden zum IFC-Model-Checker. Zum Health Score, der die Qualität in einer einzigen Kennzahl zusammenfasst, siehe den Leitfaden zum IFC Health Score. Wenn Sie Eigenschaftswerte oder GUIDs einer erhaltenen IFC-Datei korrigieren müssen, ohne sie irgendwohin hochzuladen, wendet der kostenlose Online-IFC-Editor dieselbe browserorientierte Architektur auf das zerstörungsfreie Bearbeiten von Eigenschaften an.
Browserbasierte IFC-Validierung vs. Cloud: Die Architekturentscheidung, die BIM-Teams falsch treffen