Un modello architettonico può essere perfettamente costruito nel software che lo ha generato e diventare difficile da utilizzare appena viene condiviso con uno strutturista, un impiantista, un computista o l’impresa. È qui che il confronto tra IFC aperto vs formato proprietario smette di essere teorico: riguarda la continuità del dato, le responsabilità di progetto e la capacità dello studio di lavorare con interlocutori diversi senza ricostruire informazioni.
La contrapposizione, però, non va letta come una scelta assoluta tra formato “giusto” e formato “sbagliato”. I formati proprietari sono fondamentali per produrre, modificare e gestire un modello nel suo ambiente nativo. L’IFC è essenziale per scambiare informazioni in modo leggibile da piattaforme differenti. La qualità del processo BIM dipende da come queste due esigenze vengono governate.
IFC aperto vs formato proprietario: la differenza operativa
Un formato proprietario è sviluppato e controllato da uno specifico produttore software. Conserva in modo completo le logiche interne dell’applicazione: parametri, famiglie o oggetti, relazioni, viste, regole di modellazione, funzioni di calcolo e dati utili alla modifica del progetto. È quindi il formato più efficace quando un team lavora nello stesso ecosistema applicativo e deve mantenere la massima ricchezza informativa durante la progettazione.
L’IFC, acronimo di Industry Foundation Classes, è invece uno standard aperto per lo scambio dati nel settore delle costruzioni. Il suo obiettivo non è replicare ogni caratteristica del software di origine, ma rappresentare in modo strutturato gli elementi edilizi, le loro proprietà, le relazioni e la collocazione nel modello. Un muro, una porta, un pilastro, uno spazio o un impianto possono così essere interpretati da software differenti, a condizione che esportazione e importazione siano configurate correttamente.
La differenza sostanziale è questa: il file nativo tutela la continuità di lavoro all’interno di un’applicazione, mentre l’IFC tutela la continuità informativa tra applicazioni e soggetti diversi. In un processo reale, non sono alternative incompatibili. Sono due livelli del flusso documentale, con finalità distinte.
Perché l’IFC è centrale nei processi BIM
Il BIM non coincide con la modellazione tridimensionale. È un metodo di gestione delle informazioni lungo il ciclo di vita dell’opera, nel quale discipline, committente, progettisti, impresa e gestori devono poter condividere dati affidabili. In questo scenario, un formato aperto riduce la dipendenza da una singola piattaforma e rende più praticabile la collaborazione tra soggetti che utilizzano strumenti diversi.
L’IFC assume un ruolo particolarmente rilevante nelle commesse in cui il capitolato informativo, il piano di gestione informativa o le richieste della stazione appaltante definiscono consegne aperte e verificabili. Può essere utilizzato per il coordinamento federato, il controllo delle interferenze, la consultazione del modello, l’estrazione di quantità e la conservazione di una base informativa non vincolata alla disponibilità futura di una specifica licenza software.
Questo non significa che un IFC sia automaticamente affidabile solo perché porta l’estensione corretta. Un export incompleto può trasformare oggetti parametrici in geometrie poco leggibili, omettere classificazioni, perdere proprietà o assegnare in modo errato le entità IFC. La vera interoperabilità si misura sulla capacità del file di rispondere agli usi informativi richiesti, non sulla sola possibilità di aprirlo.
Il valore della neutralità del dato
Un formato aperto permette a committenti e organizzazioni di mantenere accessibili le informazioni di progetto nel tempo, anche se cambiano software, fornitori o configurazioni operative. Questo aspetto è decisivo per patrimoni immobiliari, interventi pubblici, progetti di lunga durata e realtà che collaborano con una filiera ampia.
La neutralità non elimina la necessità di definire regole. Al contrario, richiede maggiore disciplina: convenzioni di nomenclatura, classificazioni condivise, proprietà obbligatorie, livelli di sviluppo e informazioni, responsabilità di compilazione e procedure di controllo. Senza questi presupposti, l’IFC può diventare un contenitore formalmente corretto ma poco utile per chi lo riceve.
Quando il formato proprietario resta la scelta più efficiente
Nelle fasi di produzione, il formato nativo conserva un vantaggio concreto. Permette di intervenire sul modello senza conversioni, mantenere le funzionalità specifiche dell’applicativo e lavorare con librerie, automatismi e documentazione collegata. Per il progettista autore del modello, questa continuità è spesso indispensabile.
Pensiamo a uno studio che sviluppa un edificio complesso con oggetti personalizzati, dettagli costruttivi, abachi, regole parametriche e tavole strettamente collegate alla modellazione. Trasferire quotidianamente il lavoro da un formato all’altro può introdurre rallentamenti e rendere più difficile il controllo delle revisioni. In questi casi il formato proprietario è il luogo di authoring, cioè l’ambiente nel quale il modello viene creato e aggiornato.
Il limite emerge quando il file nativo diventa l’unica modalità di consegna e collaborazione. Gli altri soggetti potrebbero non avere lo stesso software, la stessa versione o le stesse estensioni. Potrebbero inoltre poter visualizzare il modello senza riuscire a verificarne i dati in modo indipendente. Affidare l’intero progetto a un unico formato può generare dipendenza tecnologica e costi non previsti lungo la filiera.
I punti critici dello scambio IFC
L’IFC non è una copia perfetta del modello nativo. Alcune informazioni devono essere mappate dal software di authoring verso classi, property set e relazioni previste dallo standard. Il risultato dipende dalle capacità dello strumento, dalle impostazioni di esportazione e, soprattutto, dalla qualità con cui il modello è stato costruito.
Le criticità più frequenti riguardano oggetti modellati in modo generico anziché classificati correttamente, proprietà non standardizzate, elementi complessi esportati come semplici geometrie e incoerenze tra classificazioni disciplinari. Anche la scelta della versione IFC e del Model View Definition, quando prevista dalla commessa, va affrontata con attenzione: non tutti gli scambi hanno lo stesso scopo e non tutti richiedono il medesimo livello di dettaglio.
Un errore ricorrente è esportare l’IFC solo alla fine, poco prima della consegna. A quel punto eventuali problemi di struttura dati possono richiedere correzioni onerose. È più efficace pianificare verifiche periodiche fin dalle prime fasi progettuali: esportare, controllare in un visualizzatore indipendente, confrontare quantità e proprietà, rilevare anomalie e correggere il modello sorgente. Il controllo deve avvenire sul processo, non solo sul file finale.
Come scegliere senza creare un falso aut aut
La domanda utile non è “IFC o formato proprietario?”, ma “quale informazione deve essere prodotta, scambiata, verificata e conservata in ogni fase?”. La risposta dipende da commessa, ruoli, software coinvolti e requisiti contrattuali.
Per impostare una strategia efficace conviene chiarire quattro aspetti prima di modellare:
- quali elaborati e dati devono essere consegnati, e in quale formato;
- quali soggetti devono poter leggere, modificare o verificare il modello;
- quali proprietà sono necessarie per coordinamento, computo, gestione o conformità;
- con quale frequenza verranno prodotti e controllati gli scambi IFC.
Da queste decisioni deriva un flusso equilibrato. I progettisti operano nei formati nativi più adatti alla produzione disciplinare; il coordinamento avviene mediante modelli federati e file IFC controllati; la documentazione è gestita in un ambiente comune di condivisione dati con versioni, stati di approvazione e tracciabilità chiari. Non serve imporre lo stesso software a tutti, ma serve imporre regole condivise sui dati.
Il ruolo di formazione e configurazione
L’interoperabilità non si ottiene installando un nuovo programma o attivando un comando di esportazione. Richiede competenze nella modellazione informativa, nella classificazione degli oggetti, nella gestione delle proprietà e nella verifica dei modelli. Richiede anche configurazioni coerenti con gli standard aziendali e con i requisiti della singola commessa.
Per studi e imprese che stanno strutturando il proprio workflow, l’affiancamento tecnico può evitare due estremi: il modello ricco ma chiuso nel proprio software e l’IFC formalmente esportato ma povero di significato operativo. Cadline Software supporta questo percorso combinando strumenti BIM, formazione e assistenza orientata ai flussi di lavoro effettivi, dalla modellazione alla condivisione del dato.
La scelta migliore, quindi, non è rinunciare ai vantaggi del formato proprietario in nome dell’apertura, né trattare l’IFC come una semplice formalità di consegna. È progettare un processo in cui il dato nasca correttamente, resti produttivo per chi lo crea e sia utilizzabile da chi deve coordinarlo, verificarlo o gestirlo. Quando questa continuità è definita prima della produzione, l’interoperabilità diventa un risultato misurabile del progetto, non una promessa affidata all’ultimo export.
