PROGETTARE BIM, Software e INTEROPERABILITA’: qualche riflessione… utile

Negli ultimi mesi ho notato un crescente e virale interesse nei confronti delle problematiche relative all’interoperabilità tra piattaforme differenti.

Non c’è evento in cui non compaiano le “domande standard”: “Revit è certificato IFC? é vero che il BIM Autodesk è “chiuso”?”

Interrogativi che in parte sorgono spontanei leggendo l’articolo 23 del Nuovo Codice Appalti – comma 13, che enunciando la possibile richiesta da parte delle stazioni appaltanti dell’uso di metodi e strumenti elettronici precisa: “Tali strumenti utilizzano piattaforme interoperabili a mezzo di formati aperti non proprietari, al fine di non limitare la concorrenza tra i fornitori di tecnologie e di non limitare il coinvolgimento di specifiche progettualità tra i progettisti”.

Sottolineo in parte, perchè credo anche che ci sia stata una forte intenzionalità da parte del mercato (o “marketing”) nel  travisare il concetto di “piattaforme interoperabili” e “formati aperti” riducendo la assai complessa questione ad una pura esportazione in formato IFC in concomitanza con la nascita di svariate alleanze di produttori “OPEN BIM” che hanno sottinteso implicitamente esclusi gli altri (tra cui Autodesk) dalla gamma dei “BIM APERTI”.

Proverò a rispondere prima in maniera chiara alla domanda principe: Revit non solo è certificato IFC, ma soprattutto l’opzione IFC è stata aggiunta in Revit già nel 2007 e dal 2012 il codice IFC di Revit è un “Open Source” in modo da poterlo anche personalizzare per adattarlo alle varie situazioni (in quanto come vedremo non è sempre perfettamente esauriente).

Aggiungo a tal proposito che Autodesk è Socio Fondatore della associazione “Building Smart International” dal lontano 1995 ed ha sempre fortemente supportato il formato IFC, tanto da avere oggi il maggior numero di software IFC compatibili (14 interfacciati e 7 certificati) tra tutti i maggiori provider di software.

Se volete sorridere del nostro passato a questo proposito date un’occhiata a questo simpatico filmato, “IFC – Where it all started – the end of Babel” datato 1994.

E che dire poi, parlando di interoperabilità, del concetto stesso di AutoCAD (ebbene sì forse per la prima volta mi sentite parlare di AutoCAD!) che nel lontano 1982 ha costituito il primo CAD al mondo basato sul principio di interoperabilità: si trattava infatti di un CAD che funzionava su qualsiasi PC, creando una netta discontinuità col passato, quando ogni sistema CAD era associato ad uno specifico hardware: Autodesk è nata con un concetto intrinseco di interoperabilità.

E che dire ancora di tutti gli Application Program Interface (API) appositamente sviluppati per ogni versione dei software Autodesk, proprio per permettere a qualunque sviluppatore di dialogare con essi?

Quindi la risposta più semplice e immediata che posso dare è la più banale: è evidente che Autodesk supporta l’interoperabilità ed investe in interoperabilità.

Ma allora perchè tante obiezioni relative al BIM Autodesk come un BIM “chiuso”?  Qui bisogna fare chiarezza.

Il BIM Autodesk non è affatto “chiuso” o “più chiuso” di altri BIM concorrenti. Il BIM Autodesk è invece “Completo”. Questo significa che pur dando per scontato il fatto che è indispensabile interoperare e investire in interoperabilità, la soluzione Autodesk consente di sviluppare tutto il progetto rimanendo, volendo, all’interno di casa Autodesk, riducendo magari al minimo l’utilizzo di plugin locali (interoperabili) per considerazioni molto specifiche.

Mi preme anche sottolineare che “Building Smart International” co-fondato da Autodesk è l’UNICO ente al mondo in grado di CERTIFICARE i software dal punto di vista IFC compatibility.

Permettetemi di aggiungere di fare molta attenzione: solo ed esclusivamente questo tipo di targhetta vi dà la garanzia che un software è certificato IFC e vi dice in che termini: tutto il resto è solo marketing.

Detto questo, una dovuta riflessione su cosa è veramente il formato IFC e cosa possiamo illuderci di ottenere a mio avviso è indispensabile.

Prima di tutto IFC è un formato DI SCAMBIO. Non si può lavorare in IFC, si può solo scambiare informazioni. Ad oggi ritengo, ma smentitemi se avete altre evidenze, che il modo più interessante di lavorare interoperando con un collega che mi invia un suo formato IFC è linkarlo al mio file in Revit. Oppure, se lo devo solo interrogare posso pensare di aprirlo con il Large Model Viewer (https://a360.autodesk.com/viewer/) gratuito online, che perlatro aprirebbe tranquillamente anche il formato nativo originale. Se poi lo dovessi usare per la gestione del cantiere potrei aprirlo con Navisworks, ma ancora una volta… potrei usare il formato nativo. Spero che questi dubbi inizino a far porre delle domande…

Altra domanda tipica dell’utente: perchè esportando in IFC da un software certificato e reimportandolo sullo stesso software non ottengo esattamente indietro tutte le informazioni?

Perchè esattamente come sto cercando di spiegare, IFC oggi ha ancora delle limitazioni. Un software viene certificato IFC regolarmente se è in grado di importare / esportare una certa serie di parametri definiti; anno dopo anno i software evolvono, i link migliorano, il formato IFC cambia (2×3, 4.0 ecc) più parametri vengono mappati e la vita del progettista migliora.

Nonostante la mia puntuale critica, io credo fermamente che il formato IFC sarà il futuro, insieme ad altri tool di collaborazione.

Volendo spingere al limite il concetto di interoperabilità “al fine di non limitare la concorrenza tra i fornitori di tecnologie “ perchè non potremmo pretendere ad esempio che un fornitore di carpenteria per un edificio in acciaio utilizzasse un formato IFC per la produzione a controllo numerico, costringendolo a modificare i formati di input delle macchine? Non pensate che il produttore ci darebbe dei pazzi?

O perchè non potremmo insistere che per un calcolo energetico invece di un formato gbXML, un Energy Manager si potrebbe accontentare di un IFC?

E che dire della progettazione infrastrutturale, dove il concetto di IFC è solo agli albori?

Occorre fare attenzione che tutta questa sete di neutralità non finisca per diventare una ortodossia, che porterebbe come possiamo facilmente immaginare ad un formato “ufficiale” in IFC e un sottobosco di scambi tra i professionisti di formati utilizzati sui quali non sarebbe poi possibile gestire alcuna contestazione dal momento che non sono ufficiali, mentre uno degli scopi principali del BIM è proprio quello di avere un modello come riferimento incontestabile.

Insomma, la mia riflessione vuole essere solo un punto di partenza per comprendere quanto vasta sia la problematica dell’interoperabilità che giustamente viene sollevata in ambito di appalti pubblici e senza dubbio va garantita al massimo la neutralità, ma di sicuro non è consegnando un file IFC (che pure ritengo sia l’obiettivo che ci dobbiamo porre a medio termine) che ci possiamo ritenere al sicuro da tutti i problemi.

E di sicuro, scegliere un Software solo in base alla sua targhetta IFC è una scelta sbagliata.

Un’ultima riflessione: gli anglosassoni, che sono molto più avanti di noi rispetto al BIM, nelle loro norme di riferimento per il “BIM Level 2”, non richiedono mai in nessuna fase un file in formato IFC: possibile che nessuno si preoccupi da loro della concorrenza libera, o forse ci sfugge qualcosa?

Ciò che viene richiesto nei Paesi Anglosassoni per il BIM Level 2, anche per gli appalti pubblici è il file NATIVO, i pdf di tutte le tavole e il file COBie (Construction Operation Building Information Exchange), anche esso esportabile da Revit e da Navisworks, che, guardacaso perchè gli inglesi sono più avanti di noi, si riferisce alla fase di handover e gestione del manufatto edilizio, spostando la vera centralità del discorso BIM dalla fase di progetto al Facility Management.

In questo mondo in rapida evoluzione, mi sorge quindi il dubbio che mentre ci accingiamo ad intraprendere la nostra strada verso il BIM e forse a renderla troppo rigida e mentre il formato IFC evolve, le cose saranno probabilmente destinate a cambiare ancora ...