Il blog di Archicad Italia

Lo standard aperto Industry Foundation Class, più comunemente chiamato IFC, sta assumendo un ruolo sempre più importante all’interno della nostra pratica quotidiana. Seppur non in maniera così approfondita come ci si aspetterebbe, molti progettisti richiedono sempre di più un interscambio e una collaborazione tramite questo formato. Vediamo qui alcuni nuovi aspetti e funzionalità dell’IFC in Archicad. 

Prima di approcciare qualsiasi argomento tecnico, è però doveroso introdurre il tema partendo dagli albori dell’IFC. Dagli avvenimenti storici che hanno portato allo sviluppo del formato fondante la metodologia OpenBIM fino alla sua struttura semantica, in modo da poterne comprendere il linguaggio. Per farlo, seguo buildingSMART International - una fonte che, per qualsiasi figura BIM, dovrebbe essere imprescindibile e necessaria per il corretto utilizzo dell’IFC e per una corretta creazione dei modelli informativi stessi.

Pronti per un tuffo nel passato?

Il formato STEP durante la Guerra Fredda

Comunemente si pensa che l’introduzione del formato aperto IFC sia un evento molto recente. Eppure, tale formato ha una storia molto più lunga di un altro formato aperto a noi molto comune: il Portable Document Format (PDF), il quale risale agli inizi degli anni ’90. 

L’avanzamento tecnologico ha trovato il sua maggiore espansione nel campo militare. Infatti, seppur non ancora denominato e sviluppato per lo scopo attuale, la storia dell’IFC ha origine da un conflitto militare di grande importanza del XX secolo. Dal punto di vista teorico già al tempo si parlava di Building Information Modeling nel settore delle costruzioni, ma il formato STandard for the Exchange of Product model data (STEP), “padre” dell’IFC, nacque durante gli anni della Guerra Fredda. 

Divenuto poi un vero e proprio standard ISO 10303, il formato ebbe origine da aziende coinvolte nella progettazione di apparecchiature militari complesse tramite l’utilizzo dei primi programmi di modellazione tridimensionale. Adottato in tempi brevi anche da compagnie petrolifere e simili, STEP contiene una serie di regole per la scrittura e lo scambio dati fra alcuni dei più importanti sistemi informatici come CAD, CAM e CAE. Un concetto molto simile a quello dell’IFC.

Esempio di struttura dati di un file in formato STEP creato in CATIA.

L'obiettivo del formato aperto era quello di:

• Eliminare qualsiasi errore scaturito da ambiguità e mappature dati derivati da differenti sistemi;
• Avere un formato aperto che consentisse il dialogo a prescindere dal software utilizzato;
• Permettere l'archiviazione dei dati a lungo termine.

Per essere ancora più chiaro, un modello informativo descritto da uno schema dati IFC2x3 o IFC4 presenterà le medesime caratteristiche di utilizzo anche nei prossimi decenni.

La svolta per lo sviluppo dell’IFC avvenne al termine del conflitto quando venne a decretarsi la sconfitta, nel 1991, dell'URSS. La produzione di equipaggiamento militare ebbe un forte arresto a beneficio del settore civile, in cui gli uffici militari riposero la loro attenzione.

I sistemi CAD videro a loro volta diminuire la produzione di modelli tridimensionali per armamenti. Conseguentemente, anche l'interesse per ulteriori sviluppi del formato STEP conobbe un simile andamento. Sappiamo tutti, però, come di lì a poco avvenne la diffusione di alcuni dei sistemi CAD fra i più importanti al mondo.

IFC come formato chiuso?

Il picco di popolarità del formato militare STEP era ormai passato, ma rimase allo stesso tempo un caposaldo della progettazione tridimensionale ancora poco utilizzata nel settore delle costruzioni. Lo stesso formato presentava, come già accennato, una ricca infrastruttura tecnica con specifiche dirette allo standard ISO. Un aspetto non di poco conto che attirò l’attenzione di una particolare casa software dell’epoca.

L’idea fu quella di sviluppare un nuovo formato, anche se non ancora denominato IFC, che prendesse spunto da quanto svolto per il formato STEP e che potesse essere applicato al settore delle costruzioni. In questo modo, riuscirono a risolvere alcune delle più grandi problematiche riguardanti lo scambio di dati ed informazioni. Un’idea di carattere globale declinata in una realtà aziendale chiusa, rese necessario il coinvolgimento di un numero maggiore di professionisti. 

Nel 1994 nacque il formato IFC, così come è conosciuto e diffuso oggigiorno, grazie ad una casa software che presentava intenzioni differenti rispetto alla sua natura odierna. Il suo sviluppo è stato successivamente proseguito da un consorzio che, tramite una rigida guida, ha iniziato ad applicare regole e standard per raggiungere esigenze e obiettivi personali.

Evoluzione del formato IFC nel corso degli anni.

Sulla nascita di una organizzazione che potesse sviluppare il formato IFC in modo aperto e condivisibile ci sono alcune discrepanze storiche, probabilmente sorte a causa di varie vicissitudini commerciali e politiche fra software house e sviluppatori. Una di queste implica una naturale evoluzione del processo, con la nascita di un’organizzazione aperta che avrebbe sviluppato il formato IFC con un approccio Open. In tal modo si avrebbe avuto un apporto maggiore, di carattere mondiale, fondamentale per garantire uno sviluppo continuo nel corso degli anni.  

Fu così che nel 1997 nacque l’organizzazione dell’International Alliance for Interoperability (IAI). Nel 2005 l’IAI divenne l’organizzazione che tutti conosciamo con il nome di buildingSMART International. Resta da evidenziare come Nemetschek Group supportò la nascita di quest’ultima a fronte della recente acquisizione di Graphisoft, e del suo prodotto di punta Archicad, promotore fin dalla sua nascita del concetto di OpenBIM e collaborazione mediante formati aperti.

Infografica della storia di buildingSMART International (vedi la fonte)

Confronto tra STEP e IFC

Contrariamente a quanto si possa immaginare, IFC non è un formato file. Per meglio dire, l’IFC rappresenta anche un formato di file aperto, ma tecnicamente viene definito come uno schema dati che rappresenta gli elementi che possono esistere all'interno di un modello di dati e come questi si relazionano tra di loro. Propriamente sarebbe anche più appropriato parlare di data model come già descritto in uno dei più importanti libri italiani sul tema: IFC - Processi e modelli digitali OpenBIM per l'ambiente costruito.

Il formato STEP viene definito come il “padre” dell’IFC per un aspetto molto importante riguardante lo sviluppo di quest’ultimo. Entrambi i formati, infatti, basano la propria struttura su un linguaggio di programmazione comune.

Lo STandard for the Exchange of Product model data è costituito da diverse parti, ognuna pubblicata separatamente all’interno dello standard ISO 10303. Gli scambi effettivi di dati tra più sistemi sono resi possibili dagli Application Protocols (APs), ciascuno di essi definisce uno standard di scambio di dati per una determinata famiglia di prodotti come: CAD, CAM, CAE. 

Per comprendere la correlazione fra STEP e IFC, e la conseguente importanza degli APs, è necessario introdurre la parte 11 dello standard ISO, denominata EXPRESS, che introduce il linguaggio di programmazione del formato STEP. Questo linguaggio consente la modellazione di dati principalmente per object-oriented e può presentarsi in due tipologie differenti, ma di uguale significato: 

• Lessicale: in cui viene memorizzato in un file ASCII similmente a quanto avviene con i linguaggi di programmazione; 
• Grafica: denominata anche EXPRESS-G, la quale utilizza simboli semantici, similmente a quanto accade nei software di Visual Programming Language come Grasshopper.

Esempi di EXPRESS

EXPRESS viene definito come un linguaggio di schema concettuale che consente di specificare le classi appartenenti a un dominio definito, le informazioni o gli attributi relativi a tali classi (colore, dimensione, forma, ecc.) e i vincoli su tali classi (unico, esclusivo, ecc.). Esso viene anche utilizzato per definire le relazioni che esistono tra le classi e i vincoli numerici che si applicano a tali relazioni. Un classico esempio potrebbe essere quello di specificare quanto segue:

“Classe Muro nel dominio architettonico con le relative informazioni personalizzabili ed attributi nativi, come aree, volumi e GUID (Global Unique IDentifier), relazionata ad una determinata Zona dell’edifico, come ad esempio zona giorno, posizionata sul piano n-esimo dell’edifico di progetto appartenente ad un determinato sito facente parte di un progetto civile.”

La stessa modellazione dati può avvenire in questo modo, sia per via lessicale che per via grafica, con l’eccezione che quest’ultima tipologia non risulta essere completa quanto la prima. Vari codici di linguaggio di programmazione, infatti, non possono essere in alcun modo espressi graficamente in EXPRESS-G.

Il più generico elemento definito attraverso EXPRESS viene chiamato con il termine SCHEMA. Secondo la normativa ISO, uno schema dati definisce la struttura dati e le tipologie di relazioni che sussistono fra i dati stessi. Un insieme di entità, attributi e istanze di tipo relazionali tra oggetti rappresentano in maniera consona uno schema dati come quello dell’IFC.

Di seguito si riportano un esempio di scrittura in EXPRESS per quanto riguarda la classe IfcWall, la quale descrive un elemento murario nel formato IFC.

Esempio di scrittura in EXPRESS per la classe ifcWall

Esempio di scrittura in EXPRESS-G

Sezione tecnica dell’IFC

Conoscere lo schema IFC e saperlo utilizzare nelle varie applicazioni del caso è relativamente semplice rispetto a quanto si possa pensare. BuildingSMART International, infatti, oltre ad aver sviluppato il formato, ha anche predisposto una sezione tecnica dove ogni utente può approfondire i seguenti standard riguardo i dati:

• IFC Specifications Database: vengono specificate le varie classi che compongono lo schema dati;
• IFC Formats: vengono specificati i vari formati rilasciati (ad esempio XML e ZIP) e in via di sviluppo (come ad esempio JSON);
• MVD Database: vengono specificate le varie Model View Definition rilasciate ( ad esempio Coordination View e Reference View) e in via di sviluppo (ad esempio Architectural Design to Building Energy Analysis).

 A disposizione dell’utente vi è anche una sezione tecnica riguardante i seguenti standard per i workflow:

• Information Delivery Specification IDS: viene specificato il nuovo standard che descrive i requisiti di scambio informativo;
• IDM Database: vengono specificati i vari Information Delivery Manual rilasciati o in via di sviluppo;
• BIM Collaboration Format: viene specificato lo standard relativo alla gestione delle problematiche.

Per interrogare lo standard IFC è opportuno recarsi nella prima sezione IFC Specification Database. Sarà possibile poi avere accesso agli schemi di tutte le versioni rilasciate di IFC. Per avere maggiore chiarezza e un confronto pratico con la progettazione odierna, si consiglia di far sempre riferimento all’ultima versione disponibile nell’elenco. Nelle successive righe si prenderà come esempio la versione IFC 4.3.1.0, attualmente in fase di aggiornamento.

Homepage dell’attuale versione IFC in corso di sviluppo.

Nella parte di sinistra della versione presa in considerazione sono presenti vari menu che consentono di accedere alla totalità delle voci dello schema dati o di alcune sue parti. Di seguito vengono definite tre semplici categorie che permettono di accedere alle classi relative alla disciplina architettonica:

• (B) Alphabetical listings: selezionando questa voce è possibile visualizzare tutto l’elenco di classi che compongono lo schema dati. Senza troppe difficoltà sarà possibile trovare la classe desiderata in un lungo elenco di voci;
• (6) Shared element data schemas: selezionando questa voce è possibile visualizzare  classi più specifiche e relazioni condivise da più domini;
• (7) Domain specific data schemas: selezionando questa voce è possibile visualizzare classi organizzate in base ai vari domini del settore delle costruzioni. Un esempio:  IfcArchitectureDomain per la disciplina architettonica.

Interrogare un’entità IFC

In relazione all’ifcWall, precedentemente descritto secondo EXPRESS ed EXPRESS-G, proviamo a comprendere come è strutturata la relativa pagina della classe in questione. I successivi ragionamenti possono essere applicati anche per tutte le altre classi. Ogni pagina di una classe è composta da varie sezioni di cui le più importanti e di nostro interesse sono:

• Semantic definition: in cui ogni classe viene descritta testualmente. Utile per risolvere eventuali dubbi riguardanti la scelta della classe per mappare i componenti costituenti il modello informativo. Questa sezione presenta, inoltre, delle note di vari colori relative a differenti aggiornamenti o rilasci della classe da una versione IFC all’altra;
• Entity inheritance: in cui graficamente viene collocata la classe all’interno dell’albero dati IFC a partire dall'entità stessa fino all’IfcRoot. Una sezione di grande importanza per comprendere in linea di massima come sono strutturate le varie classi e le loro relazioni.

Esempio di struttura ad albero per la descrizione e collocazione di IfcWall.

• Attributes: in cui vengono esplicitati gli attributi standard per ogni classe, ereditati o meno dalle sue classi genitore. Un caso tipico è l’attributo GlobalId, ereditato e comune a tutte le classi a partire dall’IfcRoot. Questa sezione risulta indispensabile per comprendere quali sono le informazioni minime da dover trasmettere per ogni classe senza ricorrere ad eventuali ed aggiuntivi PropertySet. Questi ultimi dovranno essere inseriti per informazioni più specifiche relative al singolo progetto.

Esempio di Attributi ereditati e non di IfcWall.

Di particolare importanza negli Attributi è il PredefinedType che consente di specificare la natura o tipologia della classe mediante un enumerativo, alcuni vengono messi a disposizione all’interno dello schema dati, altri invece possono essere definiti utilizzando l’enumerativo USERDEFINED. Esso consente all’utente di specificare manualmente la tipologia della relativa classe da trascrivere rigorosamente in maiuscolo come per tutti gli altri enumerativi. 

Attribuzione del PredefinedType in Archicad mediante Traduttore IFC.

Nel prossimo articolo entreremo più nel dettaglio in questi aspetti, andando anche a testare l’aggiornamento di alcune funzioni IFC relative alla versione 26 di Archicad.