Il blog di Archicad Italia

Siamo giunti all'ultimo approfondimento della serie di articoli dedicati alle sfide del restauro e della gestione di edifici storici. Giunto a questo punto, hai acquisito già molte conoscenze, tante delle quali fondamentali per poter affrontare l'ultimo degli ostacoli più significativi: oggi imparerai alcune strategie per affrontare la semantica.  

Conosci l'importanza del patrimonio informativo?

Ed eccoci finalmente arrivati all’ultima tappa del nostro breve viaggio introduttivo nel mondo dell’hBIM. Come ti avevo promesso, oggi parleremo un po’ meno di patrimonio storico e un po’ più di patrimonio informativo. Non è un caso che per entrambe queste espressioni comuni si utilizzi lo stesso termine di origine latina. Pater Munus è infatti, allo stesso tempo, il compito e il dono dei padri. Si presuppone, cioè, che ciò che giunge in eredità alla nostra generazione sia responsabilità morale e sociale di chi ci ha preceduto, ma anche e soprattutto un regalo inaspettato di cui ringraziare. In questo senso, il patrimonio storico è, in effetti, il lascito, ricchissimo e generoso, che ci hanno concesso i grandi maestri del passato e che diventa nostra responsabilità conservare e trasmettere per il futuro. Ma vale anche per il patrimonio informativo che è, appunto, ancora una volta, nostro compito elaborare e consegnare sotto forma di eredità digitale per le generazioni che ci seguiranno e dovranno trasformarlo. Se ci pensi questo è precisamente il principio fondativo di qualsiasi processo BIM e non può che esserlo anche, a maggior ragione, per qualsiasi processo hBIM, che sia quindi espressione di un duplice patrimonio, costruito e virtuale.

In quest’ultimo articolo affronteremo quindi la gestione informativa del contesto Heritage, forse il tema più importante rispetto alla responsabilità digitale dell’intero processo e dei suoi obiettivi, anche se apparentemente il più trascurato e sottostimato. Perché per arrivare a parlare di dati è necessario prima avere completato gli elementi del modello, ossia il contenitore in cui queste informazioni saranno allocate. E perché siano completati gli elementi del modello è inevitabile aver già affrontato e risolto tutto ciò di cui ci siamo occupati sinora.

Gestione informativa: un aspetto spesso tralasciato

Certamente non si tratta di un percorso banale né così comune. In altri termini, nella grande maggioranza dei casi, come visto, già lo scoglio morfologico è spesso sufficientemente ostico da far desistere nel procedere e, quand’anche superato, lo rimane a maggior ragione nel procedere oltre. Di conseguenza, se è già piuttosto raro imbattersi in modelli hBIM ben sviluppati sul fronte geometrico, ancor più raro sarà, inevitabilmente, individuare progettisti che si siano avventurati con successo nella sfida della gestione informativa, purtroppo altrettanto problematica della prima.

A questo si aggiunga un’altra constatazione di fatto, ben più trasversale e sistematica. In generale nel nostro Paese la percezione diffusa del concetto di modello informativo ha attecchito e si focalizza ancora primariamente come restituzione geometrica e grafica o, al massimo, in termini di valorizzazione quantitativa. Salvo casi virtuosi, non è quindi del tutto matura la sensibilità del progettista medio al tema centrale del dato, ancora oggi percepito come un qualche cosa di distante o estraneo rispetto al mondo digitale delle costruzioni. Di conseguenza, in generale, se la familiarità con le piattaforme di Authoring come Archicad è ormai ben consolidata nel settore, si fatica ancora molto non appena ci si sposta su argomenti più specificamente legati al processo informativo. Temi imprescindibili come IFC, BCF e IDS sono ancora molto lontani dal diffondersi capillarmente nella pratica disciplinare quotidiana, senza nemmeno citare concetti più ampi e complessi come Digital Twin, Data Analytics o Data-Driven Design.

Ma come sempre puoi vedere questo problema da due diversi punti di vista:

• Come una ragione per cui rinunciare a un processo apparentemente troppo complicato e appannaggio dei soli esperti di settore;
• Oppure come un’opportunità irripetibile per cavalcare un mercato in fortissima espansione e appassionarti ad argomenti estremamente affascinanti migliorando sensibilmente il tuo livello di comprensione e padronanza degli strumenti che già utilizzi ogni giorno.

La flessibilità di Archicad sul fronte semantico

Nelle prime tappe della nostra indagine ci siamo scontrati con una apparente inadeguatezza strutturale dell’ecosistema BIM rispetto alle necessità geometriche, morfologiche e tipologiche del contesto costruito, e in particolare del patrimonio storico. Ma la questione si fa purtroppo ancor più problematica se guardiamo all’altro fronte, ossia, appunto, la semantica degli elementi e l’ecosistema di dati che popola i modelli informativi. Con quali concetti significheremo le geometrie, quand’anche riuscissimo a restituirle in prima battuta? E qui emerge forse la questione più rilevante della pratica hBIM che, purtuttavia, apparirà nella sua notevole criticità soprattutto a quanti abbiano già una discreta esperienza in materia di gestione informativa dei flussi interoperabili. Perché a questa costitutiva inadeguatezza di tutte le piattaforme di Authoring sul fronte geometrico corrisponde purtroppo una simmetrica e altrettanto problematica inadeguatezza di fondo sul fronte informativo. Non solo, infatti, l’ambiente BIM non offre strumenti parametrici dedicati agli elementi tipologici dell’edilizia storica, ma specularmente — ed è a questo punto inevitabile — non offrirà, parimenti, i concetti e le classificazioni retrostanti su cui queste geometrie dovrebbero fondare la propria identificazione semantica. E ancor peggio, in questo caso non è nemmeno tanto un ostacolo legato alle apparenti carenze del software — in Archicad ad esempio, come vedremo, possiamo generare in pochi secondi tutte le classi integrative di cui abbiamo necessità.

Il limite davvero problematico è qui incarnato dall’invalicabile inadeguatezza sul fronte storico del linguaggio stesso del BIM, su cui si fondano i processi interoperabili, per definizione aperti e multi piattaforma, che non sono in alcun modo integrabili né dall’utente né dalle stesse software house. Ecco allora che in Archicad potrai generare, ad esempio, la classe Volta così come già esistono le classi Muro o Solaio. Ciò che però non potrai fare è generare la classificazione BIM IfcVault, così come invece esistono IfcWall o IfcSlab, in quanto appannaggio esclusivo del consorzio BuildingSmart, l’unico attore internazionale che assume, appunto, l’incarico di definire gli standard informativi condivisi per la filiera digitale delle costruzioni. Ma poiché in IFC, come d’altra parte già accade in Archicad, l’informazione viaggia esclusivamente per via classificativa, eccoci arrivati a un vicolo cieco, almeno apparentemente. Non sembra cioè possibile costruire efficacemente un ecosistema informativo nel contesto della digitalizzazione del patrimonio.

Ma fortunatamente, anche in questo caso, non è affatto così. La straordinaria flessibilità di Archicad che abbiamo già esplorato sul fronte geometrico, ci consente in modo tutto sommato insospettabilmente veloce di aggirare efficacemente anche l’ostacolo informativo, tramite un impiego consapevole e sincronizzato delle Classificazioni, delle Proprietà e del processo di Mappatura Tipi all’interno dei traduttori IFC. Come sempre, tuttavia, per risolvere problemi complessi non possiamo prescindere da una conoscenza approfondita degli strumenti e delle funzionalità che Archicad ci offre; ancora una volta, cioè, l’hBIM rappresenta un’eccezionale palestra digitale in cui potremo allenare ed evolvere il nostro livello di comprensione e competenza sull’intero processo informativo, ben al di là del contesto Heritage.

Le classificazioni: un alleato inaspettato

Non possiamo che cominciare la nostra panoramica a partire dalle Classificazioni, il più importante attore semantico dell’intero ecosistema digitale, senza il quale decade completamente sia il processo associativo interno delle Proprietà, sia, soprattutto, la mappatura IFC che ci permetterà di fuoriuscire dall’ambiente di Authoring. La Classificazione non è altro che un sistema tassonomico organizzato ad albero contenente tutti i concetti utili a descrivere un determinato gruppo di fenomeni e le corrispettive relazioni reciproche. Archicad contiene nativamente un sistema di Classificazione schematico proposto da Graphisoft, che nella maggior parte dei casi è più che adeguato a restituire l’architettura informativa di un qualsiasi manufatto contemporaneo; ma naturalmente non di un manufatto storico all’interno del quale, appunto, compariranno inevitabilmente concetti ed elementi tipologici del tutto estranei alle odierne tecnologie edilizie.

Contrariamente all’opinione comune, anzitutto, è possibile affiancare o sostituire integralmente questo sistema nativo con un diverso albero classificativo, di nostra elaborazione o direttamente ereditato da altre organizzazioni ed enti specialistici di settore, come UniClass, OmniClass, Uniformat o Masterformat. In Italia non esiste ancora uno standard nazionale di riferimento ma è possibile, ad esempio, codificare nuovi alberi di Classificazione integrativi per rispondere a esigenze specifiche e normate da UNI. Sostituire integralmente il sistema di Classificazione nativo è in generale sconsigliabile per utenti inesperti perché la cancellazione completa dell’albero compromette diversi automatismi associativi già efficacemente impostati, obbligandoci a ripristinare la quasi totalità dei processi di matrice informativa all’interno del software. Nella maggior parte dei casi è preferibile più semplicemente integrare la struttura di Classificazione nativa con i concetti necessari individuandone la migliore collocazione possibile all’interno dell’albero tassonomico standard. Non mi basterà, infatti, codificare la classe Volta ma dovrò determinare, appunto, in che relazione questa si troverà rispetto ai concetti già presenti e sistematizzati da Graphisoft.

Vediamo un esempio di questo processo seguendo il percorso dell’albero dalle ramificazioni principali sino alle foglie.

La volta è certamente un elemento, un elemento di costruzione, ma in che rapporto gerarchico e concettuale si trova rispetto agli altri suoi simili? Potremmo decidere per una soluzione paratattica: la volta è uno dei tanti elementi costruttivi, parallelo a muro, solaio, tetto ecc. Se invece preferiamo introdurre una soluzione ipotattica potremmo decidere che si tratti, ad esempio, di un tipo particolare di solaio e inserire quindi la nostra foglia all’interno della sua ramificazione. Ma non è detto nemmeno che si tratti di una foglia; e se avessimo necessità di codificare concetti più specifici e interdipendenti? Dove si troveranno, quindi, la lunetta, o la botte, la crociera e la vela? Ecco allora che, dovunque la si sia inserita, la foglia di classe Volta potrebbe diventare a sua volta ramificazione all’interno di una rete di relazioni più estesa e complessa. Naturalmente questo stesso processo andrà replicato per tutti i numerosissimi concetti che abbiamo esplorato nella panoramica degli articoli precedenti.

Il lavoro è piuttosto ampio e impegnativo ma, una volta terminato, potremo ovviamente conservarlo in Template o trasferirlo tra progetti diversi. Il nuovo albero di Classificazione, così integrato e ottimizzato, offrirà un sistema descrittivo completo ed esaustivo per la restituzione semantica del patrimonio storico, nonché una solida base concettuale per procedere con lo sviluppo del processo informativo.

Linguaggi comprensibili 

Quando avremo completato la fase di Classificazione degli elementi, tutte le basi necessarie saranno predisposte per automatizzare il flusso di significazione sino alla mappatura IFC. Non ci resta quindi che procedere con il prossimo passaggio, trasmettere cioè al traduttore le medesime indicazioni semantiche che abbiamo già fornito al sistema di Classificazione interno.

Se non hai dimestichezza con questi temi potrà sembrarti strano di dover replicare tutte queste specifiche. In fin dei conti, molto probabilmente, non ti è mai capitato di doverlo fare o, quantomeno, non così estensivamente. Ciò accade perché, in effetti, tutti i concetti del sistema di Classificazione nativo sono già stati opportunamente trasmessi al traduttore da Graphisoft nel Template standard di Archicad, risparmiandoti un bel po’ di complicazioni. Così però, inevitabilmente, ogni qualvolta integrerai il sistema di Classificazione nativo con nuovi concetti dovrai ricordarti di coordinare il traduttore di conseguenza. E poiché, come abbiamo appena visto, nel contesto hBIM siamo sostanzialmente obbligati a intervenire massivamente sulle Classi, saremo altrettanto obbligati a intervenire massivamente all’interno del traduttore, aggiungendo un ulteriore livello di complessità a un processo che è già di per sé piuttosto articolato. Per completare la procedura dovrai quindi accedere ai Traduttori IFC e definire la Mappatura Tipo per lo Schema che stai utilizzando — al momento, 2X3 o 4. Noterai che sulla colonna di sinistra Archicad ti riporta il sistema di Classificazione aggiornato segnalandoti con il colore azzurro le Classi che abbiamo appena integrato e per le quali, appunto, non è ancora stata correlata una entità IFC. Per assegnarla dovrai impostare la mappatura su Personale, scontrandoti però con un ultimo annoso problema che abbiamo già sollevato. Se le Classi Archicad sono liberamente implementabili, lo stesso non si può dire del corrispettivo IFC Type: potrai certamente scegliere quale assegnare ma dovrai limitarti alla selezione fornita nel menu contestuale, che non è integrabile dall’utente né dalle stesse software house. Non possiamo semplicemente inventarci una parola nel linguaggio IFC, tanto quanto non possiamo inventarci un termine italiano: qualunque linguaggio, per definizione, prevede infatti che il lessico si utilizzi ma non si crei autonomamente, proprio perché il suo compito è permettere una comunicazione comprensibile basata su standard convenzionali e condivisi.

Anche qui, di conseguenza, si ripropone una dinamica analoga a quella che abbiamo già esplorato in materia di Classificazioni. Dove inserirò il mio concetto? All’interno di quale macro categoria? Qual è il concetto esistente più prossimo da un punto di vista semantico? Quella che per le Classificazioni era una semplice scelta di inquadramento tassonomico, tuttavia, qui diventa, al contrario, una necessità inevitabile con cui scendere a compromessi.

Immaginiamo, dunque, di assimilare il concetto di Volta all’idea più generale di solaio; sceglierò quindi IfcSlab ma non potrò ritenermi pienamente soddisfatto della soluzione. Le mie volte confluiranno infatti all’interno di un’unica grande categoria concettuale insieme a elementi del tutto diversi e incompatibili da un punto di vista informativo. Anche qui, però, in attesa che BuildingSmart estenda finalmente la portata lessicale di IFC all’ambito Heritage, una qualche formula di compromesso si può trovare. Anche in funzione della sua capacità ristretta, IFC prevede infatti che si possa specificare ulteriormente la natura di un certo elemento, al di là della categoria generale di appartenenza. Il Predefined Type ospita una sequenza di opzioni più puntuali, ma soprattutto la possibilità di richiamare un’alternativa a discrezione dell’utente — Userdefined, appunto. Il valore che sarà qui specificato passerà su IFC integrando più dettagliatamente la natura esatta di ciascun elemento. Il compromesso è più che accettabile, non avremo a disposizione IfcVault ma riusciremo comunque a descrivere i voltati come IfcSlab ObjectType:VOLTA, consentendoci in ogni caso una mappatura informativa specifica, puntuale e indipendente dagli impalcati di altra natura con i relativi PredefinedType.

Va precisato, in conclusione, che ci sono altri metodi, più complessi, per significare correttamente il modello IFC, così come, ovviamente, molti altri aspetti del linguaggio e dello sviluppo informativo che, per brevità, qui non abbiamo descritto. Questa semplificazione, per quanto riduttiva, ti porterà in ogni caso a produrre elaborati informativi efficaci e consistenti, già oltre le aspettative di un mercato che ancora fatica enormemente a gestire e sfruttare il processo nella sua interezza, soprattutto quando, come in questo caso, ci muoviamo nelle aree più grigie dai confini disciplinari non ben definiti.

Se vorrai approfondire nel dettaglio questo e tutti gli altri temi che abbiamo introdotto negli articoli precedenti ti invito ancora una volta a consultare l'ebook, ricchissimo di linee guida sul mondo hBIM, che potrai scaricare gratuitamente dal portale Graphisoft Italia dedicato insieme a tante altre risorse indispensabili sul tema, dalla libreria agli eventi di presentazione.

Questo è, almeno per ora, l’ultimo articolo sulla digitalizzazione del patrimonio ma, come ti ho già anticipato, il nostro viaggio nel mondo dell’hBIM non si conclude qui. In queste settimane abbiamo tenuto tre nuovi webinar con approfondimenti verticali ancora più avanzati sulla gestione di degradi, nuvole e fotogrammetrie. Se tutti questi argomenti ti interessano rimani sintonizzato, presto saranno disponibili sul portale. Nel frattempo, ti ringrazio per essere arrivato sino alla fine e mi auguro di essere riuscito a trasmetterti un po’ di curiosità e passione per questi temi così affascinanti.

A presto!

Mario Ambrogi
Architetto, BIM & AEC Innovation Manager
Open Building - Gruppo Contec