Obbligo dei formati aperti per la modellazione digitale, uso cosciente

Con l’introduzione della modellazione digitale è ritornata alla ribalta una criticità, in vero mai totalmente risolta, in riferimento alla garanzia di trasparenza, integrità e completezza dei dati, e trasmissione degli stessi, indipendentemente dallo strumento/linguaggio informatico che li ha prodotti o li sta gestendo e conservando.

Questa garanzia di completezza ed integrità del dato è ovviamente garantita, dai software che usano linguaggi proprietari, solo all’interno del proprio mondo. Mentre lo stesso linguaggio proprietario, nel dialogo con terzi, diviene una evidente barriera naturale alla trasparenza e trasmissione delle informazioni verso software e sistemi informativi che utilizzino linguaggi da esso differenti. Le case software rispondono in genere a queste criticità mantenendo il proprio linguaggio, all’interno, e adottando poi sistemi di trasferimento aperti verso l’esterno. Conversione in linguaggi aperti.

Il linguaggio aperto, in genere, garantisce l’integrità del dato ma non sempre la piena operatività sullo stesso mediante un specifico software, a meno di una riconversione nel linguaggio proprietario di quest’ultimo, o l’uso di specifici software di modifica puntuale.

Il tipico esempio è rappresentato dai programmi di videoscrittura e l’uso di formati

  • aperti senza regole di composizione come *.txt;
  • aperti con conservazione delle regole di composizione come *.rtf;
  • aperti con garanzia di integrità del dato e della composizione come *.pdf.

Ciascuno di essi è utile ad uno scopo fondamentale: garantire la lettura – aspetto preminente dei sistemi aperti - ma presenta ovvi limiti di utilizzo per altri scopi. Nella prassi comune dell’uso della videoscrittura, viene inviato un documento scritto in formato proprietario/aperto, come “*.docx”, o aperto, come “*.rtf”, entrambi modificabili, cui viene allegata una copia in formato sempre aperto ma non modificabile (se non con appositi strumenti ma in modo molto meno efficiente) in formato “*.pdf”.

Formato aperto quest’ultimo: *.pdf, a cui, in pratica, delego la garanzia di trasferire, non tanto la possibilità di rielaborare il mio prodotto, ma la sua“immagine” (statica), l’immagine dei miei desiderata, in termini quantitativi e qualitativi. Si mantiene lo scopo principale di garanzia di lettura, cui si lega un secondo scopo non, meno importante, di garanzia di integrità (rispetto all’originale) dell’informazione da trasferire.

uso-ifc-pavan-1.JPG
Figura 1 - Schema formati proprietari ed aperti dei software di videoscrittura

Nel mondo CAD-AEC (Computer Aided Design - Architecture, Engineering and Construction) questa criticità (di leggibilità ed integrità del contenuto) nel trasferimento dei dati era superata nella prassi corrente dalla diffusione nel mercato di un formato proprietario (DWG, Autodesk) divenuto, esso stesso, standard di fatto. Formato proprietario prevalente letto e scritto da tutti gli altri software concorrenti. Ciò ha ovviamente dato, negli anni, uno significativo vantaggio competitivo alla casa software proprietaria di quel linguaggio, a svantaggio delle restanti case che, si sono comunque create una loro nicchia di mercato, dovendo altresì garantire, nel contempo, alla propria utenza la piena compatibilità col formato proprietario dominante (DWG).

uso-ifc-pavan-2.JPG
 Figura 2 - Schema formati proprietari ed aperti dei software CAD

Con l’introduzione del BIM (Building Information Modelling), nel mondo AEC, si ripropone oggi la stessa criticità avuta con il CAD. Al fine di evitare rendite di posizione (come appunto avvenuto nel CAD), che possano limitarne il progresso, l’evoluzione, il problema della trasmissione e lettura dei dati, indipendente dal software in uso, è stato in questo caso affrontato sin dal suo nascere, prima della diffusione del BIM stesso nei mercati, ed ha trovato una sua soluzione nell’uso del linguaggio aperto IFC (Industry Foundation Classes), promosso dall’organizzazione Building Smart International (ex IAI, International Association for Interoperability, fondata, tra gli altri, nel 1985, anche da Autodesk).

Il formato IFC,per la trasmissione di modelli grafici (UNI 11337- :2017; quelli prodotti mediante software di BIM authoring), rappresenta oggi l’unica certezza informativa “aperta”, e consolidata, cui la filiera può far utile riferimento.

Il formato IFC è uno standard internazionale (UNI-EN-ISO 16793:2016) e garantisce, appunto, la lettura “aperta” delle geometrie degli oggetti (informatici) come nessun altro linguaggio oggi disponibile. Geometrie e attributi informativi ad esse collegati secondo l’ontologia IFC.

La garanzia di trasmissione e di conservazione del dato, nel tempo, quindi, è assicurata attraverso l’uso di formati aperti non proprietari, nel BIM così come in ogni altro sistema informativo. Per il BIM il linguaggio aperto oggi più solido è il formato standard IFC.

uso-ifc-pavan-3.JPG 
 Figura 3  -Schema formati proprietari ed aperti dei software di BIM authoring

Se l’ineludibilità dell’obiettivo di utilizzare file aperti è indiscutibile, a garanzia dell’utente e del mercato, fermarsi a farne una mera questione di principio, come spesso è avvenuto nel mondo BIM nei confronti di IFC, però, senza comprenderne emigliorarne i possibili limiti di utilizzo esistenti, come è invece avvenuto per altri formati aperti in altri settori, ne decreta oggi i limiti di utilizzo reale e, nel futuro, il possibile sottoutilizzo se non addirittura l’abbandono.Se non adeguatamene sostenuto, aggiornato o reso performante verso vecchie e nuove esigenze, il formato aperto (IFC) verrà superato dalla velocità del mercato (come già avvenne nel CAD).

Perché, miopi alle esigenze dell’utenza, si è stati più attenti ad imporne l’obbligo, per legge, piuttosto che favorirne l’efficienza ed efficacia dell’uso.

IFC presenta oggi ambiti e campi di applicazione ben definiti, non dichiararlo o sottacerlo lo fa sembrare limitato verso esigenze che sono reali per l’utenza ma ancora non del tutto risolvibili in questo ambito e con quello strumento.

uso-ifc-pavan-4.JPG
Figura 4 – Immagine tratta da presentazione di Arto Kiviniemi (2016)

Voler diffondere un linguaggio, fino all’obbligo di utilizzo, senza che esista un testo (oltre la norma volontaria) che lo illustri o che ne definisca, esemplifichi, l’applicazione, ai vari livelli, è perlomeno strano, a meno che non lo si voglia, in vero, relegare mero strumento di “traduzione”informatica o, peggio ancora, ad arma impropria di battaglia commerciale (uso “politico” del formato aperto – a prescindere dalla sua performance - come grimaldello per scardinare posizioni dominanti di altri).

I problemi non sono di IFC ma di come viene usato, divulgato e scarsamente innovato verso le quotidiane esigenze di mercato.

Oggi l’amministrazione pubblica, che impone l’IFC nel BIM per decreto (Dlgs 50/2016, DM 560/2017), consente o addirittura richiede, nello stesso procedimento o appalto, invece, il deposito di ogni altra tipologia di file (non “BIM”), direttamente nel suo formato proprietario (DWG, Excell, Primus, STR, ecc.), assolutamente incurante dei formati aperti. Formato proprietario al più accompagnato da una sua copia in formato aperto PDF (esso stesso ex linguaggio proprietario di Adobe, oggi standard– aperto - ISO).

La stessa pubblica amministrazione che (al suo interno e verso l’esterno nella maggioranza dei casi in cui non chiede un deposito ma intende dialogare/operare con soggetti esterni) non usa, richiede, impone, i formati aperti: *.rtf, *.txt, *xml, ecc., ma trasmette e pubblica file nei formati proprietari che essa stessa utilizza al proprio interno. Senza nemmeno porsi il problema della proprietà o meno dei formati.

Cosi come, ad esempio, negli appalti di lavori o servizi AEC, richiede che i modelli grafici (rigorosamente in formato aperto IFC), siano poi depositati, assieme ad ogni altro dato e file, in appositi Data Base di gestione informativa curati dall’aggiudicatario, dei quali, però, si scorda di chiedere: linguaggio, struttura e architettura. Indispensabili per gestire il sistema inseguito al deposito ed integrarlo nelle propria struttura dati di partenza (sistema informativo della Stazione Appaltante). Confondendo il “DB” necessario ai fini BIM (CDE/ACDat, ambiente di condivisione dei dati; UNI 11337:2017) con un banale repository di file (un ftp – file transfer protocol - magari un filo più evoluto).

Si innalza la bandiera dei formati aperti senza chiedersi perché lo stesso principio non lo si applichi quotidianamente al di fuori del BIM in ogni altro atto della P.A. E chi ne fa le spese, paradossalmente, è proprio IFC che viene ad essere demonizzato, dagli operatori, anziché venire impiegato con maggior profitto e beneficio per tutti.

D'altronde lavorereste mai con qualcuno ad un libro avendo come vincolo l’uso del solo formato aperto, non modificabile, PDF? Ovvio che no. Lavorereste in formato proprietario, e fra di voi al più in *.rtf, nel caso non usaste lo stesso word-processor, e poi, solo in fine, depositereste all’editore, comunque, sia il formato proprietario, o al massimo *.rtf, sia, per sicurezza di integrità, il formato PDF (aperto non modificabile). Magari firmato digitalmente per assicurare la paternità del testo.

A cosa ti serve il modello “aperto”? In quale fase e per quale uso ed obiettivo? Le tue esigenze sono coperte dalla Model View Definition (MVD) della versione di IFC che hai richiesto?

  • IFC Model View Definition:
  • IFC 4 Reference View;
  • IFC 4 Design Transfer View;
  • IFC 2x3 Coordination View (V2.0);
  • IFC 2x3 Structural Analysis;
  • IFC 2x3 BasicFM HandOver view.

Nascondere la testa sotto la sabbia non aiuta IFC lo fa invece sembrare inadeguato. Cosa che nessuno direbbe per il PDF, che nessuno mette in discussione, per quello che fa e sa fare. Perché risulta chiaro al mercato ed agli utentiil suo scopo, poco o tanto che sia,e nondesta fraintendimenti o false speranza. Oggi ciò è altrettanto vero per IFC?

uso-ifc-pavan-5.JPG
 Figura 5 - Definizione di obiettivi ed usi del modello grafico in formato aperto IFC

La pubblica amministrazione nel richiedere, giustamente, un modello in formato aperto è conscia di ciò che questo comporta in termini di flusso delle attività conseguenti? Che non devono limitare l’uso dei formati aperti ma essere compiutamene valutate in termini di tempi, costi e risorse da impiegare sia per i terzi (aggiudicatari) che per la PA stessa (stazione appaltante). Non si può imporre il BIM per la trasparenza dei dati e poi non essere trasparenti nei, o coscienti dei, processi conseguenti.

Prendiamo ad esempio due passaggi critici del processo delle costruzioni:

  • aggiornamento del modello di progetto “esecutivo”durante la fase di esecuzione dei lavori (anche senza varianti) fino alla conclusiva produzione del modello “as-built”;
  • aggiornamento del modello di “as-built” in fase di esercizio (per il naturale ciclo di vita degli elementi suoi componenti) fino alla produzione e conservazione di un modello di “gestione” (o di “esercizio”, appunto).

Consideriamo, per semplicità, la sola documentazione di appalto legata ai modelli grafici: gli elaborati digitali estrapolati dai modelli (escluso ogni altro elaborato) ed i modelli stessi.

Il modello del progetto esecutivo, nell’appalto pubblico, non identifica marca e modello dei prodotti componenti (art. 68, c 6, Dlgs 50/2016). L’impresa, per il suo intervento (costruzione, recupero, ecc.), riceve dalla Stazione Appaltante un modello in formato IFC e gli elaborati grafici e documentali di accompagnamento, estrapolati dal modello proprietario, in formato PDF. Nel proprio modello costruttivo, essa,dovrà inserire il prodotto componente scelto per la tipologia di lavoro appaltato sulla base dei requisiti definiti nel progetto esecutivo. Non si parla di varianti, quindi, ma di semplice, naturale, affinamento dei dati genericidel progetto esecutivo (prodotto generico, privo di marca a tipo) con i dati specifici del prodotto industriale definitodall’impresa,in fase di esecuzione, e accettato dalla Stazione Appaltante.

Ora se si dispone di un vero ambiente di condivisione dei dati (ACDat, UNI 11337-5:2017), e non di un mero repository di file, e la scelta dell’impresa comporta il solo aggiornamento di attributi non geometrici, essa può (potrebbe) agire direttamente sul modello di dati legato al modello IFC e aggiornarne gli attributi informativi (LOI) relativi agli oggetti– digitali - già presenti.

>>> per continuare nella lettura scarica il pdf