Torna al blog BIM i IFC
Privadesa i seguretat · 2026-06-28 · 19 min
Validació IFC al navegador o al núvol: la decisió d'arquitectura que els equips BIM solen errar
Validació d'IFC sense connexió amb WebAssembly: no es puja res i funciona a l'obra. Visor IFC al navegador versus al núvol: privadesa, RGPD, velocitat de pujada, ús fora de línia i quan guanya cada arquitectura.
Validació IFC al navegador o al núvol: la decisió d'arquitectura que els equips BIM solen errar — IFC Viewer Online article cover
- 0 bytes — pujats en la validació al navegador
- 40 s — per pujar 50 MB a 10 Mbps
- 44 — regles comprovades en el costat client
- 10× — càrregues repetides més ràpides gràcies a la memòria cau d'OPFS
Quan un coordinador BIM pregunta «on puc validar el meu fitxer IFC?», la resposta que sol rebre és un URL. Un servei al núvol. Pujar el model, esperar, obtenir l'informe. Aquest és el model mental per defecte per a la validació IFC, i és la tria equivocada per a una part important dels projectes on s'aplica.
Hi ha dues arquitectures fonamentalment diferents per a la validació IFC. Entendre la diferència, i saber quina és la correcta per a cada projecte, és cada cop més una competència professional per als BIM managers i els equips de construcció digital. L'arquitectura que tries determina, en una sola decisió, la privadesa, la velocitat, el compliment normatiu i la disponibilitat fora de línia.
Dues arquitectures completament diferents
La distinció no és un detall de producte. És una qüestió d'on té lloc el càlcul, i això determina tot el que ve després.
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
En l'arquitectura A, el fitxer IFC és processat per una infraestructura que no controles. Travessa una xarxa, resideix en un servidor de tercers i el gestiona un programari que no has desplegat tu. En l'arquitectura B, la mateixa lògica de validació s'executa dins del teu navegador mitjançant WebAssembly compilat a partir del mateix codi en C++ que fa funcionar les eines BIM d'escriptori natives: res no surt del dispositiu, i cap tercer intervé en el processament.
Per què els models IFC contenen informació sensible
L'instint de tractar els fitxers IFC com si fossin PDF (compartibles, pujables i arxivables a qualsevol lloc) infravalora el que hi ha incrustat en un model d'edifici complex. Un fitxer IFC és una base de dades estructurada d'informació d'actius. Per a molts tipus de projecte, aquesta informació és genuïnament sensible, restringida o classificada.
Administració pública i infraestructures cíviques
Jutjats, oficines governamentals, centres de dades, serveis públics crítics. Dades de vulnerabilitat estructural, disposicions de sistemes d'emergència i esquemes d'infraestructura de seguretat, incrustats com a geometria i propietats IFC.
Aeroports i nusos de transport
Geometria dels controls de seguretat, disposicions del perímetre d'accés a pista, ubicació de CCTV i sensors, encaminament de sistemes d'emergència. Subjecte a classificació de seguretat aèria i de seguretat nacional en la majoria de jurisdiccions.
Hospitals i sanitat
Infraestructura de flux de pacients, redundància del subministrament de gasos medicinals, disposicions d'unitats de crítics. Subjecte als requisits del NHS IG (Regne Unit) i de la HIPAA (EUA). Dades estructurals de sistemes de suport vital.
Ferrocarril i trànsit crític
Geometria de túnels, infraestructura de senyalització, vies d'evacuació d'emergència, topologia del subministrament elèctric. Sovint classificat com a infraestructura crítica nacional, amb prohibicions explícites de pujada a tercers.
Plantes industrials i de procés
Disposició d'equips de procés, geometria de contenció de materials perillosos, ubicació de sistemes de seguretat. Subjecte a la normativa COMAH / SEVESO III a la UE. Dades de procés comercialment sensibles.
Defensa i àmbit militar
Explícitament restringit en la majoria de països per la normativa de contractació de defensa. Els fitxers IFC d'infraestructura militar no es poden pujar legalment a serveis al núvol comercials sense una habilitació de seguretat específica i una aprovació contractual.
Més enllà del tipus de projecte, els fitxers IFC incrusten metadades que qualifiquen com a sensibles sota diversos marcs legals. El camp FILE_NAME de la capçalera del fitxer STEP conté noms d'autor i d'organització. Les propietats d'IfcProject porten identificadors de client i de projecte. Els models de planificació d'espais poden incloure recomptes d'ocupants i distribució de personal. Els conjunts de propietats poden revelar capacitats de sistemes, especificacions estructurals i característiques operatives d'una instal·lació: el tipus d'informació que fa viable l'espionatge industrial.
L'angle del RGPD i el tractament de dades
L'article 4 del RGPD defineix les dades personals de manera àmplia: inclou qualsevol informació relativa a una persona física identificada o identificable. En el BIM, això inclou: noms d'ocupants en l'assignació d'espais, dades de contacte del propietari en les metadades d'IfcProject, recomptes de personal en els càlculs d'evacuació contra incendis i, de vegades, codis de referència d'actius si es poden vincular a persones identificables mitjançant altres conjunts de dades.
A la pràctica, la majoria de grans empreses d'AEC i organismes del sector públic tenen polítiques de tractament de dades que, tècnicament, prohibeixen pujar models de projecte a serveis de tercers no aprovats. Aquestes polítiques s'ignoren sovint a nivell de coordinador perquè la política resideix en un sistema de gestió documental i l'URL del validador es va compartir en un fòrum de la comunitat. La validació al navegador converteix el compliment normatiu en el camí de menys resistència: elimina del tot la decisió de pujar el fitxer.
Com WebAssembly va canviar les eines BIM al navegador
Per entendre per què la validació al navegador és ara tècnicament creïble cal entendre què va canviar. Abans del 2017, cap fabricant de programari BIM es plantejava seriosament executar un analitzador d'IFC genuí en un navegador. El navegador només podia executar JavaScript, i JavaScript és el llenguatge equivocat per analitzar el format STEP de la norma ISO 10303-21 a la velocitat que exigeix la producció.
Abans de WebAssembly: la situació anterior al 2017
- L'anàlisi d'IFC exigia processament al servidor: els validadors al núvol existien no com una comoditat, sinó com l'única arquitectura viable. No hi havia cap alternativa competitiva en rendiment.
- Els visors IFC al navegador feien servir formats intermedis preprocessats (extractes de geometria en JSON, malles simplificades) en lloc d'analitzar l'IFC en temps real. El que veies no era l'IFC: era una aproximació generada pel servidor.
- Un fitxer IFC de 50 MB analitzat en JavaScript pur trigava minuts i provocava blocatges de pestanya en màquines amb poca memòria. Un fitxer de 200 MB era, a la pràctica, impossible en un navegador.
- El renderitzat 3D era WebGL en una fase inicial: accelerat per GPU, però limitat a complexitats d'escena gestionables des de JavaScript. Els models estructurals grans amb centenars de milers d'elements no eren viables.
- Els Web Workers oferien aïllament de fils, però cap manera d'executar codi natiu compilat. El rendiment quedava limitat per les pauses del recol·lector d'escombraries de JavaScript i el seu model d'execució en un sol fil.
Després de WebAssembly: què és possible ara
WebAssembly (WASM) és un format d'instruccions binari per a una màquina virtual basada en pila que s'executa al navegador a una velocitat gairebé nativa. El codi escrit en C, C++ o Rust es compila a WASM i s'executa a aproximadament un 60–90% de la velocitat nativa dins de qualsevol navegador modern: sense connectors, sense instal·lació, amb aïllament total de memòria i un sandbox garantit. WASM es va convertir en estàndard del W3C el 2019 i és disponible en tots els navegadors principals.
Específicament per a l'IFC: web-ifc, l'analitzador que utilitza la biblioteca @thatopen/components, es compila de C++ a WebAssembly. Analitza el format STEP d'IFC a la mateixa classe de velocitat que les biblioteques natives d'escriptori. Un fitxer IFC de 50 MB s'analitza en menys de 10 segons en un portàtil modern, dins d'una pestanya del navegador, sense cap servidor implicat. La mateixa classe de rendiment que carregar un fitxer local a Solibri o Navisworks, però en un navegador.
WASM: velocitat de C++ al navegador
web-ifc es compila de C++ a WebAssembly. L'anàlisi del format STEP d'IFC s'executa a un 60–90% de la velocitat nativa: la mateixa classe de rendiment que les eines BIM d'escriptori. Un model de 50 MB s'analitza en menys de 10 segons en un portàtil modern.
Web Workers: paral·lelisme real
L'anàlisi WASM s'executa en un Web Worker dedicat: un fil del sistema operatiu separat. La interfície del navegador es manté responsiva durant la càrrega pesant de models. La validació s'executa en un worker paral·lel, i dona resultats mentre es carrega la geometria.
OPFS: memòria cau local persistent
L'Origin Private File System és una API d'emmagatzematge nativa del navegador, aïllada per origen i inaccessible per als servidors. La geometria analitzada s'escriu a OPFS després de la primera càrrega. Les càrregues repetides són ~10 vegades més ràpides: sense tornar a analitzar, sense tornar a pujar.
WebGL / WebGPU: renderitzat per GPU
Three.js abstrau WebGL per a un renderitzat 3D d'alt rendiment. La gestió d'escena basada en fragments gestiona models amb centenars de milers d'elements a velocitats de fotogrames interactives. El suport de WebGPU arribarà per a la pròxima generació de renderitzat.
La memòria cau d'OPFS: per què les càrregues repetides canvien el flux de treball
L'Origin Private File System és una capa d'emmagatzematge nativa del navegador, aïllada respecte a l'origen web actual. Altres orígens, altres pestanyes del navegador i, sobretot, els servidors remots no poden accedir-hi. Persisteix entre sessions del navegador. Per als fluxos de treball amb IFC, OPFS resol la fricció més dolorosa en les eines de models pesants: el cost de tornar a analitzar.
Un fitxer IFC de 250 MB analitzat des de zero triga entre 20 i 40 segons en una màquina moderna. El mateix fitxer carregat des de la memòria cau d'OPFS es carrega en 2–3 segons. Per a un coordinador BIM que obre el mateix model de projecte diverses vegades al dia, OPFS marca la diferència entre una eina que se sent ràpida i una que se sent com una espera constant. I com que l'emmagatzematge d'OPFS està aïllat per origen i resideix en el sistema de fitxers local, les dades del model desades en la memòria cau mai no arriben a un servidor: hereten la mateixa garantia de privadesa que la mateixa validació al navegador.
El coll d'ampolla de la pujada: xifres reals
El cost més infravalorat de la validació IFC al núvol és, amb diferència, el temps de pujada. És invisible en les comparatives de producte, però domina el flux de treball real. Això és el que sembla pujar mides habituals de fitxers IFC en diferents tipus de connexió realistes, i com es compara amb el processament local al navegador:
| Mida del fitxer IFC | Oficina (10 Mbps de pujada) | 4G mòbil (3 Mbps) | A l'obra (1 Mbps) |
|---|
| 50 MB | ~40 segons | ~2 min 15 s | ~7 minuts |
| 250 MB | ~3 min 20 s | ~11 minuts | ~33 minuts |
| 1 GB | ~13 minuts | ~45 minuts | ~2 h 15 min |
| 2 GB | ~27 minuts | ~1 h 30 min | ~4 h 30 min |
Només el temps de pujada; cal afegir-hi el processament del servidor: 50 MB +5–15 s · 250 MB +30–90 s · 1 GB +2–6 min · 2 GB +5–15 min. Validació al navegador: 0 s de pujada en tots els casos.Un model de 250 MB: minuts abans que la comprovació pugui començar
- Navegador, anàlisi local (sense pujada): 0.7 min — 20–40 s de primera anàlisi en una estació de treball moderna
- Pujada des de l'oficina (10 Mbps): 3.3 min
- Pujada per 4G (3 Mbps): 11 min
- Pujada des de l'obra (1 Mbps): 33 min
Només temps de pujada per a les eines basades en servidor; el seu processament n'afegeix 30–90 s més.
Un fitxer IFC de 250 MB —un model de coordinació típic per a un projecte comercial mitjà— triga més de 3 minuts a pujar-se amb una connexió d'oficina ràpida. Per 4G, en triga 11. Per a un coordinador BIM que fa comprovacions prèvies al lliurament diverses vegades al dia, només el temps de pujada afegeix hores d'espera morta cada setmana. La validació en si mateixa suposa una fracció del temps de pujada.
A les obres, on la connectivitat 4G és la norma i l'ample de banda es comparteix entre les oficines d'obra i les tauletes BIM, pujar un fitxer IFC d'1 GB és un compromís de 45 minuts abans que s'executi ni una sola regla de validació. La validació al navegador processa el mateix fitxer localment en 90–180 segons sense cap dependència de xarxa, i en 2–5 segons en sessions posteriors gràcies a la memòria cau d'OPFS.
La comparativa completa: validació IFC al navegador vs al núvol
| Dimensió | Validació al navegador | Validació al núvol |
|---|
| Privadesa | ✅ El fitxer mai no surt del dispositiu | ⚠️ El fitxer es puja a un servidor |
| Sobirania de dades | ✅ Sense custòdia de tercers | ⚠️ Custòdia de dades per tercers |
| Compliment del RGPD | ✅ Compleix per disseny | ⚠️ Requereix DPA i base legal |
| Projectes sensibles | ✅ Sovint l'única opció | ❌ Sovint prohibit |
| Velocitat (petits <50 MB) | ✅ Gairebé instantani | ⚠️ Retard de pujada i processament |
| Velocitat (grans >250 MB) | ✅ Sense penalització de pujada | ❌ Coll d'ampolla de pujada |
| Càrregues repetides | ✅ Memòria cau OPFS (~10x més ràpid) | ❌ Tornar a pujar-ho tot cada vegada |
| Temps de pujada | ✅ Zero | ❌ Proporcional a la mida del fitxer |
| Disponibilitat fora de línia | ✅ Suport total fora de línia | ❌ Requereix internet |
| Ús a l'obra | ✅ Funciona amb 4G o sense connexió | ❌ Lent o poc fiable a l'obra |
| Dependència d'internet | ✅ Cap (després de la càrrega inicial) | ❌ Necessària a cada execució |
| Processament per lots | ❌ Manual, d'un en un | ✅ Automatització per API/lots |
| Integració CI/CD | ❌ No adequat | ✅ Webhook/API natius |
| Registre d'auditoria de l'equip | ⚠️ Només local | ✅ Historial centralitzat |
| Informes a escala d'organització | ⚠️ No agregats | ✅ Tauler entre projectes |
| Seguretat (dades) | ✅ Sense risc de trànsit o servidor | ⚠️ Exposició en trànsit i al servidor |
| Seguretat (bretxes) | ✅ Cap servidor a comprometre | ⚠️ Depèn del proveïdor de núvol |
| Fitxers molt grans >2 GB | ⚠️ Limitat per la RAM del dispositiu | ✅ El servidor té més RAM |
| Cost | ✅ Gratuït o de cost baix | ⚠️ Per ús o per subscripció |
| Càrrega d'infraestructura | ✅ Zero: s'executa al navegador | ✅ Gestionada pel proveïdor |
| Complexitat de configuració | ✅ Obrir l'URL, arrossegar el fitxer | ⚠️ Cal compte o clau d'API |
On la validació al núvol és realment millor
Una comparativa que només destaca un dels dos costats és propaganda. La validació IFC al núvol té avantatges reals en contextos concrets, i aplicar la validació al navegador en aquests contextos és la tria equivocada.
Pipelines de CI/CD automatitzats
Validació activada automàticament a cada commit del model, de manera anàloga a les proves unitàries de programari. Les API al núvol amb resposta per webhook són l'única arquitectura per a l'automatització sense interfície (headless). No hi ha cap sessió de navegador per executar WASM en un pipeline del costat servidor.
Processament per lots a escala de cartera
Auditar centenars de fitxers IFC existents en una cartera de projectes —una migració de dades heretades, una auditoria d'arxiu del CDE— és pràctic mitjançant API de lots al núvol, i impracticable de fer manualment al navegador un fitxer cada vegada.
Informes centralitzats de l'equip
Un BIM manager necessita una visió única de l'historial de validació de diversos projectes i originadors: tendències de puntuació, freqüència d'incidències, compliment al llarg del temps. Els serveis al núvol ho agreguen. Les eines al navegador només produeixen resultats locals.
Integració amb la passarel·la del CDE
Alguns CDE validen automàticament les pujades d'IFC entrants abans d'acceptar-les. Això és, per naturalesa, una operació del costat servidor: qui processa el fitxer és el servidor del CDE, no el navegador d'un usuari. Les API de validació al núvol són el punt d'integració.
Validació al navegador: el millor encaix
- Projectes governamentals i del sector públic
- BIM de defensa, infraestructures i aeroports
- Models d'hospitals i instal·lacions sanitàries
- Enginyeria de plantes industrials i de procés
- Models amb polítiques de RGPD o restricció de dades
- Validació a l'obra i fora de línia
- Comprovació prèvia abans d'un enviament formal al núvol
- Coordinadors individuals i equips petits
Validació al núvol: el millor encaix
- Pipelines de validació CI/CD automatitzats
- Auditories de qualitat per lots a escala de cartera
- Taulers centralitzats de qualitat BIM
- Passarel·la del CDE i portes de lliurament automatitzades
- Projectes comercials no sensibles a gran escala
- Automatització de fluxos de treball multiequip empresarials
- Integració impulsada per API amb altres sistemes
- Fitxers molt grans que superen la RAM local disponible
Cinc idees errònies sobre la validació IFC al navegador
Idea errònia 1: «Les aplicacions al navegador són més lentes que les del núvol»
Això era cert el 2015. Ara no ho és. El codi WebAssembly s'executa a un 60–90% de la velocitat nativa de C++ dins d'un navegador modern. El motor d'anàlisi d'IFC (web-ifc) es compila a partir de C++: la mateixa categoria de rendiment que les biblioteques que fan funcionar Solibri, els importadors d'IFC d'Autodesk i IfcOpenShell. Combinat amb una latència de pujada zero, la validació al navegador és sovint més ràpida que la del núvol per a mides de model habituals, especialment en connexions per sota de 50 Mbps de pujada.
Aquesta idea errònia persisteix perquè la gent compara el JavaScript del navegador (lent i amb recol·lecció d'escombraries) amb aplicacions natives compilades (ràpides). Les eines BIM modernes al navegador no executen el processament pesant en JavaScript: executen WASM compilat a velocitat gairebé nativa, i JavaScript només orquestra el flux de treball. La distinció entre JS i WASM és tan significativa com la diferència entre Python i C++.
Idea errònia 2: «Cal pujar un fitxer IFC per validar-lo»
Això és fals. Quan obres un fitxer IFC en un validador al navegador, el navegador crea un objecte File en la memòria local, accessible per a WASM i JavaScript que s'executen en aquest context del navegador, però no es transmet a cap punt de xarxa tret que el codi cridi explícitament una API fetch o XHR. Ho pots verificar tu mateix: obre l'inspector de xarxa del navegador (F12 → pestanya Network) i comprova que no es produeix cap pujada quan s'obre i es valida un model.
Idea errònia 3: «Els fitxers IFC grans no poden funcionar en un navegador»
Els navegadors moderns poden assignar diversos gigabytes de RAM en maquinari habitual d'estació de treball. Un fitxer IFC de 250 MB en memòria n'ocupa 250 MB, ben dins del que un procés de navegador pot assignar en una màquina amb 16 GB. Els Web Workers ho amplien amb accés a memòria fora del fil principal. Per a fitxers per sobre de 500 MB, la càrrega espacial fragmentada fa viable el processament al navegador fins i tot amb restriccions de memòria més estrictes. OPFS garanteix que un model gran, un cop analitzat, no calgui tornar-lo a analitzar mai més en sessions posteriors.
Idea errònia 4: «El núvol sempre és més segur»
La seguretat és multidimensional, no un atribut únic. Els serveis al núvol solen xifrar les dades en trànsit (TLS 1.3) i en repòs (AES-256), cosa que aborda la intercepció passiva. Però introdueixen superfícies d'atac que el processament al navegador elimina del tot: compromís del costat servidor, contenidors d'emmagatzematge mal configurats, accés intern per part d'empleats del proveïdor de núvol, atacs a la cadena de subministrament de la infraestructura del proveïdor i infraccions de residència de dades si el servidor es troba fora de les jurisdiccions exigides contractualment.
Un fitxer que mai no surt del dispositiu té exposició zero a qualsevol amenaça basada en xarxa. La pregunta de seguretat no és «quina arquitectura és més segura en termes absoluts?», sinó «quins models d'amenaça són més rellevants per a aquest projecte?». Per a un model d'una instal·lació d'un Ministeri de Defensa, el processament al navegador elimina del tot el vector d'amenaça de la pujada. Per a un projecte comercial no sensible on el registre centralitzat importa, els controls al núvol poden ser el compromís correcte.
Idea errònia 5: «La validació al navegador no és de nivell empresarial»
El programari de nivell empresarial es defineix per la fiabilitat, la profunditat de funcionalitats i la capacitat de suport institucional, no per l'arquitectura de desplegament. Figma, AutoCAD Web, Google Earth i Microsoft Office per a la web són aplicacions de nivell empresarial que s'executen al navegador mitjançant WebAssembly i API web modernes. El mateix entorn d'execució WASM, els mateixos Web Workers i la mateixa infraestructura WebGL que fan funcionar aquestes aplicacions també fan funcionar la validació IFC al navegador. «Basat en navegador» és una decisió d'arquitectura sobre on té lloc el càlcul, no un sostre de qualitat.
Resolució de problemes de la validació al navegador
El model es carrega però la validació sembla lenta
La validació s'executa en un Web Worker separat i no bloqueja la interfície: el model 3D hauria de mantenir-se interactiu mentre la validació s'executa en segon pla. Si tot el procés de càrrega sembla lent, comprova si el model es carrega des de la memòria cau d'OPFS (ràpid) o s'analitza des de zero (més lent per a fitxers grans). En la primera càrrega, un fitxer de 200 MB trigarà 20–40 segons a analitzar-se, fins i tot localment. Les càrregues següents des de la memòria cau triguen 2–5 segons.
Sense memòria disponible amb fitxers molt grans
Els fitxers per sobre de 400–500 MB poden esgotar la memòria del navegador en màquines amb 8–16 GB de RAM. Símptomes: la pestanya del navegador es bloqueja o deixa de respondre. Solucions: tanca altres pestanyes del navegador per alliberar memòria, fes servir una màquina amb 16 GB de RAM o més, o divideix un model federat en fitxers per disciplina abans de carregar-lo. Per a fitxers que superin sistemàticament els 500 MB, la validació al núvol pot ser l'arquitectura més adequada: el maquinari de servidor sol tenir més marge de RAM.
La memòria cau d'OPFS creix molt amb el temps
OPFS desa fragments de geometria analitzada per a cada model carregat. Per a un equip de projecte que carrega molts models al llarg de setmanes, la memòria cau pot arribar a diversos gigabytes. El Gestor de memòria cau del validador mostra tots els fitxers desats amb la seva mida i permet esborrar-los de manera selectiva. La configuració d'emmagatzematge del navegador també permet esborrar tot l'emmagatzematge de l'origen. La memòria cau es desa en el dispositiu local i no és accessible per a cap servidor remot.
Els resultats de la validació difereixen entre el navegador i el núvol
Si els resultats difereixen, la causa més habitual és que s'apliquen conjunts de regles diferents. La validació al navegador (44 regles de qualitat) i la validació d'esquema al núvol (compliment d'ISO 10303-21) comproven coses diferents, no les mateixes regles en llocs diferents. Consulta la guia de capes de validació per veure la distinció entre la comprovació d'esquema de nivell 1, la comprovació de qualitat de nivell 2 i l'IDS de nivell 3. Un resultat IDS hauria de ser idèntic entre dos motors conformes a l'especificació que executin el mateix fitxer .ids sobre el mateix model.
On encaixa IFC Viewer Online en aquesta arquitectura
IFC Viewer Online és una implementació al navegador de l'arquitectura B. L'analitzador d'IFC (web-ifc compilat a WASM), el motor de validació de 44 regles, el càlcul del Health Score, el motor de comprovació IDS 1.0, el panell BCF i el renderitzador 3D (Three.js via WebGL) s'executen tots al navegador. No es puja res. L'arquitectura ho garanteix a nivell d'implementació: no hi ha cap punt final del costat servidor on enviar les dades del model.
Anàlisi WASM en un Web Worker
web-ifc (C++ → WASM) s'executa en un fil worker dedicat. La interfície es manté responsiva durant càrregues de models grans. Un fitxer de 50 MB s'analitza en menys de 10 segons. Un de 200 MB, en 20–40 segons. El primer resultat: local. Sempre.
Memòria cau OPFS per a càrregues repetides
Els fragments de geometria analitzada persisteixen a OPFS després de la primera sessió. Les càrregues repetides són ~10 vegades més ràpides: sense tornar a analitzar, sense dependència de xarxa. La memòria cau és privada a l'origen del navegador i inaccessible per a servidors remots.
44 regles de qualitat + IDS 1.0
44 regles de qualitat de model (integritat estructural, ISO 19650, Psets, classificació, LOD, MEP) més un motor IDS 1.0 de buildingSMART provat contra els 100 casos de prova oficials de bSI: tot al costat client.
Edició de propietats no destructiva
Els noms d'elements, els valors de conjunts de propietats i els GlobalId es poden editar en fitxers IFC rebuts sense passar de nou pel programari d'autoria, i sense pujar-los a cap servidor.
Recomanacions d'expert: triar l'arquitectura correcta
La tria entre validació al navegador i al núvol és una decisió de governança a nivell de projecte, no una preferència d'eina. Aquesta és la lògica de decisió per als escenaris més habituals:
- Projectes governamentals, de defensa, aeroportuaris, ferroviaris, hospitalaris i de plantes industrials: la validació al navegador hauria de ser la tria per defecte. Comprova si la política de tractament de dades de la teva organització permet pujar el model abans de considerar el núvol. Si la política no ho contempla, assumeix que la pujada està prohibida i demana aclariment al teu delegat de protecció de dades.
- Projectes comercials sense classificació de dades: qualsevol de les dues arquitectures és viable. Fes servir el núvol per a registres d'auditoria centralitzats i integració CI/CD. Fes servir el navegador per rapidesa, preferència de privadesa i capacitat fora de línia.
- Comprovacions diàries de qualitat prèvies al lliurament per part de coordinadors individuals: la validació al navegador és més ràpida, més senzilla, no requereix compte i elimina l'espera de la pujada. Executa-la localment abans de qualsevol enviament formal al CDE.
- Auditories de cartera o avaluacions de compliment del CDE en molts models: el processament per lots al núvol és l'eina adequada. Passar 200 models per una API al núvol i obtenir un informe de qualitat consolidat és impracticable en un navegador.
- Porta de lliurament automatitzada dins d'un CDE: la validació al núvol amb integració d'API és l'única arquitectura pràctica. No hi ha cap context de navegador disponible en un flux de treball automatitzat del costat servidor.
- Flux de treball híbrid: fes servir la validació al navegador com la porta de qualitat diària (ràpida, privada, sense compte necessari), i reserva el núvol per a l'enviament formal al CDE, on un registre d'auditoria, una integració d'API o l'automatització per lots aporten un valor genuí. Aquestes arquitectures es complementen.
Preguntes freqüents
És realment privada la validació IFC al navegador?
Sí, quan està implementada correctament. WebAssembly s'executa en un entorn aïllat del navegador. L'objecte File que conté les dades IFC es crea en la memòria local del navegador. Perquè aquestes dades arribin a un servidor, el codi ha de cridar explícitament una API de xarxa. Un validador de navegador ben implementat no fa cap crida d'aquest tipus per al fitxer IFC. Verifica-ho obrint l'inspector de xarxa del navegador (F12 → pestanya Network) i comprovant que no es produeix cap pujada quan obres i valides un model.
Pot funcionar sense connexió la validació al navegador?
Sí, amb una salvetat. Cal carregar l'aplicació en si almenys un cop en línia: el binari WASM i els paquets de JavaScript es descarreguen en la primera visita. A partir d'aquí, una aplicació web progressiva pot funcionar totalment fora de línia. Els models desats a OPFS es carreguen sense cap accés a la xarxa. Per a visites a obra amb connectivitat poc fiable, carregar l'aplicació i desar prèviament el model del projecte la nit abans garanteix la disponibilitat fora de línia l'endemà.
Quin és el límit pràctic de mida de fitxer per a la validació al navegador?
En maquinari amb 16 GB de RAM (una estació de treball moderna típica o un portàtil d'alta gamma), els fitxers fins a 400–500 MB es processen de manera fiable. En màquines de 8 GB, el límit pràctic ronda els 200–250 MB abans que la pressió de memòria provoqui inestabilitat. La memòria cau d'OPFS elimina el cost de tornar a analitzar, de manera que el primer processament és l'única vegada que pagues tot el cost de càlcul. Per a fitxers que superin sistemàticament els 500 MB, la validació al núvol pot oferir més marge.
Introdueix WebAssembly riscos de seguretat?
WASM s'executa en el mateix entorn aïllat que JavaScript: no pot accedir al sistema de fitxers, al sistema operatiu ni a la xarxa sense passar per les API del navegador, subjectes a les mateixes polítiques de seguretat que qualsevol contingut web. La pregunta de seguretat rellevant no és l'entorn d'execució WASM en si, sinó quines crides de xarxa fa l'aplicació, i un validador de navegador ben implementat no en fa cap per al fitxer IFC.
Puc fer servir les dues arquitectures en el mateix flux de treball d'un projecte?
Sí, i sovint és la combinació més pràctica. Els coordinadors executen la validació al navegador localment com a comprovació prèvia abans de qualsevol enviament formal. La passarel·la del CDE fa servir la validació al núvol amb una API per al registre d'auditoria i l'acceptació automatitzada. La comprovació al navegador és ràpida i privada; la comprovació al núvol aporta el registre oficial i els informes a escala d'organització. Les dues arquitectures cobreixen necessitats diferents i es complementen.
Resum
On va un fitxer IFC durant la validació no és un detall tècnic. És una decisió de governança de dades que determina el compliment normatiu d'una gran part dels projectes d'AEC.
IFC Viewer Blog
Projectes sensibles: navegador primer
Els projectes governamentals, de defensa, sanitaris i d'infraestructures haurien de tenir la validació al navegador com a opció per defecte. Sovint és l'única opció que compleix la normativa, no només la més còmoda. Les dades mai no surten del dispositiu.
Automatització i lots: núvol
Els pipelines de CI/CD, les auditories de cartera i els informes centralitzats requereixen arquitectura al núvol. Una sessió de navegador no pot participar en fluxos de treball automatitzats sense interfície ni agregar resultats entre equips.
Validació diària: el navegador guanya en velocitat
Zero temps de pujada, càrregues repetides accelerades per OPFS i cap compte necessari. Per a les comprovacions prèvies al lliurament que defineixen el flux de treball diari d'un coordinador, el processament al navegador és més ràpid que el del núvol en totes les mides de model habituals.
Per entendre què comproven realment les 44 regles de qualitat, i com es relacionen amb la validació d'esquema i l'IDS, consulta la guia completa del verificador de models IFC. Per al Health Score que resumeix la qualitat en un sol número, consulta la guia del Health Score d'IFC. Si necessites corregir valors de propietats o GUID en un fitxer IFC rebut sense pujar-lo enlloc, l'editor d'IFC en línia gratuït aplica la mateixa arquitectura basada en el navegador a l'edició no destructiva de propietats.
Validació IFC al navegador o al núvol: la decisió d'arquitectura que els equips BIM solen errar