E’ ormai chiaro, dai primi documenti circolati per lo sviluppo normativo nazionale e internazionale, che il BIM diventerà presto cogente. Da stabilire restano solo le scadenze di tale percorso. Possiamo intanto già segnalare l’importante orientamento che i legislatori stanno adottando, il quale, per altro, come IBIMI abbiamo sempre sostenuto: il BIM sarà OPEN, cioè non legato a software specifici, ma aperto e interoperabile. Il metodo poggerà quindi su formati di scambio dati non proprietari. Tradotto in quella che è l’unica possibilità di oggi, saranno IFC i file da consegnare ai committenti.

In questo post condividiamo le strategie di sviluppo dell’IFC, così come è stato annunciato durante l’ultimo summit internazionale di buildingSMART, l’associazione no profit che si occupa di sviluppare, tra gli altri, lo standard IFC.

IFC 4

L’ultima versione ufficialmente rilasciata del formato IFC è la 4. Questa è stata pubblicata, è online e a disposizione delle software house, che però, nella maggior parte dei casi, non hanno ancora implementato questa versione all’interno dei propri prodotti. Considerando che con questa versione sono stati risolti praticamente tutti i problemi della versione precedente, la IFC 2×3, c’è da chiedersi come mai questo ritardo? Probabilmente la causa va ricercata nel fatto che il sistema di certificazione per l’IFC4 è in fase di “lancio” con la Reference View cominciata appena a Luglio di quest’anno e la Design Transfer View ancora non operativa. La versione è implementabile, ma il rilascio del “marchio” IFC4 spendibile come materiale di marketing dalle software house, oggi ancora non esiste. Visto che lo sviluppo dei propri software richiede comunque investimenti importanti, se non si è certi questo venga riconosciuto dal mercato si preferisce rimandare la spesa. Ma è questione di poco tempo e anche quest’ultima versione verrà implementata in tutti i software del settore.

IFC 5

Con la versione IFC4 si è raggiunto un ottimo grado di maturità per l’interoperabilità delle informazioni edili, ma parliamo esclusivamente dell’ambito edile, quindi building in senso stretto. Si è già cominciato a lavorare alla versione 5, data rilascio prevista 2020, la quale ha l’obbiettivo di ampliare lo scopo del formato dati anche all’ambito civile. L’intenzione è di rendere l’IFC in grado di supportare lo scambio di informazioni geometriche e non geometriche di tutto ciò che riguarda le infrastrutture lineari autostradali e ferroviarie (comprensivo di ponti e tunnel) e le infrastrutture portuali. C’è molto fermento intorno a questo progetto, come IBIMI ci occupiamo di fare il link tra i bisogni dei nostri soci e i gruppi tecnici che lavorano allo sviluppo degli standard. Se sei interessato a partecipare o ad avere più informazioni contattaci.

Certificazione dei Software

Oggi, alcuni software, nonostante riescano ad ottenere la certificazione buildingSMART, non sono performanti al 100% nello scambiare dati, e perdono molte informazioni durante l’import ed export dei modelli. Questo accade perché per la certificazione viene rilasciata sulla base di una valutazione della capacità di leggere (import) o scrivere (export) il formato IFC, che oggi viene effettuata secondo due concetti:

  • Viene esaminata la capacità di scambiare le informazioni di tutte le proprietà che caratterizzano una specifica famiglia di oggetti che il software ha la capacità di creare.
  • Il giudizio ha tre possibili risultati: verde = sopporta lo scambio; giallo = solo in particolari casi o non completamente; rosso = non supporta lo scambio.
Schermata di valutazione per il rilascio della certificazione IFC compliant

La problematica risiede nel fatto che in sede di giudizio finale, la valutazione complessiva del software considera i gialli e i verdi come positivi e solo i rossi come negativi. Così si crea una grossa area di incertezza, infatti per fare un esempio del tutto teorico, un software che ottiene il 90% di verdi potrebbe essere riconosciuto interoperabile alla stregua di uno che ottiene il 50% di verdi e il 40% di gialli. Ma il secondo non garantisce prestazioni adeguate per il grande pubblico che magari poco informato sui tecnicismi dell’interoperabilità conclude che “l’interoperabilità è un utopia”. In realtà, dipende dal software, che in linea di principio permette lo scambio, a patto che la persona che ne fa utilizzo conosca le singole problematiche e sviluppi di volta in volta una soluzione. Se però l’utilizzatore del software non è un “esperto di interoperabilità”, lo scambio con alcuni software semplicemente non riesce.

Va poi considerato che alcune proprietà potrebbero essere meno utili/utilizzate rispetto ad altre, ancora facendo un esempio generico, un rosso sulla proprietà del posizionamento dell’elemento sulla griglia di riferimento è certamente più critico della proprietà di descrizione materiale.

Il problema è stato analizzato e la soluzione individuata è quella di aumentare la “rigidità” del test. I prossimi sistemi di certificazione software daranno risposte solo in termini di verdi contro rossi, eliminando del tutto i gialli. Questo certamente porterà ad una maggiore attenzione da parte delle software house a migliorare la capacità di interoperabilità dei propri prodotti ed in ultimo ad offrire ai professionisti strumenti di più facile utilizzo per rispondere alle richieste della committenza.