openBIM e interoperabilità: cosa cambia con l’evoluzione di IFC4

Premesse

Lo scorso giugno buildingSMART International pubblica IFC 4 ADD1, addendum che consolida lo schema IFC4 reso disponibile in forma definitiva alcuni anni fa. Il formato IFC 4 è ancora poco adottato rispetto al precedente IFC2x3. Vale la pena capire cosa significa concretamente questo aggiornamento per chi lavora sullo scambio dati tra software diversi, perché per le esigenze del Facility Management l’interoperabilità resta una necessità per la fase operativa.

Cos’è tecnicamente lo schema IFC ?

IFC, Industry Foundation Classes, è uno schema dati basato sul linguaggio EXPRESS (ISO 10303-11), sviluppato e mantenuto da un consorzio indipendente – buildingSMART – e non da una singola azienda produttrice di software. A differenza dei formati nativi dei singoli strumenti di modellazione, pensati per rappresentare al meglio le funzionalità di quello specifico software, IFC rappresenta in modo neutro gli oggetti di un edificio – pareti, porte, impianti, spazi – con le loro relazioni gerarchiche e le loro proprietà, indipendentemente da chi ha prodotto il modello e da chi dovrà leggerlo. Questa neutralità è ciò che rende teoricamente possibile lo scambio tra software diversi senza perdita di informazioni – anche se, come vedremo, la teoria e la pratica del 2015 non coincidono ancora del tutto.

Perché un addendum come ADD1 è più di un aggiornamento cosmetico?

Uno standard aperto vive attraverso revisioni che correggono ambiguità nello schema e migliorano la compatibilità tra le diverse implementazioni software. ADD1 non introduce concetti nuovi rispetto a IFC4: ne stabilizza la definizione EXPRESS, riducendo i casi in cui software diversi interpretano la stessa entità in modo differente. È un segnale di maturazione di un progetto vivo, mantenuto da una comunità tecnica che risponde ai problemi reali riscontrati nell’uso pratico – una garanzia di continuità che un formato proprietario, legato alle scelte commerciali di una singola azienda, non offre allo stesso modo.

Cosa significa concretamente “perdita informativa” in uno scambio IFC ?

Esportare un modello da un software e importarlo in un altro attraverso IFC non garantisce, in questa fase, che tutte le informazioni sopravvivano intatte: proprietà specifiche di un software potrebbero non avere un corrispondente diretto nello schema, geometrie complesse potrebbero essere semplificate nella conversione, relazioni tra oggetti potrebbero non essere ricostruite correttamente dal software di destinazione. Chi lavora in ambito progettazione con scambi IFC in questi anni sa il travaso non è esente da perdite e il risultato va sempre verificato: un modello visivamente corretto potrebbe aver perso, nel passaggio, proprietà informative che mancheranno solo più avanti, quando si proverà a estrarre un computo o un elenco di attributi.

Perché l’interoperabilità è già un requisito di filiera?

Un singolo studio che lavora sempre con lo stesso software, con lo stesso team, può in teoria fare a meno dell’interoperabilità. Ma questa situazione è sempre più rara: le commesse coinvolgono team con strumenti diversi, il committente vuole poter verificare il modello con strumenti indipendenti, e chi gestirà l’edificio userà quasi certamente un sistema diverso da quello di progettazione. In questo scenario l’interoperabilità non è più una scelta tecnica interna a un singolo studio, ma una condizione strutturale della filiera: senza un formato di scambio affidabile, ogni passaggio tra attori richiede una ricostruzione parziale del dato.

Che differenza c’è tra “esportare in IFC alla fine” e “modellare pensando allo scambio”?

Molti progettisti trattano l’interoperabilità come un’operazione finale: si modella con il proprio software abituale, e solo quando serve si esporta in IFC. L’approccio produce spesso risultati parziali, perché le scelte fatte senza pensare allo scambio non si traducono bene nello schema neutro. Un approccio più maturo progetta fin dall’inizio pensando alla condivisione: classificazioni compatibili con IFC, proprietà popolate nei campi standard, verifiche periodiche dell’esportazione durante il lavoro e non solo alla fine.

Che effetto ha, per il Facility Management?

Un progetto consegnato esclusivamente nel formato nativo di un software vincola chi lo riceve a quello stesso software, o a un costoso lavoro di conversione, per tutta la vita utile dei dati – una dipendenza tecnologica che pesa poco nell’immediato ma limita nel tempo la libertà di scegliere un altro fornitore di software o un altro team di progettazione. Nella fase attuale pochissimi contratti FM hanno già misurato il bisogno di consegne di modelli BIM. Si tende ancora a prediligere le planimetrie as built CAD bidimensionali ma certamente arriverà presto il bisogno di capire come lavorare con i modelli e farlo al meglio degli strumenti di interscambio vendor-indipendent come IFC.

Conclusioni

L’evoluzione di IFC non cambia dall’oggi al domani la pratica della maggior parte dei progetti, ancora prevalentemente legati a formati nativi. Ma segna una direzione: l’interoperabilità aperta smette di essere un esperimento per pochi progetti internazionali e comincia a diventare l’infrastruttura su cui, negli anni a venire, si costruiranno nuovi modi di lavorare. Al momento il Regno Unito sembra guidare il percorso evolutivo ma anche l’Unione Europea e l’Italia vi si dovranno uniformare.

Se vuoi un supporto qualificato sull’argomento puoi contattarmi qui