Il blog di Archicad Italia

Uno dei temi più controversi e dibattuti nel mondo del BIM è quello sui formati d'interscambio e in particolare l'IFC.

Mi è spesso capitato di sentire opinioni critiche su IFC che si ripetono con esatta precisione e con tale frequenza da far pensare di trovarci di fronte ad alcune "vox populi" su cui è invece meglio fermarsi a riflettere, soprattutto per non alimentare un clima di contrapposizione che è dannoso e che ha poco a che fare con l'essenza del BIM. 

Proviamo ad esaminare alcuni dei principali miti da sfatare su IFC:

1. "Con IFC c'è una perdita di dati"

La sentenza del TAR della Lombardia del 2017 sostiene che "è noto dalla letteratura nazionale ed internazionale che in fase di esportazione del file in formato IFC è possibile che una parte, a volte anche significativa dei dati, possa andare perduta".
Ad oggi non è ben chiara quale sia la letteratura a cui fa riferimento la sentenza in oggetto, e soprattutto non vi sono evidenze a suffragare tale affermazione.

Ragioniamo un momento sul tema: un programma di BIM authoring come ARCHICAD ha massimo una cinquantina di strumenti di modellazione, ognuno dei quali ha una serie di possibili variabili. IFC ha invece più di 800 entità, considerati gli oggetti e le loro relazioni, e può inoltre generare infiniti Property Set personalizzati.

Nel travaso dal formato proprietario al formato IFC, il collo di bottiglia non può essere rappresentato dal contenitore più ampio ma da quello meno capiente: i programmi proprietari che esportano ed importano il formato IFC. 
Dov'è il problema allora?

Ogni qualvolta si manifestano dei problemi siamo poco propensi ad assumercene le responsabilità, quindi imputiamo le colpe agli altri operatori ("è colpa del tuo software") o meglio ancora ce la prendiamo con chi è assente in quel momento e non è in grado di difendersi (quindi IFC). Eppure è possibile effettuare una semplice verifica, aprendo il file IFC generato con un visualizzatore IFC (ce ne sono diversi, per lo più gratuiti), oppure addirittura in un editor di testo: se il dato è visibile nel visualizzatore o nelle righe di testo che compongono l'IFC, allora il problema è nel software di lettura.

L'operazione con cui si assegna un oggetto ad un' Entità IFC è denominata "Mappaggio Tipo".  In ARCHICAD abbiamo estrema flessibilità per associare gli elementi e le loro proprietà all'IFC Type più consono all'uso stabilito.

2. "IFC non è modificabile"

E non deve esserlo!

Già nel 2013 la PAS 1192 - 2 sosteneva che ogni modifica ai devirables depositati all'interno della piattaforma del Common Data Environment deve essere necessariamente a carico dell'autore (originator) del deliverable stesso, sia esso un modello, un documento od un elaborato, indipendentemente dal formato utilizzato, proprietario o aperto.

L'obiezione che mi è capitato con più frequenza di sentire è che "nel caso il committente voglia cambiare qualcosa, con il formato nativo è in grado di farlo". A parte che ciò è possibile solo nel caso in cui progettista e committente condividano lo stesso software, ma fondamentalmente questo è in aperta contraddizione con i principi fondanti del BIM prima ancora che delle norme che vigilano sulla pluralità della libera concorrenza.

Il BIM è un mondo complesso, dove ogni elemento è interconnesso e la possibilità che il committente, o chiunque altro, possa avvalersi di scorciatoie per velocizzare il processo assomiglia più ad una espediente che ad una reale esigenza del committente.
Nel caso invece sia necessario impostare un nuovo lavoro partendo da un Asset esistente, bisogna necessario redigere un nuovo Capitolato Informativo; la problematica riscontrata ha più a che vedere con la stesura dei contratti che con una problematica tecnico ed informatica.

E in ogni caso, se proprio il committente, o chi per esso, vuole modificare un componente IFC, può aprire il modello IFC con qualsiasi software, effettuare la modifica e successivamente esportare nuovamente il tutto con il componente modificato; in ogni situazione, la modifica deve essere tracciata e validata.

3. "Una volta ultimato il modello, il progettista deve tradurlo nel formato IFC con un ulteriore aggravio di lavoro"

Molto dipende dal metodo di lavoro di ogni software ma in linea di massima è possibile gestire dei traduttori che predetermino le caratteristiche dell'IFC in base agli usi del modello.

Ma il punto principale è che un file IFC non è inteso per ottenere una copia quanto più possibile simile al formato nativo di origine. Scopo dell'IFC è generare modelli che rispondano alle esigenze dei diversi usi del modello.

Diversamente dai formati nativi, con IFC è possibile:

• determinare le caratteristiche geometriche degli oggetti;
• stabilire relazioni fra i componenti, differenziate in base all'uso;
• filtrare i dati per trasportare solo quelli veramente necessari allo scopo.

Il lavoro di traduzione nel formato IFC, in particolare la necessità di determinare la corrispondenza fra proprietà del modello nativo e proprietà IFC, non è un lavoro "in più" ma è il fattore che determina il vero valore del BIM: con IFC siamo in grado di consegnare al committente un modello conformato alle esigenze della commessa e non alla praticità e convenienza del progettista.

Libera reinterpretazione di un concetto espresso anche in immagine da Mark Baldwin nel suo The BIM Manager

Mark Baldwin nel suo The BIM Manager, A practical Guide for BIM Project Management, (libro di cui consiglio vivamente la lettura), sfata il mito del modello unico centralizzato in grado di gestire dal suo interno tutte le discipline e propone invece  una confederazione di modelli d'interscambio da gestire internamente alla Piattaforma AcDat o CDE. "In questo scenario, i modelli interscambiati non sono 'live' ma copie compatibili dei modelli originali nativi. Pertanto "gli autori del modello lavorano in un ambiente 'live' ma interscambiano modelli compatibili con il team di progetto allargato ad intervalli concordati per il coordinamento. In un Progetto BIM collaborativo ci si sposta continuamente da un ambiente nativo a un ambiente collaborativo". 

Nell'ambiente collaborativo, continua Baldwin, i modelli sono "strutturati per i cicli di revisione ed aiutano a definire gli scopi e le responsabilità di ciascun partecipante al progetto".

©Mark Baldwin.

Fino a qualche anno fa l'attenzione degli operatori del BIM era concentrata sull'aumento di efficienza dei progettisti attraverso l'uso di oggetti altamente parametrici che consentano di modificare rapidamente e comodamente le caratteristiche dei componenti. Ma se consideriamo che le fasi di Design vero e proprio costituiscono soltanto una minima porzione dell'intero ciclo di operazioni del BIM, si capisce che l'attenzione debba necessariamente essere spostata verso le fasi ulteriori, dal coordinamento multidisciplinare in avanti, comprese la gestione e manutenzione dell'Asset.

Da questa prospettiva, l'interesse verso la "parametricità" di un oggetto viene meno, e anzi diventa controproducente: ai fini della commessa un generico oggetto finestra non ha nessun valore, mentre è prezioso il modello di una specifica finestra, prodotta dal tal produttore, che abbia al suo interno le informazioni previamente concordate e che soprattutto abbia superato il ciclo di validazione programmato. 

4. "Esistono delle possibili alternative ad IFC"

Quali sono le alternative all'uso del formato IFC? Poche al momento e nessuna di queste è esaustiva quanto il formato IFC.

In prima istanza si può pensare di lavorare tutti con lo stesso software anche se è impossibile ritenere che un unico software, o una suite di un'unica softwarehouse, possa soddisfare tutte le esigenze di un team multidisciplinare.
Tante volte poi abbiamo l'esigenza di dialogare con software locali: diversi software di authoring propongono soluzioni per la valutazione energetica dei modelli ma nessuno è in grado di produrre un Attestato di Prestazione Energetica perchè nessuna software house internazionale sarà mai in grado di rapportarsi con le diverse normative locali.
I plug-in di interscambio stanno rapidamente diminuendo rispetto ad alcuni anni fa perchè IFC garantisce comunque un interscambio dettagliato e preciso con il vantaggio ulteriore di non dover aggiornare il plug-in ad ogni nuova versione dei software: è un'operazione onerosa, tanto da esporci al rischio che la software house decida di non proseguirne lo sviluppo, caso anche piuttosto frequente, privando così l'utente da un giorno all'altro degli strumenti di lavoro necessari.

Con IFC l'operatore può gestire in totale trasparenza il processo d'interscambio mentre non sempre si è a conoscenza di come gestiscono i dati software che non si utilizzano, a meno che non avere delle competenze molto approfondite in merito, molto spesso superflue.

Quante volte è capitato ad utenti poco esperti di venir condizionati nella modellazione di un oggetto dalle caratteristiche del software? Analogamente, se non entriamo nel vivo della materia del BIM, saremo portati a replicare determinati schemi processuali perchè più facilmente gestibili o perchè predisposti all'interno di un qualche software. IFC diventa determinante per compiere il passaggio verso il BIM "maturo", dove i modelli sono espressione delle esigenze del committente e del tutto coerenti con il processo gestionale del progetto.

Esistono altri metodi di trasmissione basati sull'interscambio del puro dato, che vanno cioè a lavorare alla radice della questione: rendere i software capaci di veicolare direttamente l'informazione senza bisogno del tramite di un file contenitore. Ad esempio è possibile interscambiare le informazioni attraverso l'uso di database relazionali, a loro volta connessi ad altri database. Oppure è possibile ricorrere a strumenti di scripting informatico (Python, Json, ecc) per generare dei link dinamici fra software diversi: ad ogni modifica del modello generata in un software, otteniamo una pari variazione nell'altro software.

La Live Connection Rhino/Grasshopper/ARCHICAD non prevede uno scambio di file ma di informazioni necessarie a generare geometrie e dati. Tuttavia è un processo che non va a sostituire l'utilizzo dell'IFC.

Ma sono metodi questi che non si pongono in alternativa all'uso dell'IFC e rispondono piuttosto ad altri tipi di esigenza, quali la modellazione avanzata di forme complesse o analisi delle performance del manufatto condotta con strumenti computazionali avanzati. Ma la mancanza del supporto del file non permette di tenere traccia dello stato di avanzamento del modello che è un'entità in continuo sviluppo e che varia costantemente secondo la disciplina di riferimento; IFC costituisce una configurazione stabile del modello, coerente con i requisiti imposti e le responsabilità assegnate. 

Inoltre, se l'uso dell'IFC viene talvolta criticato per la sua complessità, l'impiego di questi metodi proposti come sua alternativa rappresentano da questo punto di vista, un ostacolo ancora maggiore. 

Concludo queste considerazioni ricordando che:

• Il formato IFC non ha una "scadenza": oggi, domani o fra 10 anni sarò ancora in grado di aprire e gestire un file IFC, mentre non è possibile dire lo stesso di un file in formato proprietario dove per ragioni puramente commerciali viene limitato, in maniera più o meno severa, l'accesso dei file da parte di versioni del software precedenti.
• IFC è il risultato di anni di lavoro da parte di un'entità sovranazionale, BuildingSmart, nato dal contributo collettivo e neutrale di diversi rappresentanti del mondo delle costruzioni. A partire dal 2018 è divenuto, con la norma ISO 16379, uno standard riconosciuto ufficialmente a livello internazionale.
• Sono di prossima uscita le nuove definizioni IFC relative agli elementi infrastrutturali, così da comprendere l'ambiente e il costruito nella sua interezza e non focalizzarsi soltanto ai singoli edifici.
• IFC consente di scegliere le soluzioni, e quindi i professionisti, più adatti alle esigenze contingenti fra un ventaglio di soluzioni molto ampio.