Torna al blog BIM e IFC
Privacy e sicurezza · 2026-06-28 · 19 min
Validazione IFC nel browser o nel cloud: la decisione architetturale che i team BIM sbagliano
Validazione IFC offline tramite WebAssembly: nulla viene caricato, funziona in cantiere. Validatore IFC nel browser o nel cloud: privacy, GDPR, velocità di upload, uso offline e quando conviene ciascuna architettura.
Validazione IFC nel browser o nel cloud: la decisione architetturale che i team BIM sbagliano — IFC Viewer Online article cover
- 0 byte — caricato con la validazione nel browser
- 40 sec — per caricare 50 MB a 10 Mbps
- 44 — regole verificate lato client
- 10× — caricamenti ripetuti più veloci grazie alla cache OPFS
Quando un BIM coordinator chiede 'dove posso validare il mio file IFC?', la risposta che riceve di solito è un URL. Un servizio cloud. Carica il modello, aspetta, ottieni il report. È questo il modello mentale predefinito per la validazione IFC — ed è la scelta sbagliata per una parte significativa dei progetti in cui viene applicato.
Esistono due architetture fondamentalmente diverse per la validazione IFC. Capire la differenza — e sapere quale sia adatta a quale progetto — è sempre più una competenza professionale per i BIM manager e i team di digital construction. L'architettura scelta determina, in un'unica decisione, privacy, velocità, conformità normativa e disponibilità offline.
Due architetture completamente diverse
Non è un dettaglio di prodotto. È una questione di dove avviene l'elaborazione — e questo determina tutto ciò che segue.
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
Nell'Architettura A, il file IFC viene elaborato da un'infrastruttura che non controlli. Attraversa una rete, risiede su un server di terze parti ed è gestito da software che non hai distribuito tu. Nell'Architettura B, la stessa logica di validazione viene eseguita all'interno del tuo browser tramite WebAssembly, compilato dallo stesso codice C++ che alimenta gli strumenti BIM desktop nativi: nulla lascia il dispositivo e nessuna terza parte è coinvolta nell'elaborazione.
Perché i modelli IFC contengono informazioni sensibili
L'istinto di trattare i file IFC come dei PDF — condivisibili, caricabili, archiviabili ovunque — sottostima ciò che è incorporato in un modello edilizio complesso. Un file IFC è un database strutturato di informazioni sull'asset. Per molte tipologie di progetto, queste informazioni sono realmente sensibili, riservate o classificate.
Edifici governativi e infrastrutture civiche
Tribunali, uffici governativi, data center, utility critiche. Dati sulla vulnerabilità strutturale, planimetrie dei sistemi di emergenza e schemi delle infrastrutture di sicurezza incorporati come geometria e proprietà IFC.
Aeroporti e hub di trasporto
Geometria dei varchi di sicurezza, planimetrie dei confini lato aria, posizionamento di telecamere e sensori, percorsi dei sistemi di emergenza. Soggetti, nella maggior parte delle giurisdizioni, a classificazione per la sicurezza aeronautica e nazionale.
Ospedali e sanità
Infrastrutture per il flusso dei pazienti, ridondanza dell'alimentazione dei gas medicali, planimetrie delle unità di terapia intensiva. Soggetti ai requisiti NHS IG (Regno Unito) e HIPAA (Stati Uniti). Dati strutturali dei sistemi salvavita.
Ferrovie e trasporti critici
Geometria delle gallerie, infrastrutture di segnalamento, vie di fuga in emergenza, topologia dell'alimentazione elettrica. Spesso classificati come infrastrutture critiche nazionali, con espliciti divieti di caricamento verso terze parti.
Impianti industriali e di processo
Planimetria delle apparecchiature di processo, geometria di contenimento delle sostanze pericolose, posizionamento dei sistemi di sicurezza. Soggetti alle normative COMAH / Seveso III nell'UE. Dati di processo commercialmente sensibili.
Difesa e settore militare
Esplicitamente vincolati, nella maggior parte dei paesi, dalle normative sugli appalti della difesa. I file IFC relativi a infrastrutture militari non possono essere legalmente caricati su servizi cloud commerciali senza un nulla osta di sicurezza specifico e un'approvazione contrattuale.
Al di là della tipologia di progetto, i file IFC incorporano metadati che risultano sensibili secondo diversi quadri normativi. Il campo FILE_NAME dell'header del file STEP contiene nomi di autori e organizzazioni. Le proprietà di IfcProject riportano identificativi del cliente e del progetto. I modelli di space planning possono includere il numero di occupanti e la distribuzione del personale. I set di proprietà possono rivelare capacità dei sistemi, specifiche strutturali e caratteristiche operative di una struttura — il tipo di informazioni che rende praticabile lo spionaggio industriale.
L'aspetto GDPR e la gestione dei dati
L'articolo 4 del GDPR definisce i dati personali in modo ampio: comprendono qualsiasi informazione relativa a una persona fisica identificata o identificabile. Nel BIM, questo include: nomi degli occupanti nelle assegnazioni degli spazi, dettagli di contatto del proprietario nei metadati di IfcProject, conteggi del personale nei calcoli di evacuazione antincendio e, talvolta, codici di riferimento degli asset se collegabili a persone identificabili tramite altri set di dati.
In pratica, la maggior parte delle grandi aziende AEC e degli enti pubblici dispone di policy di gestione dei dati che vietano tecnicamente il caricamento dei modelli di progetto su servizi di terze parti non approvati. Queste policy vengono spesso ignorate a livello di coordinatore, perché la policy risiede in un sistema di gestione documentale mentre l'URL del validatore è stato condiviso in un forum della community. La validazione nel browser rende la conformità la strada di minor resistenza: elimina del tutto la decisione di caricare il file.
Come WebAssembly ha cambiato gli strumenti BIM nel browser
Per capire perché oggi la validazione nel browser è tecnicamente credibile bisogna capire cosa è cambiato. Prima del 2017, nessun fornitore di software BIM prendeva seriamente in considerazione l'esecuzione di un vero parser IFC in un browser. Il browser poteva eseguire solo JavaScript, e JavaScript è il linguaggio sbagliato per analizzare il formato STEP ISO 10303-21 a velocità produttiva.
Prima di WebAssembly — la situazione pre-2017
- Il parsing IFC richiedeva un'elaborazione lato server: i validatori cloud esistevano non per comodità, ma come unica architettura praticabile. Non esisteva un'alternativa competitiva in termini di prestazioni.
- I visualizzatori IFC nel browser usavano formati intermedi pre-elaborati (estrazioni di geometria in JSON, mesh semplificate) anziché il parsing IFC in tempo reale. Ciò che si vedeva non era l'IFC — era un'approssimazione generata dal server.
- Un file IFC da 50 MB analizzato in puro JavaScript richiedeva minuti e provocava il crash della scheda su macchine con memoria limitata. Un file da 200 MB era di fatto impossibile in un contesto browser.
- Il rendering 3D era WebGL agli esordi: accelerato via GPU, ma limitato a complessità di scena gestibili in JavaScript. I grandi modelli strutturali con centinaia di migliaia di elementi erano impraticabili.
- I Web Worker offrivano isolamento dei thread, ma nessun modo di eseguire codice nativo compilato. Le prestazioni erano limitate dalle pause del garbage collection di JavaScript e dal modello di esecuzione a thread singolo.
Dopo WebAssembly — cosa è possibile oggi
WebAssembly (WASM) è un formato di istruzioni binario per una macchina virtuale basata su stack, eseguita nel browser a velocità quasi nativa. Il codice scritto in C, C++ o Rust viene compilato in WASM ed eseguito a circa il 60–90% della velocità nativa all'interno di qualsiasi browser moderno — senza plugin, senza installazione, con isolamento completo della memoria e sandbox garantita. WASM è diventato uno standard W3C nel 2019 ed è disponibile in tutti i principali browser.
Per l'IFC nello specifico: web-ifc — il parser usato dalla libreria @thatopen/components — è compilato da C++ a WebAssembly. Analizza il formato STEP IFC nella stessa classe di velocità delle librerie desktop native. Un file IFC da 50 MB viene analizzato in meno di 10 secondi su un laptop moderno, dentro una scheda del browser, senza alcun server coinvolto. La stessa classe di prestazioni di Solibri o Navisworks che caricano un file locale — ma nel browser.
WASM: velocità del C++ nel browser
web-ifc è compilato da C++ a WebAssembly. Il parsing STEP IFC gira al 60–90% della velocità nativa — la stessa classe di prestazioni degli strumenti BIM desktop. Un modello da 50 MB viene analizzato in meno di 10 secondi su un laptop moderno.
Web Worker: parallelismo reale
Il parsing WASM viene eseguito in un Web Worker dedicato — un thread separato del sistema operativo. L'interfaccia del browser resta reattiva durante il caricamento di modelli pesanti. La validazione gira in un worker parallelo, fornendo risultati mentre la geometria si carica.
OPFS: cache locale persistente
L'Origin Private File System è un'API di storage nativa del browser, isolata per origine e inaccessibile ai server. La geometria analizzata viene scritta in OPFS dopo il primo caricamento. I caricamenti successivi sono ~10 volte più veloci: niente ri-parsing, niente ri-caricamento.
WebGL / WebGPU: rendering su GPU
Three.js astrae WebGL per un rendering 3D ad alte prestazioni. La gestione della scena basata su frammenti gestisce modelli con centinaia di migliaia di elementi a frame rate interattivi. Il supporto WebGPU è in arrivo per il rendering di nuova generazione.
La cache OPFS: perché i caricamenti ripetuti cambiano il workflow
L'Origin Private File System è un livello di storage nativo del browser, isolato rispetto all'origine web corrente. Altre origini, altre schede del browser e — cosa fondamentale — i server remoti non possono accedere al suo contenuto. Persiste tra una sessione del browser e l'altra. Per i workflow IFC, OPFS risolve l'attrito più fastidioso nella gestione dei modelli pesanti: il costo della rielaborazione ripetuta.
Un file IFC da 250 MB analizzato da zero richiede 20–40 secondi su una macchina moderna. Lo stesso file caricato dalla cache OPFS si carica in 2–3 secondi. Per un BIM coordinator che apre lo stesso modello di progetto più volte al giorno, OPFS fa la differenza tra uno strumento che sembra veloce e uno che sembra un'attesa. E poiché lo storage OPFS è isolato per origine e risiede sul filesystem locale, i dati del modello memorizzati in cache non raggiungono mai un server — ereditano la stessa garanzia di privacy della validazione nel browser stessa.
Il collo di bottiglia dell'upload — numeri reali
Il costo più sottovalutato della validazione IFC in cloud è il tempo di upload. È invisibile nei confronti tra prodotti, ma dominante nel workflow reale. Ecco come si presenta il caricamento delle dimensioni tipiche di un file IFC su connessioni realistiche — e come si confronta con l'elaborazione locale nel browser:
| Dimensione del file IFC | Ufficio (upload 10 Mbps) | 4G mobile (3 Mbps) | Cantiere (1 Mbps) |
|---|
| 50 MB | ~40 secondi | ~2 min 15 s | ~7 minuti |
| 250 MB | ~3 min 20 s | ~11 minuti | ~33 minuti |
| 1 GB | ~13 minuti | ~45 minuti | ~2 h 15 min |
| 2 GB | ~27 minuti | ~1 h 30 min | ~4 h 30 min |
Solo tempo di upload — aggiungi l'elaborazione lato server: 50 MB +5–15 s · 250 MB +30–90 s · 1 GB +2–6 min · 2 GB +5–15 min. Validazione nel browser: 0 s di upload in tutti i casi.Un modello da 250 MB: minuti prima che il controllo possa iniziare
- Browser, parsing locale (nessun upload): 0.7 min — 20–40 s per il primo parsing su una workstation moderna
- Upload dall'ufficio (10 Mbps): 3.3 min
- Upload via 4G (3 Mbps): 11 min
- Upload dal cantiere (1 Mbps): 33 min
Solo tempo di upload per gli strumenti basati su server; la loro elaborazione aggiunge altri 30–90 s.
Un file IFC da 250 MB — un tipico modello di coordinamento per un progetto commerciale di medie dimensioni — richiede oltre 3 minuti per essere caricato su una connessione da ufficio veloce. Su 4G, ne servono 11. Per un BIM coordinator che esegue controlli pre-consegna più volte al giorno, il solo tempo di upload aggiunge ore di attesa morta ogni settimana. La validazione in sé richiede una frazione del tempo di upload.
Nei cantieri, dove la connettività 4G è la norma e la banda è condivisa tra gli uffici di cantiere e i tablet BIM, caricare un file IFC da 1 GB è un impegno di 45 minuti prima ancora che venga eseguita una sola regola di validazione. La validazione nel browser elabora lo stesso file in locale in 90–180 secondi, senza alcuna dipendenza dalla rete — e in 2–5 secondi nelle sessioni successive grazie alla cache OPFS.
Il confronto completo: validazione IFC nel browser o in cloud
| Dimensione | Validazione nel browser | Validazione cloud |
|---|
| Privacy | ✅ Il file non lascia mai il dispositivo | ⚠️ Il file viene caricato sul server |
| Sovranità dei dati | ✅ Nessuna custodia di terze parti | ⚠️ Custodia dei dati da parte di terzi |
| Conformità GDPR | ✅ Conforme per progettazione | ⚠️ Richiede DPA + base giuridica |
| Progetti sensibili | ✅ Unica opzione in molti casi | ❌ Spesso vietata |
| Velocità (file piccoli <50 MB) | ✅ Quasi istantanea | ⚠️ Ritardo di upload + elaborazione |
| Velocità (file grandi >250 MB) | ✅ Nessuna penalità di upload | ❌ Collo di bottiglia dell'upload |
| Caricamenti ripetuti | ✅ Cache OPFS (~10× più veloce) | ❌ Ri-caricamento completo ogni volta |
| Tempo di upload | ✅ Zero | ❌ Proporzionale alla dimensione del file |
| Disponibilità offline | ✅ Supporto offline completo | ❌ Richiede internet |
| Uso sul campo in cantiere | ✅ Funziona su 4G o offline | ❌ Lento / inaffidabile in cantiere |
| Dipendenza da internet | ✅ Nessuna (dopo il caricamento iniziale) | ❌ Richiesta a ogni esecuzione |
| Elaborazione in batch | ❌ Manuale, uno alla volta | ✅ API / automazione batch |
| Integrazione CI/CD | ❌ Non adatta | ✅ Webhook/API nativi |
| Tracciabilità di team | ⚠️ Solo locale | ✅ Cronologia centralizzata |
| Reporting a livello organizzativo | ⚠️ Non aggregato | ✅ Dashboard tra progetti |
| Sicurezza (dati) | ✅ Nessun rischio di transito/server | ⚠️ Esposizione di transito + server |
| Sicurezza (violazione) | ✅ Nessun server da compromettere | ⚠️ Dipende dal provider cloud |
| File molto grandi >2 GB | ⚠️ Limitata dalla RAM del dispositivo | ✅ Il server ha più RAM |
| Costo | ✅ Gratuito o a basso costo | ⚠️ A consumo o in abbonamento |
| Onere infrastrutturale | ✅ Zero — gira nel browser | ✅ Gestito dal provider |
| Complessità di setup | ✅ Apri l'URL, trascina il file | ⚠️ Richiede account/chiave API |
Dove la validazione cloud è realmente migliore
Un confronto che mette in luce solo un lato è propaganda. La validazione IFC in cloud ha vantaggi reali in contesti specifici — e applicare la validazione nel browser a quei contesti sarebbe la scelta sbagliata.
Pipeline CI/CD automatizzate
Validazione attivata automaticamente a ogni commit del modello — analoga ai test unitari del software. Le API cloud con risposte webhook sono l'unica architettura per l'automazione headless. Non esiste una sessione browser in cui eseguire WASM all'interno di una pipeline lato server.
Elaborazione batch su scala di portafoglio
Verificare centinaia di file IFC esistenti in un portafoglio di progetti — una migrazione di dati legacy, un audit dell'archivio del CDE — è praticabile tramite API cloud batch ed è impraticabile da eseguire manualmente nel browser un file alla volta.
Reporting di team centralizzato
Un BIM manager ha bisogno di una vista unica della cronologia di validazione tra più progetti e originator — andamento dei punteggi, frequenza dei problemi, conformità nel tempo. I servizi cloud aggregano questi dati. Gli strumenti nel browser producono solo risultati locali.
Integrazione con il gateway del CDE
Alcuni CDE validano automaticamente i file IFC in ingresso prima di accettarli. Si tratta intrinsecamente di un'operazione lato server: è il server del CDE a elaborare il file, non il browser dell'utente. Le API di validazione cloud sono il punto di integrazione.
Validazione nel browser — adatta a
- Progetti governativi e della pubblica amministrazione
- BIM per difesa, infrastrutture e aeroporti
- Modelli di ospedali e strutture sanitarie
- Impianti industriali e ingegneria di processo
- Modelli con policy GDPR o di restrizione dei dati
- Validazione in cantiere e offline
- Controllo preliminare prima dell'invio formale in cloud
- Coordinatori singoli e piccoli team
Validazione cloud — adatta a
- Pipeline di validazione CI/CD automatizzate
- Audit di qualità batch sull'intero portafoglio
- Dashboard centralizzate della qualità BIM
- Gateway del CDE e gate di consegna automatizzati
- Progetti commerciali non sensibili su larga scala
- Automazione dei workflow multi-team a livello enterprise
- Integrazione basata su API con altri sistemi
- File molto grandi oltre la RAM del dispositivo locale
Cinque idee sbagliate sulla validazione IFC nel browser
Idea sbagliata 1: "Le app nel browser sono più lente del cloud"
Era vero nel 2015. Non lo è più oggi. Il codice WebAssembly gira al 60–90% della velocità nativa del C++ all'interno di un browser moderno. Il motore di parsing IFC (web-ifc) è compilato da C++ — la stessa categoria di prestazioni delle librerie che alimentano Solibri, gli importatori IFC di Autodesk e IfcOpenShell. Combinata con una latenza di upload pari a zero, la validazione nel browser è spesso più veloce del cloud per le dimensioni tipiche dei modelli, in particolare su connessioni con upload inferiore a 50 Mbps.
L'idea sbagliata persiste perché si confronta il JavaScript del browser (lento e con garbage collection) con le applicazioni native compilate (veloci). I moderni strumenti BIM nel browser non eseguono l'elaborazione pesante in JavaScript — eseguono WASM compilato a velocità quasi nativa, con JavaScript che si limita a orchestrare il workflow. La distinzione tra JS e WASM è significativa quanto la differenza tra Python e C++.
Idea sbagliata 2: "Per validare un file IFC bisogna caricarlo"
È falso. Quando apri un file IFC in un validatore nel browser, il browser crea un oggetto File nella memoria locale — accessibile a WASM e JavaScript in esecuzione in quel contesto del browser, ma non trasmesso ad alcun endpoint di rete a meno che il codice non richiami esplicitamente un'API fetch o XHR. Puoi verificarlo tu stesso: apri gli strumenti di sviluppo del browser (F12 → scheda Rete) e conferma che non avvenga alcun upload quando un modello viene aperto e validato.
Idea sbagliata 3: "I file IFC di grandi dimensioni non possono girare in un browser"
I browser moderni possono allocare diversi gigabyte di RAM su un tipico hardware da workstation. Un file IFC da 250 MB in memoria occupa 250 MB — ben al di sotto di quanto un processo del browser può allocare su una macchina con 16 GB. I Web Worker estendono questo limite con l'accesso alla memoria fuori dal thread principale. Per i file oltre i 500 MB, il caricamento spaziale a blocchi rende praticabile l'elaborazione nel browser anche in condizioni di memoria più ristrette. OPFS garantisce che un modello di grandi dimensioni analizzato una volta non debba mai essere rianalizzato nelle sessioni successive.
Idea sbagliata 4: "Il cloud è sempre più sicuro"
La sicurezza è multidimensionale, non un singolo attributo. I servizi cloud in genere cifrano i dati in transito (TLS 1.3) e a riposo (AES-256), il che risolve l'intercettazione passiva. Ma introducono superfici di attacco che l'elaborazione nel browser elimina del tutto: compromissione lato server, storage bucket configurati male, accesso interno da parte dei dipendenti del provider cloud, attacchi alla supply chain dell'infrastruttura del provider cloud e violazioni della residenza dei dati se il server si trova al di fuori delle giurisdizioni contrattualmente richieste.
Un file che non lascia mai il dispositivo ha esposizione zero a qualsiasi minaccia basata sulla rete. La domanda sulla sicurezza non è 'quale architettura è più sicura in termini assoluti?' ma 'quali modelli di minaccia sono più rilevanti per questo progetto?' Per il modello di una struttura del Ministero della Difesa, l'elaborazione nel browser elimina del tutto il vettore di minaccia legato all'upload. Per un progetto commerciale non sensibile in cui conta il logging centralizzato, i controlli cloud possono essere il compromesso giusto.
Idea sbagliata 5: "La validazione nel browser non è enterprise-grade"
Il software enterprise-grade si definisce per affidabilità, profondità delle funzionalità e supportabilità istituzionale — non per architettura di distribuzione. Figma, AutoCAD Web, Google Earth e Microsoft Office per il Web sono applicazioni enterprise-grade che girano nel browser usando WebAssembly e le moderne API web. Lo stesso runtime WASM, gli stessi Web Worker e la stessa infrastruttura WebGL che alimentano queste applicazioni alimentano anche la validazione IFC nel browser. 'Basato su browser' è una decisione architetturale su dove avviene l'elaborazione — non un tetto di qualità.
Risoluzione dei problemi di validazione nel browser
Il modello si carica ma la validazione sembra lenta
La validazione gira in un Web Worker separato e non blocca l'interfaccia — il modello 3D dovrebbe restare interattivo mentre la validazione procede in background. Se il processo di caricamento complessivo sembra lento, verifica se il modello si sta caricando dalla cache OPFS (veloce) oppure viene analizzato da zero (più lento per i file grandi). Al primo caricamento, un file da 200 MB richiede 20–40 secondi per essere analizzato anche in locale. I caricamenti successivi dalla cache richiedono 2–5 secondi.
Memoria esaurita su file molto grandi
I file oltre i 400–500 MB possono esaurire la memoria del browser su macchine con 8–16 GB di RAM. Sintomi: la scheda del browser va in crash o diventa non responsiva. Soluzioni: chiudi le altre schede del browser per liberare memoria, usa una macchina con 16+ GB di RAM, oppure suddividi un modello federato in file specifici per disciplina prima del caricamento. Per i file costantemente oltre i 500 MB, la validazione cloud può essere l'architettura più appropriata — l'hardware server ha in genere più margine di RAM.
La cache OPFS cresce nel tempo
OPFS memorizza i frammenti di geometria analizzata per ogni modello caricato. Per un team di progetto che carica molti modelli nel corso di settimane, la cache può crescere fino a diversi gigabyte. Il Cache Manager del validatore mostra tutti i file memorizzati in cache con le rispettive dimensioni e consente l'eliminazione selettiva. Le impostazioni di storage del browser permettono anche di cancellare tutto lo storage dell'origine. La cache è memorizzata sul dispositivo locale e non è accessibile ad alcun server remoto.
I risultati della validazione differiscono tra browser e cloud
Se i risultati differiscono, la causa più comune è l'applicazione di set di regole diversi. La validazione nel browser (44 regole di qualità) e la validazione dello schema in cloud (conformità ISO 10303-21) verificano cose diverse — non le stesse regole in luoghi diversi. Consulta la guida sui livelli di validazione per la distinzione tra il controllo dello schema di Livello 1, il controllo di qualità di Livello 2 e IDS di Livello 3. Un risultato IDS dovrebbe essere identico tra due motori conformi alla specifica che eseguono lo stesso file .ids sullo stesso modello.
Dove si colloca IFC Viewer Online in questa architettura
IFC Viewer Online è un'implementazione nel browser dell'Architettura B. Il parser IFC (web-ifc compilato in WASM), il motore di validazione a 44 regole, il calcolo dell'Health Score, il motore di controllo IDS 1.0, il pannello BCF e il renderer 3D (Three.js via WebGL) girano tutti nel browser. Non viene caricato nulla. L'architettura lo impone a livello di implementazione: non esiste un endpoint lato server a cui inviare i dati del modello.
Parsing WASM in un Web Worker
web-ifc (C++ → WASM) gira in un thread worker dedicato. L'interfaccia resta reattiva durante il caricamento di modelli di grandi dimensioni. Un file da 50 MB viene analizzato in meno di 10 secondi. Un file da 200 MB in 20–40 secondi. Primo risultato: locale. Sempre.
Cache OPFS per i caricamenti ripetuti
I frammenti di geometria analizzata persistono in OPFS dopo la prima sessione. I caricamenti ripetuti sono ~10 volte più veloci: niente ri-parsing, nessuna dipendenza dalla rete. La cache è privata per l'origine del browser e inaccessibile ai server remoti.
44 regole di qualità + IDS 1.0
44 regole di qualità del modello (integrità strutturale, ISO 19650, Pset, classificazione, LOD, MEP) più un motore buildingSMART IDS 1.0 testato su tutti i 100 testcase ufficiali bSI — tutto lato client.
Modifica non distruttiva delle proprietà
I nomi degli elementi, i valori dei set di proprietà e i GlobalId possono essere modificati sui file IFC ricevuti senza dover tornare al software di authoring — e senza caricarli su alcun server.
Consigli degli esperti: scegliere l'architettura giusta
La scelta tra validazione nel browser e in cloud è una decisione di governance a livello di progetto, non una preferenza di strumento. Ecco la logica decisionale per gli scenari più comuni:
- Progetti governativi, per la difesa, aeroportuali, ferroviari, ospedalieri e industriali: la validazione nel browser dovrebbe essere l'ipotesi predefinita. Verifica se la policy di gestione dei dati della tua organizzazione consente il caricamento del modello prima di considerare il cloud. Se la policy non lo affronta, presumi che l'upload sia vietato e chiedi chiarimenti al responsabile della protezione dei dati (DPO).
- Progetti commerciali senza classificazione dei dati: entrambe le architetture sono praticabili. Usa il cloud per tracciabilità centralizzata e integrazione CI/CD. Usa il browser per velocità, preferenza per la privacy e capacità offline.
- Controlli di qualità quotidiani pre-consegna da parte di singoli coordinatori: la validazione nel browser è più veloce, più semplice, non richiede account ed elimina l'attesa dell'upload. Eseguila in locale prima di qualsiasi invio formale al CDE.
- Audit di portafoglio o valutazioni di conformità del CDE su molti modelli: l'elaborazione batch in cloud è lo strumento giusto. Far passare 200 modelli attraverso un'API cloud e ottenere un report di qualità consolidato è impraticabile in un browser.
- Gate di consegna automatizzato all'interno di un CDE: la validazione cloud con integrazione API è l'unica architettura praticabile. Non è disponibile alcun contesto browser in un workflow automatizzato lato server.
- Workflow ibrido: usa la validazione nel browser come gate di qualità quotidiano (veloce, privato, senza account richiesto), e riserva il cloud per l'invio formale al CDE, dove tracciabilità, integrazione API o automazione batch aggiungono valore reale. Queste architetture sono complementari.
Domande frequenti
La validazione IFC nel browser è davvero privata?
Sì, se implementata correttamente. WebAssembly viene eseguito in un contesto sandbox del browser. L'oggetto File che contiene i dati IFC viene creato nella memoria locale del browser. Perché quei dati raggiungano un server, il codice deve richiamare esplicitamente un'API di rete. Un validatore nel browser implementato correttamente non effettua tali chiamate per il file IFC. Verificalo aprendo gli strumenti di sviluppo del browser (F12 → scheda Rete) e controllando che non avvenga alcun upload quando apri e validi un modello.
La validazione nel browser può funzionare offline?
Sì, con un'unica avvertenza. L'applicazione stessa deve essere caricata almeno una volta online: il binario WASM e i bundle JavaScript vengono scaricati alla prima visita. Da quel momento, un'applicazione web progressiva può funzionare completamente offline. I modelli memorizzati in cache OPFS si caricano senza alcun accesso alla rete. Per le visite in cantiere dove la connettività non è affidabile, caricare l'applicazione e pre-memorizzare in cache il modello di progetto la sera prima garantisce la disponibilità offline il giorno seguente.
Qual è il limite pratico di dimensione del file per la validazione nel browser?
Su hardware con 16 GB di RAM (una tipica workstation moderna o un laptop di fascia alta), i file fino a 400–500 MB vengono analizzati in modo affidabile. Su macchine con 8 GB, il limite pratico è di circa 200–250 MB, oltre il quale la pressione sulla memoria causa instabilità. La cache OPFS elimina il costo della rielaborazione ripetuta — quindi il primo parsing è l'unico momento in cui si paga per intero l'overhead di elaborazione. Per i file costantemente sopra i 500 MB, la validazione cloud può offrire un margine maggiore.
WebAssembly introduce rischi di sicurezza?
WASM viene eseguito nello stesso ambiente sandbox di JavaScript: non può accedere al filesystem, al sistema operativo o alla rete senza passare per le API del browser, soggette alle stesse policy di sicurezza di qualsiasi contenuto web. La domanda di sicurezza rilevante non riguarda il runtime WASM in sé, ma quali chiamate di rete effettui l'applicazione — e un validatore nel browser implementato correttamente non ne effettua nessuna per il file IFC.
Posso usare entrambe le architetture nello stesso workflow di progetto?
Sì — spesso è la soluzione più pratica. I coordinatori eseguono la validazione nel browser in locale come controllo preliminare prima di qualsiasi invio formale. Il gateway del CDE utilizza la validazione cloud con un'API per la tracciabilità e l'accettazione automatizzata. Il controllo nel browser è rapido e privato; quello cloud fornisce il registro ufficiale e il reporting a livello organizzativo. Le due architetture rispondono a esigenze diverse e si completano a vicenda.
Riepilogo
Dove va a finire un file IFC durante la validazione non è un dettaglio tecnico. È una decisione di data governance che determina la conformità normativa per una larga parte dei progetti AEC.
IFC Viewer Blog
Progetti sensibili: prima il browser
I progetti governativi, per la difesa, sanitari e infrastrutturali dovrebbero adottare come impostazione predefinita la validazione nel browser. È spesso l'unica opzione conforme — non solo quella più comoda. I dati non lasciano mai il dispositivo.
Automazione e batch: il cloud
Le pipeline CI/CD, gli audit di portafoglio e il reporting centralizzato richiedono un'architettura cloud. Una sessione browser non può partecipare a workflow automatizzati headless né aggregare i risultati tra i team.
Validazione quotidiana: il browser vince in velocità
Tempo di upload pari a zero, caricamenti ripetuti accelerati da OPFS e nessun account richiesto. Per i controlli pre-consegna che definiscono il workflow quotidiano di un coordinatore, l'elaborazione nel browser è più veloce del cloud a tutte le dimensioni tipiche dei modelli.
Per capire cosa verificano esattamente le 44 regole di qualità — e come si collegano alla validazione dello schema e a IDS — consulta la guida completa al model checker IFC. Per l'Health Score che riassume la qualità in un unico numero, consulta la guida all'Health Score IFC. Se devi correggere valori di proprietà o GUID su un file IFC ricevuto senza caricarlo da nessuna parte, l'editor IFC online gratuito applica la stessa architettura browser-first alla modifica non distruttiva delle proprietà.
Validazione IFC nel browser o nel cloud: la decisione architetturale che i team BIM sbagliano