Piattaforme interoperabili e formato IFC nei processi BIM
Piattaforme interoperabili e IFC (formati aperti e formati proprietari) nei processi BIM: analizziamo le caratteristiche, le potenzialità e i limiti
Cos’è esattamente il formato IFC e perché esso è così importante per l’introduzione del BIM nel settore delle costruzioni?
Quali sono le caratteristiche, le potenzialità e i limiti di questo formato?
Le possibili risposte a questi interrogativi costituiscono una sorta di “discriminante” in grado di orientare secondo direzioni diverse la modalità con cui la metodologia BIM potrà diffondersi e radicarsi.
E prova ne è il dibattito sviluppatosi a seguito di due distinti eventi occorsi prima della pausa estiva i quali si sono interessati, tra l’altro, anche del formato IFC e del suo utilizzo.
Scheda di decreto BIM
Il primo evento di rilievo è stato la diffusione del testo della bozza del cosiddetto decreto BIM.
Sul sito del Formez, durante lo scorso mese di giugno, il Ministero delle Infrastrutture e dei Trasporti ha reso disponibile il testo dello schema di decreto BIM per sottoporlo ad una fase di inchiesta pubblica, conclusasi il 3 luglio u.s. (ne abbiamo parlato diffusamente in “Obbligo di adozione del BIM, capitolati informativi e formati di interscambio. Le prime osservazioni al decreto BM” e “Dal 2019 BIM obbligatorio. Ecco il decreto BIM” ) .
Tra le numerose osservazioni sollevate durante tale periodo, tuttora visionabili alla pagina web, l’argomento che ha riscosso maggior interesse è risultato essere proprio quello relativo al formato IFC.
Nel testo dello schema di decreto, all’articolo 4 dedicato al tema dell’ ”interoperabilità”, richiamando quanto già indicato nell’articolo 23 comma 13 del Codice appalti, viene specificato che “le Stazioni Appaltanti utilizzano piattaforme interoperabili a mezzo di formati aperti non proprietari”.
Viene poi precisato che “tutti i dati presenti nel processo […] devono essere richiamabili in qualunque fase e da ogni attore durante il processo di progettazione, costruzione e gestione dell’intervento secondo formati digitali aperti e non proprietari, normati […]”.
La sentenza del TAR Lombardia sull’adozione del BIM
La sentenza del TAR Lombardia n. 1210/2017, pubblicata lo scorso 29 maggio, è il secondo evento di rilievo cui si faceva inizialmente menzione.
Tale sentenza rappresenta il primo pronunciamento giurisprudenziale in Italia relativo ad un appalto pubblico in cui, pur non essendo richiesta obbligatoriamente l’adozione del BIM, erano previste delle clausole premianti per i concorrenti che avessero eseguito la progettazione con tale metodologia.
Senza entrare nel merito del contenzioso e nei contenuti del dispositivo (è possibile prendere visione della sentenza alla pagina web del sito giustizia amministrativa) particolarmente rilevante è apparsa la seguente frase, inserita nel testo della sentenza:
“Per la verifica dei contenuti del modello BIM si è deciso di lavorare direttamente sul file nativo […] poiché è noto dalla letteratura nazionale e internazionale che in fase di esportazione del file in formato IFC è possibile che una parte, a volte anche significativa dei dati, possa andare perduta”.
In risposta a tale affermazione è seguita una nota ufficiale di “BuildingSMART Italia” (pubblicata sul relativo sito) in cui, precisando di non avere l’intenzione di entrare nel merito della sentenza ma esclusivamente della frase precedentemente riportata, l’Organizzazione si preoccupa di formulare alcune considerazioni che riportiamo nel seguito testualmente.
A tal proposito BuildingSMART Italia dichiara quanto segue:
Citando la letteratura nazionale ed internazionale, sarebbe anche opportuno precisare di cosa si sta parlando; non risulta infatti nessuna pubblicazione che argomenti il tema della perdita di dati nell’esportazione di un file in formato UNI EN ISO 16739:2016 (IFC)
Il formato UNI EN ISO 16739:2016 (IFC) è uno schema concettuale, un formato di scambio dei dati in grado di supportare, nel momento in cui si sceglie di esportare in questo formato, tutte le proprietà, anche quelle non presenti nello standard. La perdita di dati, quindi, può unicamente dipendere dai differenti meccanismi attraverso i quali i software di authoring scelgono quali proprietà includere o non includere nell’esportazione e come le proprietà interne di detti strumenti sono messe in correlazione (mappate) con le proprietà IFC
Emerge a questo punto, con evidenza, la necessità di precisazioni e chiarimenti in merito al formato IFC:
Che cos’è l’IFC? A che serve? E cosa è possibile aspettarsi da esso?
Formati aperti e formati proprietari
Di IFC avevamo già parlato da queste pagine (vedi “ BIM e IFC: l’interoperabilità dei software e il BuildingSmart International ” e “ IFC, cos’è e quali sono i vantaggi ”, a cui rimandiamo per ulteriori informazioni di carattere generale e concettuale) ma ci appare ora più che mai necessario precisarne alcuni aspetti operativi partendo, anzitutto, dal chiarire cosa significhi “formato aperto non proprietario”.
La UNI 11337-1, riporta le seguenti definizioni:
- Formato aperto – Formato di file basato su specifiche sintassi di dominio pubblico il cui utilizzo è aperto a tutti gli operatori senza specifiche condizioni d’uso.
- Formato proprietario – Formato di file basato su specifiche sintassi di dominio non pubblico il cui utilizzo è limitato a specifiche condizioni d’uso stabilite dal proprietario del formato
In maniera concorde, ma forse maggiormente esplicita, è possibile rintracciare facilmente sul web le seguenti descrizioni:
- Un formato aperto, in informatica, indica una specifica tecnica di pubblico dominio, utilizzata per la descrizione e l’archiviazione di dati digitali libera da restrizioni legali per il suo utilizzo
L’obiettivo principale dei formati aperti è garantire l’accesso ai dati nel lungo periodo senza incertezza presente e futura riguardo ai diritti legali o le specifiche tecniche (interoperabilità).
Un secondo obiettivo comune dei formati aperti è di incoraggiare la concorrenza invece di consentire a un solo produttore di mantenere il controllo su di un formato proprietario per inibire l’uso di prodotti concorrenti.
- I formati proprietari, a differenza dei formati aperti, sono controllati e definiti da interessi privati (ed hanno, in genere, misure di restrizione o vincoli nell’utilizzo).
Può capitare che un utente possa perdere tutte le informazioni contenute in un formato proprietario se l’unico software proprietario in grado di operare correttamente con tali dati non è più reso disponibile.
Occorre, inoltre, precisare anche la differenza tra formato proprietario o non proprietario e formati aperti o chiusi.
Il formato MP3, ad esempio, è un formato proprietario ma è anche un formato aperto perché, benché brevettato, le sue specifiche sono pubbliche.
La pubblicazione della specifica tecnica è un modo per diffondere il formato, necessario per far diventare un formato uno standard internazionale. Ad esempio, la pubblicazione è un requisito per ottenere una qualifica ISO ed essere riconosciuto come standard internazionale.
Un formato proprietario aperto può essere diverso da un formato open-source, perché il primo può essere modificato solamente acquistando un programma proprietario, mentre i formati open-source possono essere sia letti che modificati da qualunque applicazione.
Da quanto detto emerge la grande valenza del formato IFC: l’indipendenza del dato dal formato del file in cui esso viene memorizzato e veicolato.
Infatti l’adozione di un formato proprietario legherebbe la fruizione dell’informazione al programma che lo ha prodotto: ciò significa che il cambiamento di versione del software o, peggio, la scomparsa dal mercato della software house che lo ha realizzato, renderebbe illeggibili (e quindi persi per sempre) i dati memorizzati nei file conservati, ad esempio, in un archivio comunale.
Tutte le informazioni raccolte negli archivi pubblici (comuni, province, regioni, ministeri, ecc.) diverrebbero inutilizzabili in tempi molto rapidi.
Ora a chiunque, in veste di cittadino o nell’esercizio della propria attività professionale, sarà capitato di dover andare a ritroso nel tempo su una qualsiasi pratica edilizia: la presenza di incartamenti, magari dimenticati in qualche archivio polveroso, ha comunque consentito il superamento di incertezze e difficoltà.
Appare, pertanto, decisamente un azzardo pensare di utilizzare file in formato proprietario poiché essi, non essendo pubbliche le relative specifiche, non possono offrire garanzie circa la disponibilità nel tempo delle informazioni veicolate.
Per contro perché un file IFC potrebbe offrire una versatilità simile a quella dei supporti cartacei prima citati?
Vediamo, allora, com’è fatto un file IFC.
Procuriamoci un file in formato “.ifc”, ad esempio relativo a un modello BIM architettonico (vedi Figura 1).
Proviamo a rinominarlo, modificandone l’estensione in “.txt”, e apriamolo, poi, con un qualsiasi editor di testo (come “Blocco note” di Microsoft, presente in tutte le versioni di Windows): quello che vedremo sarà quanto proposto in Figura 2.
Figura 2 – Contenuto del formato IFC
Si tratta di un elenco di parametri (proprietà) non solo geometrici, organizzati per oggetti e logicamente strutturati, corredati dal relativo valore e perfettamente leggibili.
Un file IFC, allora, può essere facilmente letto direttamente (come file testo) o visualizzato anche graficamente con un semplice BIM viewer gratuito e in grado di supportare file di grandi dimensioni.
Questo è il motivo per cui è possibile affermare che un file IFC consente di trasferire efficacemente informazioni tra i differenti attori di un processo edilizio che decidessero di scambiarsi tra loro tali file.
Il corretto impiego di un file IFC
Ma quali sono i limiti, se ve ne sono, di un formato IFC?
In realtà, le caratteristiche del formato IFC possono risultare limitative in ragione di un uso non in linea con gli scopi per cui esso è stato realizzato.
Infatti il salvataggio di un modello BIM in formato IFC, se correttamente effettuato dal software di authoring, consente il trasferimento di tutte le informazioni contenute nel modello stesso (anche quelle non previste nello standard) ma non l’esportazione degli oggetti, di cui esso è costituito, in forma parametrica.
In altri termini, dal punto di vista grafico, gli oggetti costituenti il modello vengono esportati come “blocchi” visualizzabili e ancora correlati alle rispettive informazioni assegnate nel software che li ha generati, ma non più modificabili parametricamente. E questo risulta essere in linea con l’utilizzo proposto da buildingSMART International, l’ente senza scopo di lucro che a livello internazionale ha sviluppato e manutiene il formato IFC, occupandosi anche di verificare la conformità a tale formato dei file IFC prodotti dalle software house che ne facciano richiesta, rilasciandone, nel caso, apposita certificazione.
L’uso appropriato del formato IFC, come è possibile leggere anche sul sito di buildingSMART International, è consentire una comunicazione unidirezionale tra gli autori dei vari modelli. Questo è chiaramente visualizzato anche nella nota immagine in figura 3, in cui si evidenzia come dal modello di ciascuna singola disciplina si generi un “transfert” (modello in formato IFC) che unidirezionalmente si dirige verso l’area di competenza delle altre discipline.
Figura 3
Sarà così possibile “mettere insieme” i vari modelli per l’effettuazione del coordinamento o utilizzare il modello salvato in formato IFC di una certa disciplina (ad esempio il modello architettonico) come riferimento per produrre il modello di un’altra disciplina (nell’esempio potrebbe trattarsi del modello strutturale o quelli relativi agli impianti), o utilizzare il file IFC definitivo di una progettazione come un vero e proprio archivio da consegnare alla committenza.
Ma queste caratteristiche del formato IFC non devono essere sentite come una limitazione!
L’alternativa, infatti, non potrebbe che essere un formato aperto non proprietario (IFC, ecc.) tale da comprendere tutte le funzionalità di tutti i vari software di authoring presenti sul mercato.
E non solo: occorrerebbe che questi ultimi bloccassero la propria evoluzione affinché questo ipotetico formato non proprietario onnicomprensivo possa risultare efficace per tutti i software proprietari e indefinitamente nel tempo.
In altri termini occorrerebbe bloccare definitivamente lo sviluppo della tecnologia nel mondo!
È evidente che tutto questo è improponibile e, soprattutto, assolutamente non auspicabile.
A questo punto si comprende meglio perché consentire la compresenza di file in formato proprietario e non proprietario negli appalti pubblici probabilmente non sia la strada più opportuna: chi si aggiudicherà l’appalto, dovrà scegliere se partire da una tipologia di file o dall’altra, finendo molto probabilmente con l’utilizzare file derivanti da software commerciali, certamente più ricchi di funzionalità in continua evoluzione.
Ma così facendo la Pubblica Amministrazione molto probabilmente finirebbe col ritrovarsi archivi di file dati i cui reali proprietari saranno le aziende che hanno sviluppato i software di authoring da cui detti file sono prodotti. E delle distorsioni che ne conseguirebbero abbiamo già detto prima ampiamente.
Si tratta, dunque, anche sotto questo aspetto, di un cambiamento del nostro modo di lavorare con strumenti tecnici nuovi a cui dovremo abituarci, ripensando le consuete prassi operative per adeguarle ad essi.
