26 Mar IFC – Industry Foundation Classes: un PDF per i modelli edilizi

Avete mai provato il disagio di comunicare con una persona che non parla la vostra stessa lingua e non riuscire a capire ciò che sta cercando di dirvi? Ecco, situazioni come questa nascono tutte da problemi di comunicazione, da un linguaggio che non è condiviso.
Diceva Wittgenstein[1], “I limiti del mio linguaggio significano i limiti del mio mondo.”[2] In sostanza, ciò che conosciamo è ciò che riusciamo ad esprimere e ciò che riusciamo a comprendere una volta che ci viene comunicato da altri. Un problema di linguaggio si traduce pertanto in un problema di conoscenza. La mancanza di conoscenza impedisce di affrontare una qualsiasi attività, sia essa concreta o astratta, in maniera efficiente.
Nell’industria delle costruzioni il problema della comunicazione è una questione all’ordine del giorno e presenta due aspetti fondamentali: da una parte l’atavica scarsa comunicazione tra i soggetti coinvolti, spesso troppo preoccupati di proteggere il loro know-how, e dall’altra la difficoltà tecnologica di condividere informazioni in formati universalmente compatibili.
A questo secondo aspetto, in particolar modo, si rivolgono le Industry Foundation Classes (IFC).

Di che cosa stiamo parlando?
IFC è un formato di dati aperto, neutrale ed interoperabile; questa è la definizione che, per quanto tecnica e forse poco chiara ai più, probabilmente meglio descrive che cosa sia IFC. Ed è infatti la stessa definizione che troverete anche nel sito dell’organismo sviluppatore di IFC, buildingSMART[3]. Analizzandola nel dettaglio, essa ci dice che IFC è:

Un formato di dati
A titolo d’esempio, sono formati di dati: .pdf, .dwg, .dxf, .docx, .xlsx, .jpeg, .mp3. Insomma, al pari di quelli elencati, IFC è un sistema di codifica digitale dell’informazione, pensato per la codifica di modelli informativi tridimensionali.

Aperto
Si definisce aperto un formato di dati la cui specificazione tecnica di codifica dell’informazione è stata pubblicata e di conseguenza può essere utilizzata ed implementata da chiunque. Di conseguenza, la scelta degli sviluppatori di software proprietari o open-source di consentire al loro prodotto di leggere/scrivere in formato IFC è prettamente una scelta commerciale, non legata cioè all’impossibilità di sapere come lo standard IFC codifichi l’informazione. Altri formati di file aperti sono ad esempio PNG (immagini), FLAC (audio), HTML (web)[4].

Neutrale
Quando buildingSMART parla di IFC come un formato neutrale, intende dire che il suo sviluppo non è controllato da nessuna società, azienda o ente specifico, in particolar modo non è controllato dalle case produttrici di software. Va però sottolineato che, fra i membri di buildingSMART[5] figurano le principali software house: Autodesk, Nemetschek, Trimble, Dassault Systemes[6]. Per quanto queste aziende siano concorrenti, è chiaro che eventuali osservazioni sul tema della neutralità meritino di essere ascoltate.

Interoperabile
Questa caratteristica è, per la verità, conseguenza delle precedenti. IFC in quanto formato di dati aperto è già attualmente implementato dai principali software BIM e per questa ragione costituisce uno strumento che consente a tutti gli attori del processo di comunicare informazioni tramite un linguaggio comune, che può essere scritto e letto da qualsiasi applicativo proprietario normalmente utilizzato.

In ottica BIM, inteso come metodologia applicata all’intero progetto e quindi a tutte le fasi e a tutte le discipline, il poter fare affidamento su uno strumento di comunicazione che sia comprensibile da tutti gli attori è fondamentale. In questo senso IFC rappresenta una delle fondamenta dell’openBIM, il movimento originariamente avviato dalle case software Tekla e Graphisoft il cui “unico obbiettivo è quello di promuovere flussi di lavoro a collaborazione aperta per ottenere dei progetti meglio coordinati”[7].

Fig. 1 – Logo openBIM.

Alla luce di quanto detto, sarà ora più chiaro il titolo di questo articolo. Per quanto infatti il formato PDF sia un formato proprietario, semplificando si può dire che la finalità primaria che IFC si pone è quella di essere per l’universo BIM-based delle costruzioni quello che il PDF è diventato per i documenti testuali e gli elaborati grafici bidimensionali.

Più di vent’anni di storia
L’idea di IFC nasce addirittura nel 1994, quando venne diffuso un filmato intitolato “The End of Babel”[8], su iniziativa di una serie di aziende capitanate da Autodesk[9]. Partendo dall’episodio biblico della Torre di Babele (fig. 2), a cui si fa mitologicamente risalire la presenza dei diversi linguaggi della Terra, viene evidenziata la necessità di trovare un unico sistema di comunicazione per affrontare la digitalizzazione già all’epoca in corso.

Fig. 2 – Pieter Bruegel il Vecchio, Grande Torre, 1563, olio su tavola, 114x155cm, Kunsthistorisches Museum, Vienna.
La torre di Babele è il soggetto anche di un altro dipinto di Bruegel, la Piccola Torre, conservato nel Museum Boijmans Van Beuningen di Rotterdam.

Da allora IFC si è evoluto progressivamente, aggiungendo Classi[10] e relazioni fra di esse, fino ad arrivare all’ultima release dello standard (IFC4 Add 2[11]). In particolare risale al 2013 la norma ISO 16739 – Industry Foundation Classes (IFC) for data sharing in the construction and facility management industries.

Fig. 3 – Evoluzione dello standard IFC.

Ci sono state sei versioni principali di IFC nel corso della sua storia: IFC 1.5.1, IFC 2.0, IFC2x, IFC2x2, IFC2x3 ed IFC4 (la cui corretta denominazione sarebbe in realtà IFC2x4). Dal rilascio di IFC2x, il core dello standard è rimasto invariato e sono state solamente aggiunte classi e relazioni fra esse, in modo da descrivere scenari via via maggiori ed integrare l’esperienza derivante dall’implementazione dello standard. La garanzia di una base comune fatto sì che le case produttrici di software potessero aggiornarsi alla più recente versione di IFC senza difficoltà. Consultando la più recente versione di IFC via web è possibile notare come, per ogni classe, vengano fornite informazioni sull’evoluzione della classe stessa attraverso le varie versioni dello standard.

Fig. 4 – Organizzazione delle classi di IFC:
Core schema: classi che costituiscono la struttura di base, le relazioni fondamentali e i concetti comuni, e sono necessarie per le successive definizioni specifiche delle diverse discipline (es. IfcActor, IfcTask, ifcElement).
Shared schema: classi che descrivono relazioni e oggetti più specifici, condivisi da diverse discipline (es. IfcBeam, IfcColumn, IfcDoor, IfcFastener, IfcFurniture).
Domain schema: classi che afferiscono a specifiche discipline e che non possono essere ulteriormente specificate da altre classi (es. IfcAlarm, IfcCoil, IfcStructuralAction)
Resource schema: classi di supporto che non possono esistere in maniera indipendente, ma che possono esistere solo in riferimento ad una o più classi degli altri schema (es. .IfcDate, IfcPoint, IfcAddress, IfcMaterial).

L’obbiettivo di IFC è quello di essere in grado di descrivere l’informazione che riguarda il processo edilizio nei suoi ambiti e nelle sue fasi. Per questo motivo l’attività dei capitoli locali di buildingSMART e dei professionisti coinvolti è fondamentale per portare al tavolo di buildingSMART le istanze di modifica o aggiornamento dello standard.
In questo modo IFC potrà davvero diventare, o perlomeno potrà avvicinarsi ad essere, una sorta di “Enciclopedia delle Costruzioni “attraverso cui comunicare l’intera complessità del processo edilizio (fig. 5).

Fig. 5 – Il logo di IFC testimonia l’ambizione dello standard a diventare un linguaggio comune per lo scambio delle informazioni sull’edificio alle varie fasi del processo: procure, design, assemble, operate.

Lo standard IFC prevede oltre al formato .ifc (basato su STEP, ISO 10303-21), anche il formato .ifcXML (basato su XML e normalmente 3/4 volte più pesante di un file .ifc), oltre alla possibilità di comprimere i due formati citati ottenendo un file .ifczip (più leggero del file .ifc di circa il 70%).

Tutto molto bello, ma…
Uno dei principali problemi che evidenziano coloro che utilizzano IFC risiede nell’efficienza delle procedure di import/export del file in formato IFC nel/dal software utilizzato. In altre parole, affinché l’utilizzo di IFC abbia futuro occorre che i software importino ed esportino file IFC senza perdita di informazioni.
A questo proposito, buildingSMART ha istituito un sistema di certificazione dei software rispetto alla loro capacità di “maneggiare” lo standard IFC; sul sito viene riportato l’elenco di tutti i software certificati[12]. Ciascun software viene certificato separatamente per quanto riguarda l’importazione e l’esportazione di file IFC e sempre rispetto ad una specifica Model View Definition (MVD).
In breve, una MVD non è altro che un sottoinsieme di IFC e può essere vista come un filtro alle informazioni contenute in un modello, finalizzato a trasmettere le sole informazioni utili a perseguire un determinato obiettivo. Esiste più d’una MVD ufficialmente pubblicata da buildingSMART, così come esiste COBie, pubblicata dal capitolo americano (buildingSMART Alliance) ma non ancora ufficialmente approvata dal board internazionale. Nel caso delle certificazioni IFC, la MVD utilizzata come criterio è la Coordination View 2.0, ed è la stessa e la sola per tutti i software.
Inoltre, analizzando i report di ciascun software che si possono scaricare dal sito, si nota che la semplice certificazione non assicura un risultato positivo su tutti le voci sulle quali il test si articola. Questo ed il fatto che venga utilizzata una singola MVD impongono di considerare criticamente le certificazioni rilasciata. Insomma, nel software certificato troveremmo senz’altro il comando “importa IFC” od “esporta IFC”, ma non possiamo fare cieco e totale affidamento sulla corrispondenza fra il contenuto del modello nativo e quello del modello importato/esportato.

IFC e l’openBIM: la strada per l’interoperabilità
Infine, tornando al problema della comunicazione nell’industria delle costruzioni dal quale era partita la trattazione, IFC rappresenta una soluzione anche alla questione della conservazione del know how. Un file IFC infatti, proprio come i PDF, costituisce una fotocopia digitale del lavoro svolto, consultabile, ma non modificabile, da chiunque ne venga in possesso.
Il concetto di collaborazione, e quindi di comunicazione, è centrale nel Building Information Modelling. Impostare, nell’ambito del processo edilizio, lo scambio delle informazioni su sistemi interoperabili (come ad esempio IFC) costituisce pertanto una necessità se l’obiettivo è quello di trasformare l’industria delle costruzioni attraverso l’adozione della metodologia BIM. E questa affermazione è ancor più sensata nell’ambito di progetti pubblici, dove non è possibile forzare i professionisti a dotarsi di quello strumento piuttosto che dell’altro.
L’Esperanto, dopo più di un secolo di vita, non ha avuto grande fortuna. Vedremo se per IFC andrà meglio…

Link utili:

www.buildingsmart.org/
www.buildingsmart-tech.org/
www.ifcwiki.org/
www.graphisoft.com/it/soluzioni/open_bim/

Note:

[1] Ludwig Wittgenstein (Vienna, 1889 – Cambridge, 1951) è stato un filosofo, ingegnere e logico austriaco da molti considerato, soprattutto in ambito accademico anglosassone, il massimo pensatore del XX secolo. Alcuni dei suoi contributi più notevoli riguardano il tema della filosofia del linguaggio.
[2] L.Wittgenstein, Tractatus Logico-Philosophicus, 1921, cap. 5.6.
[3] Nata nel 1995 con il nome di International Alliance for Interoperability, buildingSMART ha assunto l’attuale denominazione nel 2008 ed è un’organizzazione no profit che si fonda sui principi di collaborazione e neutralità, operando sul tema dell’interoperabilità e del teamwork nel settore delle costruzioni. buildingSMART si compone di una serie di capitoli nazionali ed internazionali, tra cui quello italiano. buildingSMART è una società no-profit costituita da 24 membri, tra case software, aziende ed enti di vario genere, e da uno Strategic Advisory Council composta da Arup, Autodesk, Trimble, HOK, Kajima, LafargeHolcim e Nemetschek.
[4] Nel mondo delle costruzioni, IFC non è l’unico formato di dati aperto. Esiste infatti il formato gbXML (Green Building XML), specificamente pensato per la trasmissione delle informazioni fra i software di BIM authoring ed i software di analisi energetica. Dal sito www.gbxml.org è possibile risalire ai software che implementano l’importazione/esportazione di questo formato di dati.
[5] www.buildingsmart.org/members/member-directory/
[6] Giusto per dare qualche riferimento, in ambito BIM Autodesk produce, fra gli altri, Revit e Navisworks; al gruppo Nemetschek fanno capo ArchiCAD, Allplan, Vectorworks e Solibri: Trimble è conosciuta soprattutto per Tekla, mentre Dessault Systems produce Catia e SolidWorks.
[7] www.graphisoft.com/it/soluzioni/open_bim/open_bim_program/#faq06
[8] Nel video, il personaggio che vedrete illustrare il tema è James Burke, oggi ottantenne, storico della scienza, presentatore, autore e produttore televisivo nord-irlandese. È famoso in patria per numerosi programmi di divulgazione scientifica andati in onda sulla BBC. (https://www.youtube.com/watch?v=g_jmGQvr6dQ)
[9] Di questo gruppo facevano parte: AT&T, HOK, Honeywell, Carrier, Tishman, Lawrence Berkeley Laboratory, JB&B, Timberline, Archibus/FM, SoftDesk, Primavera.
[10] Il termine Classes all’interno dell’acronimo IFC rivela la struttura logica dello standard, che si basa su una serie di “scatole informative”, per l’appunto le Classi, collegate fra loro attraverso relazioni. Ad esempio un muro, codificato attraverso la Classe IfcWall, viene descritto da uno specifico ID per mezzo di un collegamento fra la Classe IfcWall e la Classe IfcGloballyUniqueId.
[11] www.buildingsmart-tech.org/ifc/IFC4/Add2/html/
[12] www.buildingsmart.org/compliance/certified-software/