Ricordo bene la prima volta che ebbi a che fare con la progettazione antincendio.  

Utilizzare la parola trauma per descrivere il primo impatto con quel mondo sarebbe a dir modo riduttivo. 

La pura verità è che non ci capivo una cippa. 

Ogni documento che mi capitava di leggere era farcito da sigle (all’epoca) incomprensibili, di conseguenza ci mettevo 10 volte il tempo che impiego ora per comprendere il problema che mi si parava davanti.  

Sono convinto che la situazione che ti ho appena descritto vale per l’antincendio così come ogni ambito in cui sono presenti sigle ed acronimi non proprio di semplice comprensione.  

Mosso dall’intenzione di evitarti il mio calvario passato e di velocizzare di 10 volte il tuo processo produttivo (o quanto meno di comprensione) ho deciso di scrivere quest’articolo riguardo all’IFC nel BIM. 

Come vedi sono presenti altre 2 sigle all’apparenza incomprensibili. non temere, non lo saranno più al termine di quest’articolo.

Prima di comprendere il concetto di IFC, ripassiamo la definizione di BIM.  

L’acronimo di BIM sta per building information modeling, ovvero un modello virtuale dell’edificio costituito dalle informazioni necessarie per progettarlo. 

Data la complessità sempre maggiore e le normative sempre più stringenti, ogni ambito specialistico richiede dei software ad esso dedicato (software di calcolo, di illuminotecnica, analisi energetica, etc).

Sorge quindi spontanea la necessità di scambiare informazioni tra i vari programmi con maggior facilità. 

I più esperti la chiamano interoperabilità. 

L’ interoperabilità riguarda le modalità di trasferimento dei dati tra applicazioni diverse nel modo più semplice e veloce possibile. 

E’ di fondamentale importanza agevolare l’interoperabilità in quanto rappresenta la chiave di volta dei processi BIM.  

Se i dati di progetto generati dalla soluzione di uno specialista (strutturista, termotecnico, lighting designer, etc.) venissero importati manualmente, tutto il processo progettuale diventerebbe oltremodo macchinoso, e la collaborazione necessaria per trovare le soluzioni migliori verrebbe disincentivata.  

A differenza di quanto avveniva in passato con i formati CAD ora gli oggetti che vedi sullo schermo possiedono numerose proprietà (oltre alle dimensioni è possibile inserire dati relativi ai comportamenti fisici, statici, etc). 

Questo modo di procedere porta a far sì che il modello diventi più complesso.  

Ogni simulazione di un oggetto, che sia un modello statico, energetico o architettonico, difficilmente diventa utilizzabile per gli altri campi, in quanto l’esigenza di ogni ambito è specifica e richiede un modello ad essa dedicata. 

Di conseguenza cambia anche il significato dello stesso elemento a seconda dei campi di interesse.  

Mi spiego meglio: Ipotizziamo che te stia lavorando su un modello architettonico. La definizione ed il concetto di “muro” può assumere un significato legato alla delimitazione dello spazio o di materiali e delle tecnologie costruttive. 

il muro se analizzato nell’ambito di analisi energetica assume un significato totalmente differente rispetto a quando viene analizzato secondo le sue funzioni strutturali, questo perchè i dati che si utilizzano in ambito statico per descrivere e studiare un oggetto sono totalmente diversi da quelli dell’ambito energetico .  

Come conseguenza ogni porzione di modello studiata da uno specialista contribuirà a definire comportamenti differenti dello stesso oggetto. E magari subirà modifiche ed adattamenti una volta che “rimbalza” da un professionista ad un altro.  E’ quindi necessario “far dialogare” insieme i vari modelli (strutturale, impiantistico, architettonico, etc.) cercando di evitare di utilizzare più dati e informazioni di quanto necessario al fine di rendere il più agevole possibile lo scambio di informazioni.  

Dal momento che diverse applicazioni (ad esempio una dedicata ai calcoli strutturali ed una a quelli energetici) analizzano gli stessi oggetti che compongono l’edificio con occhi diversi il rischio concreto durante lo scambio dei vari file è quello di una ridondanza di informazioni con ciò che ne consegue in termini di gestione dei file e di velocità di lavoro. 

E’ proprio per agevolare gli scambi di dati tra applicazioni differenti che è nato il formato di file IFC.

LE ORIGINI DELL’IFC.

Per capire l’essenza dell’IFC è necessario fare un breve salto indietro nel tempo, quando l’ISO di Ginevra ed altri enti direttamente connessi all’ISO svilupparono uno standard chiamato STEP (Standard for The Exchange of Product model data), numerato ISO 10303. Il principale prodotto dell’ISO 10303 fu lo sviluppo del linguaggio EXPRESS.  

Sulla base del linguaggio EXPRESS è stato definito un product data model indipendente dedicato all’industria dell’edilizia.  

Sono consapevole che ti stia chiedendo “Ma che cactus è un product data model?”  

Provo ad esprimerti il concetto con una metafora. Immagina il product data model alla stregua di un sacchetto della tombola con al posto dei numeri una serie di parole. Queste parole sono le uniche che hai a disposizione per descrivere un oggetto presente nell’edificio.

Siccome un edificio è composto da tanti elementi, alcuni di essi faranno riferimento ad una stessa parola chiave. Quello che puoi fare in questi casi per rendere più precisa la descrizione è modificare i parametri associati.  

Ipotizziamo che te abbia due stanze di 9 e 12 mq. Per descriverle non potrai usare il sostantivo stanza, perché non presente all’interno del sacchetto (o magari non lo hai pescato), tuttavia con uno sforzo di immaginazione potrai utilizzare la parola che meglio descrive quell’elemento che hai modellato.

In questo caso la parola che più si avvicina è “superficie”. Quindi avrai due superfici all’interno del tuo file.

Come fare a distinguere i due elementi? Associando un altro dato (ad esempio il valore in mq) alle superfici. 

Cosi facendo avrai due superfici di 9 e di 12 mq.

Quindi maggiori sono le parole a tua disposizione e maggiori sono le possibilità a tua disposizione per poter descrivere con precisione ogni elemento che compone l’edificio.  

Grazie all’ampiezza del suo dizionario di base l’IFC permette numerosi scambi tra applicazioni  AEC differenti.

Ovviamente nella realtà le cose sono un pò più complicate di quanto ti ho spiegato, ma ritengo importante afferrare il concetto. Se vuoi approfondire il vocabolario che compone il file IFC puoi farlo a questo link.

I LIMITI DEL FORMATO IFC E LE MVD 

Ogni file IFC è formato da una geometria, una serie di relazioni e di proprietà.

Anche se i file IFC provenienti da applicazioni diverse permettono il dialogo tra le applicazioni, ad oggi esiste il rischio concreto di “sovrapporre” le informazioni disponibili, creando dei file molto più pesanti di quanto necessario.  

File più pesanti comportano un impiego di risorse maggiori, modelli più complessi e di conseguenza maggiori difficoltà di gestione.  

Per queste ragioni il modello che viene esportato dovrebbe contenere la quantità di informazioni minime in relazione all’utilizzo previsto.  

Per raggiungere questi obbiettivi è stato introdotto il concetto di Model View Definitions (MVD) ovvero un diagramma che descrive gli scambi di dati tra vari attori coinvolti nel processo edilizio.  

Per capire il concetto alla base delle MVD ci viene in soccorso Mies Van Der Rohe ed il suo celebre aforisma “Meno è più” (Less is more).  

Meno dati sono uguali a più leggerezza, chiarezza e facilità di gestione del modello.  

Per non tralasciare dati essenziali o includerne di inutili si è sviluppata una rappresentazione del processo di comunicazione tra due attori durante una fase progettuale. In questo modo è possibile capire e conoscere di quali dati ha bisogno una figura professionale in un dato momento del progetto.  

Codificando le procedure di scambio sarà possibile riuscire a stabilire degli standard minimi relativi allo scambio di dati tra i vari professionisti. In questo modo sarà possibile accelerare gli scambi di file.  

(Come ti avevo anticipato all’inizio quest’articolo sarebbe stato farcito di sigle semi-incomprensibili.

Ma non temere, ti faccio un altro esempio per chiarire meglio il concetto delle MVD.  

Ipotizziamo che stia progettando un edificio rivestito in corten e debba inoltrare il modello a chi dovrà realizzare il render esterno per un fotoinserimento. Al renderista interesserà esclusivamente la sagoma esterna dell’edificio, il layout interno, le informazioni relative alla struttura, alla composizione delle pareti, ai tipi di finestre etc. Sono tutte informazioni per lui superflue.  

L’impiantista, a differenza del renderista, avrà a cuore un altro tipo di dati ed informazioni, ovvero quelle relative al tipo di macchina installata nell’edificio, le stratigrafie delle pareti, le altezze delle stanze (qualora debbano essere presenti delle canalizzazioni degli impianti) etc.

La Model View Definition quindi simula le due situazioni che ti ho appena descritto e definisce i dati che sono necessari in uno o nell’altro caso.  

Questi sono solo 2 dei possibili casi, tuttavia conoscere con precisione le informazioni richieste da un attore del processo edilizio, aiuta il lavoro di tutti.  

Questa “mappa” delle informazioni la puoi trovare  consultando le MVD, all’interno del quale troverai la lista di oggetti, dati, relazioni, informazioni e rappresentazioni necessarie al destinatario del tuo file di scambio per svolgere il lavoro nel miglior modo possibile. 

L’obbiettivo finale è quello di avere un’atlante delle MVD il più ampio possibile, che abbia analizzato la totalità o quasi degli scambi possibili, e definito per ogni possibilità i dati necessari ai professionisti coinvolti.

Bene direi che per oggi è tutto. 

Grazie a questo articolo:

hai compreso il significato di interoperabilità in ambito BIM.

Hai scoperto come funziona un file IFC e perchè è importante.

Conosci le MVD ed il loro funzionamento

Direi che per oggi abbastanza.

Vai piano