[blog Autodesk “dal BIM in poi” – autore: Ilaria Lagazio]
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…….
Per approfondimenti:
www.autodesk.com/interoperability
www.autodesk.com/campaigns/interoperability
http://buildingsmart.org/compliance/certified-software/
Salve, sono d’accordo con quello che dice tranne che per il discorso “BIM aperto”, il mondo Autodesk è aperto solo su se stesso, questa è ovviamente una politica di Autodesk e questo è confermato dalla recente scelta di modificare le licenze. Il BIM Autodesk è sicuramente completo e copre ogni fase dando la possibilità di passare da una fase all’altra in maniera molto semplice tuttavia questo costringe ad utilizzare necessariamente solo software Autodesk. L’utilizzo del formato IFC in questo senso darebbe libertà di scelta del programma preferito.
Buongiorno Alessandro,
grazie del suo commento. Mi permetta una battuta, ma se non è d’accordo su “BIM aperto” non è d’accordo su nulla di ciò che ho scritto o più probabilmente non sono stata capace di farmi capire.
Fondamentalmente porta come prova del fatto che il BIM Autodesk non sia aperto la scelta di modificare il modello di vendita delle licenze.
Voglio precisare a scanso di equivoci che “BIM aperto” non è un termine riferito relazione all'”acquisto/possesso” piuttosto che “affitto” (o subscription) della licenza, ma è riferito alla possibilità di interoperare, quindi si riferisce esclusivamente di aspetti tecnici.
Tecnicamente parlando, Autodesk ha una serie di prodotti certificati IFC (li trova a questo link: http://www.buildingsmart-tech.org/certification/ifc-certification-2.0/ifc2x3-cv-v2.0-certification/participants) oltre a quelli in via di certificazione; inoltre Autodesk da sempre investe in Open Source, Application Program Interface, esporta in COBie sia da Navisworks che da Revit, tanto per fare alcuni esempi di cui può trovare traccia online e negli add-on dei nostri prodotti.
Il fatto che lei dia per scontato che il BIM Autodesk sia “chiuso” è – proprio come affermo nell’articolo – una opinione molto diffusa. Questo accade in parte perchè come strategia di mercato, Autodesk ha sempre avuto l’ambizione di completare il workflow sviluppando o acquisendo i “pezzi mancanti”; in parte perchè noi tecnici, mostrando i nostri prodotti, abbiamo sempre dato più rilevanza ai nostri flussi di lavoro interno che alle funzioni di scambio.
Personalmente ricordo che dalla versione “Revit Building 8” ricevetti le slide relative al formato IFC in Revit e ricordo di non aver dato molta enfasi alla cosa, probabilmente perchè nel lontano 2007 (in ambito informatico un decennio è un’era geologica) mai si sarebbe previsto che il BIM avrebbe avuto risvolti così dominanti, tanto da porre la questione dell’interoperabilità al centro della scena.
All’epoca effettivamente il flusso di lavoro BIM Autodesk a mio avviso era l’unico che cominciava a delinearsi come “potenzialmente completo” ed questo era il suo punto di forza. Questa era la mia opinione da cliente, quale ero fino al 2006 quando, avendo scelto Revit fin dal 2001, osservai con attenzione l’evoluzione di quel link noto a pochi che stava sviluppando una certa “Robobat di Grenoble” e che da strutturista mi faceva sognare un mondo in cui i dati si sarebbero spostati in automatico da una applicazione all’altra…: link che senza un interfaccia di Revit aperto (Application Program Interface) da parte di una softwarehouse esterna non sarebbe mai stato possibile.
Sono pienamente d’accordo con lei invece sul fatto che le cose oggi sono cambiate ed è assolutamente auspicabile che tutte le softwarehouse investano in IFC e altri formati aperti sempre di più e sicuramente più che in passato perchè sul panorama attuale è l’unico modo per garantire una ottimizzazione dei processi. Per quanto posso vedere in casa Autodesk noi non mancheremo di fare la nostra parte.
La ringrazio per la sua opinione e non manchi di scrivermi ulteriormente o contattarmi se ne ha piacere.
Ilaria
Salve Ilaria, grazie per avermi risposto, forse non sono stato molto chiaro, non ho frainteso il bim con le licenze autodesk
Conosco il “BIM aperto”, il formato ifc, la buildingsmart ecc.
Intendevo solo dire che la possibilità per un programma di esportare in formato ifc non lo rende necessariamente “open”.
Nel post precedente intendevo dire che secondo il mio modesto parere la filosofia di Autodesk è quella di invogliare l’utente all’utilizzo di un workflow interno come lei mi ha anche confermato, e l’uscita delle nuove subscription ne sono una conferma. Questa è la mia opinione personale che mi sono fatto utilizzando i vari programmi e non ascoltando l’opinione comune.
Come dicevo il workflow interno è ottimizzato, lo è molto meno verso formati esterni. Il BIM del futuro necessita invece di un unico formato in maniera tale da permettere veramente il lavoro congiunto di più parti indipendentemente dal software. Specifico che non parlo da esperto del settore ma da semplice utilizzatore di software, in particolare Civil 3D che lo utilizzo dalla versione 2006.
Buongiorno Alessandro,
grazie a lei dei commenti; credo infine che stiamo dicendo la stessa cosa.
Ovviamente i workflow interni sono ottimizzati, la strategia di Autodesk è sempre stata quella di offrire un workflow completo per chi vuole rimanere all’interno della nostra proposta; e come dice lei prima le Suites e poi le Collections tendono a mettere il progettista in condizioni di ottimizzare l’investimento con un parco di prodotti coi quali possa fare “tutto” ciò che vuole. D’altra parte è sicuramente più semplice far parlare tra loro due applicazioni che vengono sviluppate dallo stesso team piuttosto che tra aziende differenti.
Tuttavia l’importanza dell’interoperabilità non è mai stata sottovalutata e un ecosistema aperto non è mai stato considerato da Autodesk come una minaccia ma come una opportunità da perseguire e su cui investire massicciamente.
Le faccio un esempio pratico: le soluzioni di risparmio energetico in Autodesk sono eccezionali dal punto di vista dell’ottimizzazione e della velocità de calcolo, ma è ovvio che non ci siano parti dedicate alla classica “certificazione” italiana e dei vari Paesi. Sappiamo bene che burocraticamente parlando questi dettgli sono fondamentali e per questo è altrettanto fondamentale generare formati aperti che permettano di collaborare con softwarehouse locali. Ignorare questi aspetti di localizzazione taglierebbe un prodotto anche eccellente fuori dai singoli mercati.
Grazie dell’attenzione e buona giornata
Beh, che dire: una descrizione del problema IFC praticamente da manuale e 2 commenti di ugual valore. Vorrei solo sottolineare la pochissima presenza di post di qualità come questi che indubbiamente “sfasciano” le convinzioni costruite ad arte da parte di qualche esperto marketing sotto mentite spoglie. Brava Ilaria e complimenti ai due commenti.
Sono d’accordo con Guido.
In campo infrastrutturale la questione è ancora più complessa, e non mi risulta che sia stata già affrontata.
Prima di tutto occorre chiarire bene a tutti che anche se è teoricamente possibile esportare ed importare IFC nei progetti di infrastrutture, non è per niente detto che sia utile, per ora.
Intanto ho già fatto notare agli estensori dello standard IFC, che stanno cercando il modo migliore di rappresentare il modello del terreno, che non occorre inventarsi nulla, basta utilizzare l’esperienza (Open) di LandXML.
“E che dire della progettazione infrastrutturale, dove il concetto di IFC è solo agli albori?”
Concordo pienamente e, credo, sia importante approfondire bene quale sia una buona strada da seguire.
Di fatto credo che “il sottobosco di scambi tra i professionisti di formati utilizzati” sia lo standard attuale, purtroppo necessariamente.
Non so se sia possibile (di sicuro non facile) strutturare un formato di interscambio (parlo sempre delle infrastrutture) che possa soddisfare le esigenze di tutti gli attori (committente/gestore, costruttore, vari tipi di professionisti), ma di sicuro va fatto ordine per cercare di ottenere quello che si puo’, magari per gradi.