Torna al blog BIM e IFC
Validazione · 2026-10-01 · 12 min
IDS spiegato: come verificare un modello IFC con una Information Delivery Specification
L'IDS trasforma «il modello deve contenere la resistenza al fuoco» da una frase in un PDF a un file che una macchina può verificare. Cosa testano davvero le sei facet, dove sbagliano la maggior parte dei file IDS e come eseguirne uno sul tuo IFC nel browser.
IDS spiegato: come verificare un modello IFC con una Information Delivery Specification — IFC Viewer Online article cover
Ogni EIR mai scritto contiene una frase come «tutte le porte dovranno riportare la loro resistenza al fuoco». E in ogni progetto quella frase viene verificata allo stesso modo: qualcuno apre il modello, clicca su qualche porta e decide che probabilmente va bene. Il requisito è preciso. La verifica è una sensazione.
L'IDS —la Information Delivery Specification— esiste per colmare questo divario. È un piccolo formato XML, standardizzato da buildingSMART come IDS 1.0, che esprime i requisiti informativi in una forma che una macchina può testare. Scrivi il requisito una volta, consegni il file .ids a ogni fornitore e «probabilmente va bene» diventa «passano 412 porte su 418; ecco le sei che non passano».
In sintesi
- L'IDS verifica informazioni, non geometria: classi, attributi, proprietà, classificazioni, materiali e relazioni.
- Ogni specifica ha due metà: a quali elementi si applica e cosa devono avere quegli elementi. La maggior parte dei file IDS difettosi sbaglia la prima metà.
- Un IDS è un documento contrattuale. Sta accanto al BEP, versionato, e va inviato ai fornitori prima che inizi la modellazione, non dopo il primo rifiuto.
Anatomia di una specifica
Una specifica IDS si legge come una frase: per ogni elemento che rientra nell'applicabilità, richiedi i requisiti.
Un file IDS è un elenco di specifiche. Ognuna si legge come una frase con soggetto e predicato: «per ogni elemento che corrisponde a questo, richiedi quello». Il soggetto è l'applicabilità; il predicato, i requisiti.
<specification name="Doors carry a fire rating" ifcVersion="IFC4">
<applicability minOccurs="1">
<entity><name><simpleValue>IFCDOOR</simpleValue></name></entity>
</applicability>
<requirements>
<property dataType="IFCLABEL">
<propertySet><simpleValue>Pset_DoorCommon</simpleValue></propertySet>
<baseName><simpleValue>FireRating</simpleValue></baseName>
</property>
</requirements>
</specification>
Letta ad alta voce è esattamente la frase dell'EIR: ogni IfcDoor deve avere un FireRating in Pset_DoorCommon, salvato come label. Il minOccurs="1" nell'applicabilità aggiunge una seconda affermazione facile da trascurare: il modello deve contenere almeno una porta. Senza, un modello senza alcuna porta passa, e raramente è ciò che si intendeva.
Le sei facet e cosa verifica davvero ognuna
| Facet | Verifica | Requisito tipico | Trappola comune |
|---|
| Entity | Classe IFC e tipo predefinito | I muri sono IfcWall, non IfcBuildingElementProxy | Dimenticare i sottotipi: IfcWallStandardCase è un IfcWall in IFC2x3 |
| Attribute | Attributi IFC diretti (Name, Description, Tag…) | Ogni spazio ha Name e LongName | Una stringa vuota è presente ma non valida, non assente |
| Property | Una proprietà in un property set, con tipo di dato e valore | Pset_WallCommon.IsExternal è TRUE o FALSE | Valore giusto, tipo di dato sbagliato (un label dove si chiedeva un booleano) |
| Classification | Un riferimento di classificazione e il suo codice | Ogni elemento ha un codice Uniclass Ss | Verificare il codice ma non il sistema a cui appartiene |
| Material | Un nome o una categoria di materiale associati | I pilastri strutturali dichiarano un materiale | Materiali sul tipo, non sull'occorrenza |
| PartOf | Una relazione con un elemento padre | Ogni elemento è contenuto in un piano | Confondere aggregazione e contenimento spaziale |
Ogni facet può comparire nell'applicabilità (per selezionare elementi) o nei requisiti (per esigere qualcosa da essi).Due di queste trappole meritano uno sguardo più lungo, perché spiegano la maggior parte dei falsi errori che si vedono la prima volta che si esegue un IDS.
Tipo contro occorrenza
Le proprietà possono stare sul tipo invece che sull'occorrenza. Uno strumento IDS deve seguire il tipo, o boccia elementi corretti.
Revit, ArchiCAD e Tekla scrivono abitualmente proprietà e materiali sull'oggetto tipo (IfcWallType) anziché su ogni muro. La semantica IDS è chiara: le informazioni ereditate dal tipo valgono per l'occorrenza. Uno strumento che guarda solo l'occorrenza boccerà ogni muro di un modello perfettamente corretto. Se un IDS ti dice che al 100% dei tuoi elementi manca una proprietà che vedi nel pannello proprietà, il motivo è quasi sempre questo, e la colpa è dello strumento, non tua.
Tipi predefiniti USERDEFINED
Quando un tipo predefinito è USERDEFINED, il tipo reale si trova in ObjectType (sulle occorrenze) o in ElementType (sui tipi). Una facet entity che chiede IFCWALL con tipo predefinito PARAPET deve corrispondere a un muro il cui PredefinedType è USERDEFINED e il cui ObjectType è PARAPET. Gli strumenti che confrontano l'enum grezzo li mancano tutti.
Cinque errori che rendono inutile un IDS
- Applicabilità troppo ampia. «Tutti gli elementi devono avere un codice Uniclass» trascina dentro aperture, annotazioni ed elementi spaziali che nessuno classifica. Limita ogni specifica alle classi a cui il requisito si riferisce davvero.
- Valori senza tipo di dato. Un requisito FireRating = «EI 60» non dice nulla su come debba essere salvato; lo stesso testo salvato come descrizione in un altro pset continua a non passare. Di' quello che intendi, tipo di dato compreso.
- Valori esatti dove serviva un pattern. I dati reali contengono «EI60», «EI 60» e «EI-60». Usa un xs:pattern o un'enumerazione e concorda la forma canonica nel BEP.
- Un'unica specifica gigante. Quaranta requisiti in una specifica producono un solo passa/non passa per elemento e un report su cui nessuno può agire. Un requisito per specifica, con un nome in linguaggio semplice, è ciò che rende leggibile il risultato.
- Scrivere l'IDS dopo il modello. Un IDS inviato con il primo rifiuto è un requisito nuovo. Un IDS inviato con l'incarico è un requisito. Solo il secondo è esigibile.
Il lato contrattuale di quest'ultimo punto —quali clausole rendono vincolante un IDS e cosa succede quando una consegna non lo rispetta— è trattato in clausole del BEP che evitano davvero consegne IFC scadenti e in criteri di accettazione IFC.
Eseguire un IDS sul tuo modello, passo per passo
- Apri l'IFC Trascina il modello nel visualizzatore. Viene elaborato nel browser; non si carica nulla.
- Carica il file .ids Apri il pannello IDS e scegli il tuo file, oppure parti da una delle specifiche di esempio incluse se prima vuoi vedere il formato.
- Esegui la verifica Ogni specifica viene valutata con tutte e sei le facet. I modelli grandi mostrano l'avanzamento per fasi e si possono annullare in qualsiasi momento.
- Leggi il risultato per specifica, elemento o classe Raggruppa gli errori nel modo in cui intendi correggerli. Ogni errore riporta il motivo in parole semplici: proprietà mancante, valore errato, tipo di dato errato, classe errata.
- Guardalo in 3D Evidenzia colora nel modello gli elementi che non passano; Isola nasconde tutto il resto. Entrambi sono a un clic, ed è così che un elenco di GlobalId diventa una conversazione con chi modella.
IDS tra revisioni
Un'esecuzione IDS è un'istantanea. Ciò di cui un coordinatore ha davvero bisogno è la tendenza: la revisione 7 ha corretto gli errori sollevati sulla revisione 6? Ne ha introdotti di nuovi? Poiché il risultato è indicizzato per GlobalId, la stessa specifica può essere confrontata tra due versioni di un modello, cosa che funziona solo se i tuoi GlobalId sono stabili tra un'esportazione e l'altra. Se non lo sono, risolvi prima questo: perché i GUID IFC cambiano a ogni esportazione. Il confronto vero e proprio è trattato in come confrontare due versioni di un modello IFC.
Dove si ferma l'IDS
L'IDS non verifica la geometria. Non ti dirà che due canali interferiscono, che una porta è troppo stretta per una sedia a rotelle o che il modello si trova a due chilometri dal suo punto di rilievo. Non verifica nemmeno che un IFC sia strutturalmente sano: un file con GlobalId duplicati o posizionamenti rotti può superare un IDS alla perfezione.
Non è una debolezza; è ambito. Usa l'IDS per i requisiti informativi, un model checker per struttura e geometria, e consegna i due report fianco a fianco. Il flusso completo è in come validare un file IFC.
IDS spiegato: come verificare un modello IFC con una Information Delivery Specification