Torna al blog BIM e IFC
Validazione · 2026-06-28 · 20 min
IFC Model Checker: la guida completa a validazione IFC, qualità del modello e IDS
Guida al model checker IFC: schema, qualità del modello (44 regole + Health Score) e IDS sono tre livelli indipendenti. Confonderli causa consegne respinte. Il quadro completo per i BIM coordinator.
IFC Model Checker: la guida completa a validazione IFC, qualità del modello e IDS — IFC Viewer Online article cover
- 3 — livelli di validazione indipendenti
- 44 — regole di qualità del modello
- 6 — facet IDS (buildingSMART 1.0)
- 0 — byte caricati — solo browser
Ogni conversazione sulla consegna IFC finisce prima o poi contro lo stesso muro. L'ingegnere strutturista dice che il file ha superato il validatore. Il BIM coordinator vede mancare metà dei set di proprietà e chiede quale validatore sia stato usato. L'EIR del cliente specifica requisiti IDS che nessuno ha verificato. Il CDE rifiuta il caricamento. Tre settimane dopo, nessuno sa più cosa significhi davvero «valido».
La confusione è comprensibile — la parola «validazione» copre tre operazioni completamente diverse che condividono lo stesso nome. Districarle è una delle cose più decisive che un BIM coordinator possa fare per un progetto.
Tre problemi di validazione completamente diversi
Pensa a una pratica edilizia. Il funzionario del controllo edilizio verifica in modo indipendente tre cose: se gli elaborati sono leggibili e completi (integrità del file), se il progetto rispetta le normative edilizie (qualità e conformità) e se soddisfa il capitolato specifico del cliente (requisiti di progetto). Un disegno leggibile può ignorare completamente le norme antincendio. Un progetto conforme alle norme antincendio può non rispettare affatto le specifiche acustiche del cliente. Sono domande separate, con risposte separate.
Livello 1 — Integrità IFC
Il file è un IFC valido secondo ISO 10303-21 e ISO 16739-1? I GlobalId sono univoci e conformi al formato? La gerarchia spaziale è coerente? Verifica binaria a livello di schema.
Livello 2 — Qualità del modello
I dati sono davvero utili per il coordinamento? I set di proprietà sono popolati? Gli elementi seguono le convenzioni di denominazione? Le classificazioni sono presenti? È questo il livello che governa le consegne reali — non la conformità allo schema.
Livello 3 — Validazione IDS
Il modello soddisfa i requisiti informativi contrattuali di questo progetto? I requisiti EIR e AIR codificati come specifiche IDS leggibili da macchina, verificate facet per facet su ogni elemento.
Questi tre livelli sono completamente indipendenti. Un file può essere valido a Livello 1 (schema) ed essere comunque inutile per il coordinamento perché non è stato esportato nessun set di proprietà. Un controllo IDS può superare tutti i requisiti dichiarati mentre il modello ha 400 GUID duplicati. Un Health Score di 91 non dice nulla sul fatto che i requisiti di resistenza al fuoco del cliente siano codificati e soddisfatti. Ogni livello risponde a una domanda diversa — servono tutti e tre prima di una consegna formale.
Livello 1: integrità del file IFC — è un IFC valido?
Il Livello 1 è la verifica dello schema. Risponde a una domanda binaria: questo file rispetta lo schema IFC (ISO 16739-1) e il formato fisico del file (ISO 10303-21 STEP)? La maggior parte dei parser IFC accetta silenziosamente file che falliscono i controlli di Livello 1 — sono permissivi per progettazione, perché un rifiuto rigido romperebbe troppi workflow. Questa permissività nasconde il danno finché non riemerge più a valle.
Cosa copre la verifica di integrità di Livello 1
- Unicità del GlobalId: ogni entità IfcRoot deve avere un GlobalId univoco di 22 caratteri nell'alfabeto base-64 dell'IFC. I GlobalId duplicati sono una violazione dello schema che i parser accettano, ma che corrompe silenziosamente i workflow BCF, il versionamento sul CDE e i registri asset FM.
- Conformità del formato del GlobalId: il primo carattere di un GlobalId IFC valido codifica solo i valori 0-3 (due bit significativi di uno UUID a 128 bit). Gli script che troncano ingenuamente gli UUID producono caratteri iniziali fuori intervallo — non validi secondo lo standard, tollerati dalla maggior parte dei parser, respinti dai validatori rigorosi.
- Completezza della gerarchia spaziale: lo schema IFC impone IfcProject → IfcSite → IfcBuilding → IfcBuildingStorey. I nodi mancanti (un Building direttamente sotto Project, elementi fisici collocati in IfcSite) sono violazioni dello schema con conseguenze reali a valle.
- Integrità della catena IfcRelAggregates: le entità di relazione che costruiscono l'albero spaziale devono fare riferimento a entità esistenti. I riferimenti pendenti — quando una relazione punta a un'entità eliminata o mancante — rompono la navigazione dell'albero in ogni strumento a valle.
- IfcRelContainedInSpatialStructure: gli elementi fisici devono essere contenuti in un elemento spaziale (tipicamente IfcBuildingStorey). Gli elementi privi di relazione di contenimento sono orfani — invisibili nella navigazione spaziale della maggior parte degli strumenti.
- Esattamente un IfcProject: ogni file IFC valido deve contenere esattamente un IfcProject come radice della gerarchia. I sotto-modelli che lo omettono vengono letti senza errori, ma non hanno un ancoraggio spaziale.
- Campi di intestazione FILE_NAME e FILE_DESCRIPTION: l'intestazione del file STEP contiene metadati di tracciabilità. La ISO 19650-2 richiede che siano popolati — la maggior parte degli strumenti li lascia come stringhe vuote.
- Validità della geometria: mesh non manifold, facce con area nulla, solidi con orientamento delle normali invertito, boundary representation autointersecanti che non producono solidi validi negli strumenti riceventi.
Cosa il Livello 1 NON verifica
- Se i set di proprietà sono popolati o corretti — un modello valido a livello di schema con zero Pset supera il Livello 1.
- Se i nomi degli elementi seguono una qualche convenzione di denominazione di progetto.
- Se i codici di classificazione sono presenti, corretti o coerenti.
- Se i requisiti di quantità per LOD (IfcElementQuantity a LOD 300+) sono soddisfatti.
- Se il modello soddisfa un qualsiasi requisito informativo specifico di progetto o contrattuale.
Il buildingSMART Validation Service per il Livello 1
Il buildingSMART IFC Validation Service (validate.buildingsmart.org) è il riferimento autorevole per la conformità allo schema di Livello 1 — utilizza lo stesso motore impiegato per la certificazione del software IFC. Usalo quando: devi certificare l'output IFC di un exporter personalizzato, stai risolvendo un problema con un file che i parser gestiscono in modo incoerente, oppure una clausola contrattuale richiede esplicitamente un certificato di schema buildingSMART.
Cosa non fa: verificare la qualità dei dati, validare le convenzioni di denominazione, controllare la completezza dei set di proprietà, verificare i campi di metadati ISO 19650, o valutare se il modello soddisfa un qualsiasi requisito di progetto. È uno strumento di schema, non un gate di consegna di progetto.
Ispeziona un IFC reale e complesso — tutti e tre i livelli di validazione
Un edificio per uffici multipiano esportato da Revit. Apri la scheda Validation per vedere il report completo delle 44 regole di qualità e l'Health Score. Poi prova a caricare una specifica IDS per vedere il controllo di Livello 3 sullo stesso modello.
IFC4 · 14 MB
Apri il visualizzatore IFC interattivo
Livello 2: controllo qualità del modello — il livello che governa davvero le consegne
Il controllo qualità del modello è il livello a cui la maggior parte dei BIM coordinator si riferisce quando parla di «validazione IFC», anche se raramente lo chiama così. Risponde a domande pratiche: i dati ci sono? Sono corretti? Sono coerenti? Qualcuno a valle può davvero usare questo modello per il coordinamento, la stima dei costi o l'FM?
A differenza del Livello 1, il controllo qualità non è binario. Un modello non semplicemente supera o fallisce — ha un profilo di qualità su decine di dimensioni. L'Health Score (0-100) aggrega queste dimensioni in un singolo numero che può essere scritto nel BEP, monitorato tra le revisioni e allegato alle trasmittal come prova della qualità della consegna.
Cosa copre il controllo qualità a 44 regole
Regole strutturali principali (18)
GUID duplicati, elementi orfani, contenimento errato, aggregati rotti, IfcProject mancante, nomi degli elementi vuoti, posizionamento del piano non valido. Le regole che nella pratica causano più rifiuti sul CDE.
Struttura spaziale e intestazione file (11)
Campi di metadati ISO 19650 su IfcProject, compilazione di autore e organizzazione in FILE_NAME, posizionamento del sito rispetto alle coordinate condivise, associazione elemento-piano, completezza dei piani dell'edificio.
LOD, classificazione, MEP (9)
Presenza di IfcElementQuantity a LOD 300+, IfcRelAssociatesClassification sugli elementi strutturali e architettonici, connettività dei sistemi MEP, uso eccessivo di proxy (IfcBuildingElementProxy come % del modello).
Geometria e integrità dei piani (6)
Validità del bounding box degli elementi, ordinamento delle quote dei piani, elementi sotto il piano di terra, assenza del solaio dal piano, scostamento dell'origine delle coordinate dal WCS, clash detection (regola opzionale, disattivata di default).
L'Health Score: la qualità del modello in un singolo numero
L'Health Score usa una ponderazione logaritmica delle penalità. Gli errori di schema pesano 3 volte più dei warning; i warning pesano 3 volte più dei controlli informativi. La millesima occorrenza dello stesso problema sottrae molti meno punti della decima — questo evita che modelli grandi e densi appaiano arbitrariamente peggiori di modelli piccoli e radi a parità di densità del problema sottostante. Un modello con 800 warning di denominazione può ottenere 83 punti; un modello con 12 riferimenti spaziali rotti ne ottiene 41. È la gravità a determinare il punteggio, non il volume.
- 31/100 — Critico — errori strutturali, non consegnare
- 58/100 — Scarso — richiede un intervento correttivo significativo
- 74/100 — Sufficiente — accettabile solo per revisione interna
- 87/100 — Buono — pronto per la consegna su CDE
- 96/100 — Eccellente — qualità da milestone ISO 19650
Cosa il controllo qualità del modello NON fa
- Verificare i requisiti informativi specifici di progetto — è compito del Livello 3 (IDS). Le regole di qualità sono controlli generici di buona pratica, non il tuo EIR.
- Correggere il modello — il controllo qualità produce un report. La correzione avviene nel software di authoring o, per le proprietà e i GUID, in un editor di proprietà IFC.
- Fornire il certificato di conformità allo schema richiesto dai programmi di certificazione buildingSMART — è compito del Livello 1 tramite il buildingSMART Validation Service.
- Dirti se il modello è geometricamente corretto — alcuni controlli di integrità geometrica sono inclusi, ma uno strumento di model checking non è un tool di clash detection né un software di authoring BIM.
Livello 3: validazione IDS — i requisiti di scambio come codice leggibile da macchina
IDS (Information Delivery Specification) è uno standard buildingSMART per codificare i requisiti informativi specifici di progetto in un formato XML leggibile da macchina. È l'anello mancante tra un EIR — che è un documento Word — e un motore di validazione in grado di verificare sistematicamente un modello rispetto ad esso. L'IDS 1.0 è diventato uno standard ufficiale buildingSMART nel 2023.
Cos'è davvero il buildingSMART IDS
Un file IDS è un documento XML che contiene una o più specifiche. Ogni specifica ha una sezione di applicabilità (a quali elementi si applica?) e una sezione di requisiti (cosa devono avere quegli elementi?). Il motore verifica ogni elemento del modello che corrisponde all'applicabilità, controlla se soddisfa tutti i requisiti e restituisce esito positivo o negativo per elemento e per specifica. Il risultato è una traccia di audit generata automaticamente sulla conformità contrattuale.
La suite di test di riferimento buildingSMART contiene 100 testcase ufficiali che definiscono il comportamento atteso di qualsiasi motore IDS conforme — sono la specifica nella sua forma eseguibile. Un motore IDS che supera tutti i 100 testcase ha dimostrato di interpretare le specifiche .ids in modo coerente con lo standard.
I sei facet dell'IDS
- Entity: limita l'applicabilità o i requisiti in base al tipo di entità IFC (IFCWALL, IFCDOOR, IFCBEAM) e, facoltativamente, al predefined type. È il filtro da cui parte la maggior parte delle specifiche.
- Attribute: verifica i valori degli attributi IFC che risiedono direttamente sull'entità — Name, Description, ObjectType, Tag, PredefinedType. Gli attributi sono distinti dai set di proprietà e vengono verificati in modo diverso.
- Property: verifica una proprietà specifica all'interno di un set di proprietà specifico (Pset_WallCommon.FireRating, Pset_DoorCommon.IsExternal). È il facet più usato. Supporta vincoli sul tipo di dato e pattern matching sui valori.
- Classification: verifica che gli elementi portino un riferimento di classificazione tramite IfcRelAssociatesClassification — Uniclass 2015, OmniClass, NBS o uno schema personalizzato. Può vincolare il nome del sistema di classificazione e il pattern del codice.
- Material: verifica che agli elementi sia assegnato un materiale tramite IfcMaterial, IfcMaterialLayerSet o IfcMaterialConstituentSet. Facoltativamente vincola il nome del materiale — utile per i requisiti di resistenza al fuoco o sostenibilità.
- PartOf: verifica che gli elementi partecipino a una relazione spaziale o logica richiesta — contenuti in un piano, aggregati in un sistema dell'edificio, ospitati in un edificio specifico. Il facet che impone la conformità alla gerarchia spaziale per tipi di elementi specifici.
<?xml version="1.0" encoding="UTF-8"?>
<ids:ids xmlns:ids="http://standards.buildingsmart.org/IDS"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://standards.buildingsmart.org/IDS ids_09.xsd">
<ids:info>
<ids:title>Stage 3 Architecture — EIR Data Requirements</ids:title>
<ids:description>Fire safety and classification requirements.</ids:description>
<ids:ifcVersion>IFC4</ids:ifcVersion>
</ids:info>
<ids:specifications>
<!-- All walls must carry a fire rating property -->
<ids:specification name="Wall FireRating required" minOccurs="1">
<ids:applicability>
<ids:entity>
<ids:name><ids:simpleValue>IFCWALL</ids:simpleValue></ids:name>
</ids:entity>
</ids:applicability>
<ids:requirements>
<ids:property dataType="IFCLABEL">
<ids:propertySet><ids:simpleValue>Pset_WallCommon</ids:simpleValue></ids:propertySet>
<ids:baseName><ids:simpleValue>FireRating</ids:simpleValue></ids:baseName>
</ids:property>
</ids:requirements>
</ids:specification>
<!-- Structural walls must carry a Uniclass 2015 classification -->
<ids:specification name="Structural wall classification" minOccurs="0">
<ids:applicability>
<ids:entity>
<ids:name><ids:simpleValue>IFCWALL</ids:simpleValue></ids:name>
<ids:predefinedType><ids:simpleValue>SOLIDWALL</ids:simpleValue></ids:predefinedType>
</ids:entity>
</ids:applicability>
<ids:requirements>
<ids:classification>
<ids:system><ids:simpleValue>Uniclass 2015</ids:simpleValue></ids:system>
</ids:classification>
</ids:requirements>
</ids:specification>
</ids:specifications>
</ids:ids>
EIR → IDS: il passaggio di traduzione che la maggior parte dei team salta
Un EIR specifica quali informazioni servono al cliente. Un IDS codifica quei requisiti in modo che una macchina possa verificarli. La traduzione tra i due è il passaggio che quasi nessuno compie — perché richiede qualcuno che conosca abbastanza bene sia i requisiti informativi sia lo schema XML dell'IDS da scrivere una specifica che verifichi esattamente ciò che l'EIR richiede, né più né meno.
La conseguenza: i team o saltano del tutto l'IDS e si affidano a una revisione manuale informale al momento della consegna, oppure usano un file IDS generico che non riflette il loro EIR reale. Entrambi gli approcci producono una falsa sicurezza. Un controllo IDS superato rispetto a una specifica generica non dice nulla sul fatto che i requisiti specifici del tuo cliente siano soddisfatti.
IDS basato su profili: un punto di partenza pratico
Non tutti i team scrivono l'IDS da zero. Un approccio pratico è mantenere una libreria di profili IDS riutilizzabili: uno per l'architettura di Stage 3, uno per l'MEP di Stage 4, uno per la consegna strutturale. Ogni profilo copre i requisiti più comuni per quella fase e disciplina, e viene esteso per singolo progetto con aggiunte specifiche del cliente. I profili IDS possono essere caricati direttamente nel motore di validazione e composti tra loro — puoi eseguire più file .ids sullo stesso modello e aggregare i risultati.
Come i tre livelli lavorano insieme — la pipeline di validazione
I tre livelli formano un gate di qualità che un modello attraversa in sequenza. Ogni livello ha una cadenza diversa: il Livello 1 viene eseguito a ogni esportazione (un controllo di coerenza), il Livello 2 prima di ogni caricamento sul CDE (il gate di qualità), il Livello 3 prima delle milestone formali di consegna (il controllo contrattuale). Eseguirli fuori ordine è tempo sprecato — non ha senso eseguire l'IDS su un file con una gerarchia spaziale rotta.
┌──────────────────────────────────────────────────────┐
│ EXPORT IFC from authoring tool │
│ (Revit, ArchiCAD, Tekla, Allplan, Vectorworks…) │
└───────────────────────┬──────────────────────────────┘
│
▼
┌──────────────────────────────────────────────────────┐
│ LEVEL 1 — IFC Integrity │
│ • GlobalId uniqueness & format (leading char 0–3) │
│ • Spatial hierarchy: Project→Site→Building→Storey │
│ • IfcRelAggregates chain integrity │
│ • IfcRelContainedInSpatialStructure (no orphans) │
│ • Exactly one IfcProject │
│ • FILE_NAME header traceability fields │
└─────────┬────────────────────────────────────────────┘
Fail ◄────┤ Fix in authoring tool (or IFC property editor)
│ Pass
▼
┌──────────────────────────────────────────────────────┐
│ LEVEL 2 — Model Quality (44 rules) │
│ • Naming conventions / empty element names │
│ • Property set completeness (Pset_WallCommon etc.) │
│ • ISO 19650 metadata (IfcProject.LongName etc.) │
│ • Classification presence and consistency │
│ • LOD quantity sets, proxy audit, MEP connectivity │
│ → Health Score 0–100 │
└─────────┬────────────────────────────────────────────┘
Score<80 ◄┤ Fix properties / names in IFC editor or authoring tool
│ Score ≥ 80
▼
┌──────────────────────────────────────────────────────┐
│ LEVEL 3 — IDS Validation │
│ • Project-specific EIR / AIR requirements │
│ • .ids specification(s) for this milestone │
│ • Six facets: entity, attribute, property, │
│ classification, material, partOf │
└─────────┬────────────────────────────────────────────┘
Fail ◄────┤ Fix per IDS issue report → export BCF → remediate
│ All requirements met
▼
┌──────────────────────────────────────────────────────┐
│ DELIVER TO CDE │
│ Attach: Health Score report + IDS pass certificate │
└──────────────────────────────────────────────────────┘
La tabella di confronto: Livello 1 vs Livello 2 vs Livello 3
| Dimensione | L1: integrità IFC | L2: qualità del modello | L3: validazione IDS |
|---|
| Domanda a cui risponde | Il file rispetta uno schema IFC valido? | I dati sono utili per il coordinamento? | Soddisfa i requisiti informativi di progetto? |
| Standard | ISO 10303-21 (STEP), ISO 16739-1 (IFC) | Buone pratiche BIM, norme ISO 19650 | buildingSMART IDS 1.0 (schema XML) |
| Definito da | buildingSMART (schema fisso) | Team BIM / EIR (regole concordate di progetto) | Cliente / committente (per progetto) |
| Output | Pass / Fail + elenco errori di schema | Health Score 0-100 + elenco problemi prioritizzato | Pass / Fail per specifica |
| Può sostituire gli altri? | No | No | No — servono tutti e tre |
| Cadenza | Ogni esportazione IFC | Prima del caricamento sul CDE | Prima della milestone di consegna |
| Supera questo ma fallisce un altro? | Zero Pset, nessun nome → L1 ok, L2 fallito | Resistenza al fuoco mancante (specifica IDS) → L3 fallito | GUID duplicati, gerarchia rotta |
| Strumenti di esempio | bSmart Validator, IFC Viewer Online | IFC Viewer Online, Solibri, IfcOpenShell | IFC Viewer Online (motore IDS), Solibri |
Quando usare il buildingSMART Validation Service — una valutazione onesta
Il buildingSMART IFC Validation Service verifica i file rispetto allo schema ufficiale usando un motore composto da più parti: sintassi del file fisico STEP, regole EXPRESS dello schema IFC, regole di proposizione informale derivate dalla specifica e regole di vincolo normative IFC. È lo strumento di riferimento per la conformità allo schema di Livello 1.
Usalo quando
- Devi certificare l'esportazione IFC di un exporter personalizzato: il checker buildingSMART produce il risultato di riferimento usato per la certificazione del software. Nei contesti di certificazione, nessun altro strumento può sostituirlo.
- Devi diagnosticare un'incoerenza tra parser: quando un file si apre correttamente in uno strumento e genera errori in un altro, il checker buildingSMART stabilisce quale comportamento sia corretto rispetto allo schema. È diagnosticamente prezioso anche se il file è comunque utilizzabile.
- Una clausola contrattuale lo richiede: alcuni capitolati di appalto citano la conformità allo schema buildingSMART come requisito di consegna. In quel caso, è il certificato del servizio ufficiale a soddisfare la clausola.
- Devi validare il file IDS in sé: il validatore di schema IDS di buildingSMART verifica se il tuo file .ids è un documento IDS valido — un'operazione distinta dall'eseguirlo su un modello.
Non usarlo come sostituto di
- Controllo qualità del modello — il servizio non verifica la completezza dei set di proprietà, le convenzioni di denominazione, la classificazione o qualsiasi altra regola di qualità dei dati.
- Validazione specifica di progetto — la conformità allo schema non dice nulla sul fatto che il modello soddisfi l'EIR del cliente.
- Conferma pre-consegna sul CDE — un modello valido a livello di schema ma con Pset vuoti e nomi assenti supererà il checker buildingSMART e fallirà qualsiasi gate di qualità significativo.
Validatore IFC cloud vs validatore IFC basato su browser
La distinzione tra validazione cloud (file caricato su un server remoto) e validazione basata su browser (file elaborato localmente tramite WebAssembly) conta più di quanto la maggior parte dei team si renda conto — soprattutto per progetti governativi, della difesa e commerciali sensibili.
Validazione basata su browser
- Il file IFC non lascia mai il dispositivo
- Conforme al GDPR by design — nessun trasferimento di dati
- Funziona offline: sopralluoghi, reti con restrizioni
- Nessuna quota di caricamento né limite di dimensione del file
- Feedback istantaneo — nessuna latenza di andata e ritorno in rete
- Prestazioni costanti, indipendenti dal carico del server
- Non richiede account, chiave API o abbonamento
- Funziona in ambienti di rete governativi con restrizioni
Validazione cloud
- Il file viene caricato su un server remoto per l'elaborazione
- Richiede un accordo sul trattamento dei dati (DPA) ai fini del GDPR
- Adatto a pipeline di validazione CI/CD automatizzate
- Log di audit centralizzato tra progetti e team
- Integrazione API e webhook per l'automazione delle consegne
- Si scala orizzontalmente per l'elaborazione batch dei modelli
- Può girare in modalità headless senza una sessione browser
- Risultati interrogabili tra le esecuzioni storiche
Quando la validazione cloud ha senso
- Pipeline CI/CD automatizzate: quando la validazione deve attivarsi automaticamente ogni volta che un modello viene committato o caricato — in modo simile a come i team di sviluppo eseguono test automatici a ogni push di codice. Le API cloud con webhook sono l'architettura giusta in questo caso.
- Audit a livello di organizzazione: quando un BIM manager ha bisogno di un registro centrale delle esecuzioni di validazione su più progetti e team. I servizi cloud possono aggregare i dati e mostrarne l'andamento tra le esecuzioni in modi che gli strumenti locali non consentono.
- Elaborazione batch: fare l'audit di una libreria di modelli esistenti — tutti i file IFC consegnati su un CDE negli ultimi due anni — è pratico in modalità batch cloud e poco pratico da fare manualmente in un browser.
- Modelli non sensibili: per i progetti in cui i requisiti di trattamento dei dati non vietano il caricamento sul cloud, i validatori cloud offrono un'integrazione CI/CD che gli strumenti da browser non possono eguagliare.
Quando la scelta migliore è lo strumento da browser
- Progetti governativi e della difesa: i modelli per infrastrutture pubbliche, strutture della difesa e asset riservati portano di norma restrizioni sul trattamento dei dati che vietano il caricamento su servizi di terze parti. La validazione basata su browser è l'unica opzione conforme.
- Progetti residenziali e commerciali sensibili: i modelli BIM contengono spesso informazioni sugli occupanti, indirizzi dei proprietari e metadati sugli asset che rientrano nella definizione di dati personali secondo l'articolo 4 del GDPR. Elaborarli su un server di terze parti senza un DPA valido e una base giuridica non è conforme.
- Uso in cantiere e sul campo: un file IFC da 200 MB su una connessione 4G si carica lentamente e in modo inaffidabile. La validazione da browser lo elabora localmente in pochi secondi, senza dipendere dalla banda di upload.
- Pre-validazione prima del caricamento sul cloud: anche quando un team usa un validatore cloud come gate formale, eseguire prima un controllo da browser individua i problemi più evidenti senza bisogno di caricare il file — riducendo i costi di utilizzo del cloud e la frequenza dei caricamenti.
Sei errori di validazione commessi dai team BIM — e cosa significano davvero
Errore 1: «L'IDS è passato — il modello va bene»
L'IDS valida solo ciò che la specifica .ids dichiara. Se il tuo file richiede FireRating sui muri, ma il tuo EIR richiede anche IsExternal sulle porte, codici Uniclass sugli elementi strutturali e quantity set sui solai — e questi non sono stati scritti nella specifica — il motore riporterà tutti i requisiti come soddisfatti mentre metà del tuo EIR resta non verificata. Un IDS superato è una conferma contrattuale rispetto a una specifica precisa. Non è un certificato di qualità generale.
Errore 2: «Il checker buildingSMART dice che è valido»
La validità dello schema è il pavimento, non il soffitto. Un file in cui ogni elemento ha Name='' e zero set di proprietà è perfettamente valido a livello di schema. Un modello senza IfcElementQuantity, senza classificazione e con ogni elemento fisico collocato direttamente in IfcSite anziché in un piano è perfettamente valido a livello di schema. Superare il checker buildingSMART significa che il file STEP è formattato correttamente — non dice nulla sull'utilità dei dati.
Errore 3: «Riesco ad aprirlo in un viewer, quindi va bene»
I visualizzatori IFC sono permissivi per progettazione — sono costruiti per mostrare la geometria indipendentemente dalla qualità dei dati. Un viewer che rifiutasse di aprire file non validi a livello di schema o poveri di dati sarebbe inutilizzabile. Il rendering corretto della geometria non dice nulla sulla completezza dei set di proprietà, sulle convenzioni di denominazione, sulla stabilità dei GUID, sulla classificazione o su una qualsiasi delle 44 dimensioni di qualità. Visualizzare un file è categoricamente diverso dal validarlo.
Errore 4: verificare solo la geometria, ignorando i dati delle proprietà
Un riflesso comune è aprire l'IFC, ispezionare il modello 3D e, se l'edificio sembra corretto, dichiarare il file completo. La geometria rappresenta circa il 30% di ciò che rende utile un file IFC. Set di proprietà, classificazioni, nomi degli elementi, assegnazioni di tipo e quantity set sono ciò che i sistemi FM, i cost manager e i registri asset del CDE consumano davvero. Un file geometricamente corretto ma con set di proprietà vuoti fallisce la consegna.
Errore 5: validare una sola volta, alla scadenza della consegna
Trattare la validazione come l'ultimo passaggio prima di una submission sul CDE significa correggere i problemi sotto pressione e senza margine. Un modello con 800 problemi di validazione scoperti il giorno prima della scadenza verrà consegnato con problemi noti oppure mancherà la scadenza. La cadenza corretta: Livello 1 dopo ogni esportazione, Livello 2 prima di ogni revisione interna (settimanale come minimo), Livello 3 due settimane prima di ogni milestone formale.
Errore 6: ignorare la stabilità dei GUID tra ri-esportazioni
I GUID duplicati all'interno di un file sono un problema di Livello 1 e sono rilevabili da qualsiasi validatore. Ma l'instabilità dei GUID tra ri-esportazioni — quando lo stesso elemento riceve un GlobalId diverso a ogni esportazione del modello — è invisibile alla validazione su singolo file. Quando i GlobalId si spostano tra le revisioni, ogni commento BCF, riferimento a elementi sul CDE e tag asset FM diventa silenziosamente un riferimento pendente. Serve un confronto tra due revisioni e una verifica delle impostazioni di esportazione, non solo la validazione di un singolo file.
Un workflow di validazione pratico per i BIM coordinator
- Dopo ogni esportazione IFC: esegui un controllo di Livello 1. Richiede meno di 30 secondi in qualsiasi validatore da browser. Correggi i GlobalId duplicati, gli elementi orfani e le rotture della gerarchia spaziale prima che si accumulino tra le revisioni.
- Prima di ogni revisione interna (settimanale o per sprint): esegui un controllo qualità completo di Livello 2. Rivedi l'andamento dell'Health Score. Un punteggio in calo tra le revisioni significa che si stanno introducendo nuovi problemi — individua la fonte prima che diventi una tendenza.
- Alla ricezione di qualsiasi modello disciplinare da terze parti: esegui il Livello 1 e il Livello 2 prima di federare. Un modello ricevuto può portare problemi che erediti nel modello di coordinamento — individuali subito, non tre settimane dopo l'inizio del coordinamento su una federazione già compromessa.
- Due settimane prima di ogni consegna a milestone formale: esegui tutti e tre i livelli. Obiettivo Health Score ≥ 80 prima dell'IDS. Due settimane danno il tempo per correggere senza pressione. Segnala i problemi subito — non consumare il margine.
- Prima di caricare sul CDE: esegui il Livello 2 e il Livello 3. Allega alla trasmittal il certificato dell'Health Score e il report di esito IDS. Questo crea una traccia di audit documentata e dà all'information manager tutto ciò che serve per accettare la consegna.
- Dopo qualsiasi aggiornamento di versione del software di authoring o modifica delle impostazioni di esportazione: ristabilisci la baseline di stabilità dei GUID confrontando due esportazioni consecutive. Un aggiornamento di Revit o una configurazione di esportazione modificata possono cambiare silenziosamente il comportamento di generazione dei GlobalId.
Consigli da esperti
Fai triage per penalità, non per conteggio
Non correggere i problemi in ordine di volume — correggili in ordine di impatto sull'Health Score. Tre campi di metadati IfcProject mancanti possono costare 15 punti. Ottocento warning di denominazione potrebbero costarne solo 8 in totale. Usa la ripartizione per gravità per fare triage in base all'impatto.
Blocca le impostazioni di esportazione in un template
Ogni volta che le impostazioni di esportazione vengono riconfigurate manualmente, c'è il rischio di derivare verso una configurazione diversa. Crea un setup di esportazione IFC nominato nel tuo software di authoring, includilo nel template di progetto e documenta le impostazioni richieste nel BEP. La deriva della configurazione è la causa principale della maggior parte dei problemi di esportazione del tipo «la volta scorsa funzionava».
Traduci l'EIR in IDS all'avvio del progetto
Traduci le clausole EIR più critiche in una specifica IDS entro le prime due settimane di progetto. Anche un file .ids parziale — cinque o sei specifiche — è meglio di una revisione manuale completa dell'EIR al momento della consegna, e individua per tempo le lacune sistematiche nei dati, quando costano poco da correggere.
Valida ogni modello disciplinare prima di federare
I problemi di un modello disciplinare possono mascherare o interagire con quelli di un altro all'interno di una federazione. Valida input puliti, federa il pulito. Eseguire la validazione solo sul modello di coordinamento dopo la federazione rende più difficile attribuire i problemi al soggetto responsabile corretto.
Domande frequenti
Superare il Livello 1 significa poter saltare il Livello 2?
No. Il Livello 1 e il Livello 2 misurano proprietà completamente diverse di un file. Un file valido a livello di schema (Livello 1) può avere zero set di proprietà, nomi degli elementi vuoti, nessuna classificazione e nessun metadato ISO 19650 — e ottenere un punteggio di 20 in un controllo qualità (Livello 2). Servono sempre entrambi. Pensa al Livello 1 come «il file è confezionato correttamente» e al Livello 2 come «il contenuto della confezione è quello richiesto».
L'IDS sostituisce il buildingSMART Validation Service?
No. L'IDS verifica i requisiti informativi specifici di progetto (Livello 3). Il buildingSMART Validation Service verifica la conformità allo schema (Livello 1). Operano a livelli completamente diversi e rispondono a domande diverse. Un modello che supera l'IDS ma fallisce la validazione dello schema sarebbe una contraddizione logica — l'integrità di Livello 1 è un prerequisito perché il controllo di Livello 3 abbia senso.
A quali facet IDS bisogna dare priorità per una consegna BIM standard?
Il facet Property copre il 70-80% dei requisiti EIR reali — la maggior parte dei clienti vuole valori di set di proprietà specifici popolati su tipi di elementi specifici. Il facet Classification copre la maggior parte del resto nei progetti regolati da Uniclass o OmniClass. Il facet Entity compare in quasi ogni specifica come filtro di applicabilità. Material e PartOf rispondono a requisiti contrattuali specifici. Inizia con Entity + Property, aggiungi Classification se il tuo EIR lo richiede, e amplia da lì.
È possibile validare un IFC senza caricarlo da nessuna parte?
Sì. I validatori basati su browser elaborano il file interamente nel tuo browser tramite WebAssembly. I byte dell'IFC non lasciano mai il tuo dispositivo — tutte le 44 regole di qualità, il calcolo dell'Health Score e l'intero motore IDS vengono eseguiti lato client. Per i modelli con restrizioni sul trattamento dei dati — asset governativi, dati residenziali sensibili, infrastrutture della difesa — questa è spesso l'unica opzione conforme.
Quale soglia di Health Score bisogna specificare nel BEP?
≥ 80 è la soglia standard per la consegna su CDE e il coordinamento progettuale. ≥ 90 per le consegne in fase di sviluppo del progetto a LOD 300+ e per le submission formali nelle milestone ISO 19650. ≥ 70 è accettabile per le revisioni interne in fase di concept. Sotto 60, il modello presenta problemi strutturali di qualità e non dovrebbe essere consegnato a nessuna parte esterna in nessuna circostanza.
Un unico strumento può coprire tutti e tre i livelli di validazione?
Alcuni sì. IFC Viewer Online copre il Livello 1 (regole di integrità inclusi i controlli su GUID, gerarchia e intestazione del file), il Livello 2 (controllo qualità a 44 regole con Health Score) e il Livello 3 (motore IDS 1.0 validato su tutti i 100 testcase ufficiali bSI). Solibri copre il Livello 2 e il Livello 3 con un motore di regole più sofisticato, ma senza elaborazione basata su browser. Il buildingSMART Validation Service copre solo il Livello 1. IfcOpenShell può essere scriptato per il Livello 1 e il Livello 2.
Riepilogo
Valido a livello di schema non significa valido per il progetto. Valido per il progetto non significa conforme all'EIR. Servono tutti e tre i livelli di validazione — e confonderli è la causa principale della maggior parte delle consegne formali respinte.
IFC Viewer Blog
Livello 1: esegui a ogni esportazione
Integrità dello schema, unicità e formato dei GlobalId, gerarchia spaziale. Richiede 30 secondi. Individua i guasti strutturali che corrompono silenziosamente BCF, versionamento sul CDE e registri asset FM a valle.
Livello 2: gate di ogni consegna sul CDE
44 regole di qualità, Health Score, convenzioni di denominazione, completezza dei set di proprietà, metadati ISO 19650. Richiedi ≥ 80 nel tuo BEP e EIR. È il livello che rende un modello utile — non solo leggibile.
Livello 3: verifica prima di ogni milestone
Specifiche IDS che codificano il tuo EIR e AIR in forma leggibile da macchina. Traduci le clausole critiche all'avvio del progetto, non la settimana prima della consegna. Un IDS superato è una traccia di audit contrattuale documentata.
Esegui un controllo qualità completo sul tuo modello attuale — meno di 30 secondi in qualsiasi browser, senza caricare nulla. Poi leggi la guida all'Health Score IFC per capire come viene calcolato il punteggio e quale soglia impostare nel tuo BEP. Se devi correggere valori delle proprietà o GUID su un file ricevuto, la guida all'editor IFC online gratuito tratta la modifica non distruttiva delle proprietà senza dover passare dal software di authoring. E per i guasti strutturali più comuni che causano rifiuti al Livello 1, vedi i 7 errori di validazione IFC più comuni.
IFC Model Checker: la guida completa a validazione IFC, qualità del modello e IDS