Capire IDS 1.0 — cos'è lo standard e come si presenta una prima regola

Nella maggior parte dei progetti BIM il capitolato è un documento Word. Da tre a cinquanta pagine in cui si stabilisce quali elementi devono essere consegnati, quali property devono essere compilate, quali classificazioni utilizzare. Scritto per gli umani, controllato a schermo. Funziona finché chi controlla resta concentrato. Ma chiunque abbia controllato quattro consegne IFC di seguito rispetto a un simile documento sa: dal terzo file lo sguardo inizia a vagare.

La domanda non è se il capitolato sia sbagliato. La domanda è come renderlo leggibile dalle macchine. Esattamente per questo, dal 2024, esiste uno standard aperto: l'Information Delivery Specification, in breve IDS. In questo articolo spiego cosa fa IDS, come è strutturato un file IDS e come si presenta una prima regola concreta.

Cosa fa IDS

IDS è un linguaggio XML che permette di scrivere requisiti BIM in modo che un software possa controllarli automaticamente. È standardizzato da buildingSMART International. La versione 1.0 è stata approvata come standard finale il 4 giugno 2024. Lavorarci oggi non è più da pionieri.

Tre termini vengono spesso confusi nel quotidiano BIM. Ecco come distinguerli:

• MVD (Model View Definition) — descrive cosa un software deve esportare in IFC. Dal punto di vista del produttore di software.
• IDM (Information Delivery Manual) — descrive, a livello di processo, chi consegna quale informazione in quale fase. Dal punto di vista del workflow di progetto.
• IDS — è il ponte leggibile dalla macchina tra IDM e IFC. Ciò che è stato concordato testualmente nell'IDM, IDS lo controlla tecnicamente.

In pratica: un committente o un general planner che scrive "tutti i muri portanti devono avere una resistenza al fuoco" può formulare la stessa frase in IDS in modo che ogni consegna sia controllata automaticamente. Nessuno scorre più il modello a mano.

Come è strutturato un file IDS

Nella sostanza, un file IDS è XML. Non bello da leggere, ma stabile da elaborare. È composto da diverse Specifications, e ogni Specification ha due parti:

• Applicability — a quali elementi del modello la regola si applica. Esempio: tutti gli IfcWall con LoadBearing = True.
• Requirements — cosa questi elementi devono soddisfare. Esempio: deve essere presente una property FireRating con un valore tratto da una lista definita.

In versione molto semplificata, in IDS-XML appare così:

<specification name="Muri portanti — resistenza al fuoco">
  <applicability>
    <entity name="IfcWall" />
    <property propertySet="Pset_WallCommon"
              baseName="LoadBearing" value="True" />
  </applicability>
  <requirements>
    <property propertySet="Pset_WallCommon"
              baseName="FireRating">
      <value>
        <enumeration values="REI30,REI60,REI90,REI120" />
      </value>
    </property>
  </requirements>
</specification>

Pset_WallCommon è un property set definito in IFC. LoadBearing e FireRating sono property standard al suo interno. Chi utilizza property proprie o specifiche di progetto indica semplicemente il property set adatto.

Due punti importanti:

• IDS controlla strutture e valori, non geometrie. La domanda "Questo muro ha un FireRating?" si mappa bene. "Questo muro taglia la finestra?" no. Più sotto un approfondimento.
• I file IDS sono versionabili e condivisibili. Una libreria IDS curata cresce con ogni progetto. È un asset che si porta da un progetto al successivo.

Una prima regola — passo per passo

Esempio: "I muri portanti devono avere una resistenza al fuoco." Ecco come diventa una regola IDS finita.

Passo 1 — formulare il requisito con precisione. Il capitolato dice tipicamente "I muri portanti devono essere marcati con una resistenza al fuoco". Per una regola leggibile dalle macchine non basta. Cosa significa "portante" in termini IFC? Quali valori sono ammessi? Dove si trova la property? La frase diventa:

Tutti gli elementi di tipo IfcWall con Pset_WallCommon.LoadBearing = True devono avere una property Pset_WallCommon.FireRating il cui valore appartiene alla lista REI30, REI60, REI90, REI120.

Passo 2 — esprimere la regola come IDS. Lo si fa o a mano in un editor XML (possibile, ma soggetto a errori) oppure tramite un editor di regole che genera l'XML sullo sfondo. Alla fine si ottiene un file .ids che ogni strumento conforme può leggere.

Passo 3 — verificare la regola su un modello IFC. Il file .ids viene caricato insieme al file .ifc. Un validatore percorre tutte le istanze IfcWall, filtra quelle portanti e verifica che FireRating sia presente e nell'intervallo consentito. Risultato: un rapporto che indica, per ogni elemento, cosa rispetta e cosa no — con motivazione.

Ciò che in passato richiedeva ore di campionature manuali per ogni consegna IFC, in questa forma si risolve in pochi secondi. E soprattutto: in modo riproducibile a ogni nuova consegna.

Cosa IDS non risolve ancora

Per quanto utile, lo standard non è universale. Tre cose stanno esplicitamente fuori dal campo di applicazione di IDS.

• Verifiche geometriche. Altezza minima, distanza minima, larghezza di passaggio porte — tutto ciò che richiede una misura metrica non è esprimibile in IDS. Servono strumenti con un proprio motore geometrico, spesso in combinazione con un workflow BCF.
• Rilevamento collisioni. La clash detection è un tema affine ma distinto. IDS non dice nulla sulle relazioni spaziali.
• Logica trasversale. "Un muro con FireRating REI90 dovrebbe essere spesso almeno 12 cm" combina geometria e proprietà — e si trova quindi fuori da IDS 1.0.

Queste lacune, dal mio punto di vista, non sono un fallimento dello standard ma una delimitazione voluta. IDS è il linguaggio per controlli di requisiti strutturati. Per il resto esistono altri strumenti — di solito proprio quelli che già girano nello stack BIM.

Conclusione

Dalla pubblicazione della 1.0, IDS non è più un tema di ricerca. Lo standard c'è, gli strumenti pure. Il passaggio dal capitolato Word alla libreria IDS non è un'azione una tantum, ma un processo graduale. La maggior parte dei progetti che seguo parte con dieci-quindici regole e cresce passo dopo passo con l'esperienza.

Chi vuole provare una prima regola da solo può farlo direttamente nel browser su ifclint.com. Caricare un modello IFC esistente, fornire un file IDS o assemblarne uno nell'editor — e lasciare che venga controllato. Il risultato esce come rapporto BCF, pronto per essere consegnato a progettisti e specialisti.

Per il contesto sulle questioni di qualità sottostanti, vedere «Perché l'assurance qualità IFC decide del successo o del fallimento dei progetti BIM» e «I 10 errori più frequenti nei modelli IFC».