Questo lavoro di tesi nasce dalla necessità di avere uno strumento facile e intuitivo utile per la gestione di edifici storico monumentali complessi sia per i dipendenti, sia per i tecnici manutentori.
Il nostro caso studio è rappresentato da Palazzo Vecchio, luogo in cui abbiamo svolto un tirocinio curricolare, grazie ad una convenzione stipulata tra il Comune di Firenze e l’Università degli Studi di Firenze. Abbiamo così potuto apprendere le modalità organizzative e l’uso ordinario degli spazi, le relazioni tra datori di lavoro e la gestione dei flussi di visitatori, raccogliendo dati amministrativi e geometrici sul reale utilizzo degli ambienti.
Preliminarmente all’informatizzazione dei dati, abbiamo studiato la struttura relazionale sottesa all’edificio, fino ad analizzare gli elementi architettonici basilari che definiscono una stanza. Le caratteristiche geometriche, le fonti di rischio e la gestione creano una rete neurale complessa, che ci ha permesso di estrapolare una serie di informazioni necessarie per la definizione di ciascun elemento.

Per organizzare i dati acquisiti, abbiamo deciso di usare il programma Revit(R) che consente l’introduzione di parametri condivisi, definiti ad hoc per ogni oggetto edilizio. Nonostante che la tecnologia BIM venga utilizzata per la progettazione a livello architettonico, strutturale ed impiantistico di organismi edilizi nuovi, la natura parametrica degli oggetti ci ha convinti della sua adozione per uno scopo nuovo: la gestione dei flussi e della sicurezza antincendio in edifici storici.

I parametri condivisi, inseriti nel modello BIM, sono stati codificati secondo il linguaggio IFC, standard internazionalmente riconosciuto che, con un file di testo detto PropertySet, permette l’esportazione e la condivisione del progetto. Attraverso un software di visualizzazione, è stato possibile verificare la correttezza della scrittura di esportazione e la completezza delle informazioni di ogni oggetto.

I risultati di questo esperimento sono avvalorati da alcune prove eseguite con un programma di Code Checking (Solibri Model Checker), al quale è stato possibile impostare delle regole di analisi per individuare criticità e peculiarità del progetto. Si dimostra, pertanto, che il metodo teorico di codifica è efficace e svincolato dalla realtà specifica di Palazzo Vecchio, tanto da consentirne l’applicazione a qualsiasi edificio storico.

OBIETTIVI

Tale modellazione si è ampiamente affermata come strumento di progettazione, perché favorisce l’interazione e la collaborazione tra operatori di differenti settori. Sulla base della nostra esperienza ci siamo accorte del duplice aspetto gestionale di Palazzo Vecchio, edificio storico monumentale, comprendente, da un lato, l’organizzazione interna dei dipendenti e, dall’altro, la programmazione della sicurezza e della manutenzione assieme alla tutela di edifici e contenuti. Pertanto, nasce l’esigenza di strutturare in maniera analitica il processo iterativo di progettazione, aggiornamento e check dei dati.

Il nostro proposito è quello di utilizzare il BIM, tradizionalmente impiegato per la progettazione del nuovo, come strumento per la rappresentazione 3D della zona di studio, per l’inserimento e la catalogazione di informazioni e per l’esportazione in un formato universale. Quest’ultimo passaggio potrebbe consentire un futuro sviluppo di un programma intuitivo e semplice, finalizzato all’uso manutentivo dell’edificio: una manutenzione, basata su dati aggiornati, permette di garantire il massimo livello di funzionalità e sicurezza. A questo punto, si procede all’analisi di dettaglio degli elementi architettonici base, a cominciare dalla porta. Di essa si analizzano dapprima le caratteristiche geometriche:

la funzione separatrice tra ambiente interno ed esterno o tra ambienti interni;
l’epoca di costruzione a cui risale, nuova o antica;
il valore artistico;
le dimensioni caratteristiche, sia al netto del telaio sia lorde;
il verso di apertura;
il numero di ante mobili e di parti fisse, etc.
Ci siamo, però, posti il problema della gestione in caso di emergenza: se la porta è tenuta chiusa o se è ostruita da arredi e, contemporaneamente, è indicata come via di fuga, rende lento, se non impossibile, l’esodo dal locale. Perciò, l’utente e il fattore umano diventano oggetto d’indagine come cause stesse di rischio, in particolare si studia:

le attività divise dalla porta e il loro indice di rischio;
il numero di persone, dipendenti o visitatori, che ci sono nei due ambienti che la porta divide;
la manutenzione ordinaria e straordinaria della porta e con quale cadenza viene eseguita;
chi si occupa, in caso di danno, di sistemare e pagare l’intervento, etc.
Infine, abbiamo collegato ogni aspetto geometrico e gestionale al requisito prestazionale trovato in normativa, la cui inottemperanza genera un rischio, come si evince dal diagramma riportato di seguito. Si evidenzia, in particolare, come la divisione tra caratteri geometrici e gestionali sia stata fatta qui a livello cromatico usando il riquadro verde per i primi e il blu per i secondi. Infine, sono stati collegati gli specifici aspetti con un rischio, in riquadro rosso, di cui si denuncia l’area (rischio incendio) e la tipologia (aumento carico incendio).

Schemi analoghi sono stati prodotti per tutti gli elementi citati: muro, pavimento, soffitto, finestra, arredo e, ad un livello superiore, balcone, scale, locale.

Lo schema WBS è stato definito per tutte le unità essenziali: è facile notare come un elemento architettonico apparentemente semplice nasconda relazioni complesse e una vasta gamma di potenziali rischi dovuti non solo alle particolarità di forma e di tipo, ma più spesso legati all’uso improprio o incauto che ne viene fatto.

Non si inseriscono i rischi dall’inottemperanza di una o più normative perché stiamo costruendo un modello informativo della situazione attuale. Apposite regole codificanti verranno applicate in un programma di Code Checking.

Case Study di

Relatori
Prof. Ing. Carlo Biagini
Prof Ing. Pietro Capone

Correlatori
Ing. Vincenzo Fusco
Ing. Vito Getuli
Ing. Tommaso Giusti

Anno Accademico 2018/2019

Candidate
Carlotta Arena
Elisa Marini

PROPERTY SET

Il nostro approccio all’IFC, vista la sua complessità, si è focalizzato sull’esportazione di informazioni riguardanti i settori “architettura” e “prodotti”. Per fare ciò si devono riportare tutti i parametri da esportare in un file di testo, chiamato PropertySet, mantenendo la stessa codifica e scrittura con la quale sono stati definiti.

Il modello BIM usato è di tipo architettonico, arricchito con elementi spaziali, quali gli arredi e i terminali degl’impianti. Essi portano con sé un pacchetto d’informazioni e di parametri che non sono presenti in Revit(R).

PROCEDIMENTO OPERATIVO
La visualizzazione dell’oggetto e dei suoi dati in Solibri Model Viewer è la prova di una corretta impostazione del file di esportazione dei parametri.
Ma cosa fare nel caso in cui alcuni di loro non comparissero? È avvenuto un errore ed è proprio da qui che si riparte.

Si controlla la coerenza tra i parametri in Revit(R) e il file di PSet:

La scrittura del testo del parametro deve essere identica (compresi gli spazi, lettere maiuscole e minuscole etc.);
Il genere di parametro (“Text”, “Number”, “Yes/No”, “Area” etc.);
Congruenza di Instance e Type;
Correttezza formale della scrittura del P_Set dall’inizio alla fine (spazi, Tab, #);
Famiglia di esportazione;
Regole predefinite del programma: ricercare nella struttura su www.buildingSmarttech.org

APPLICAZIONE DI VERIFICA DI SOLIBRI MODEL CHECKER

Solibri è un software che svolge la funzione di analisi e controllo dei modelli BIM, al fine di evidenziare i problemi che ne possono inficiare l’integrità, la qualità e la sicurezza. Permette una precoce individuazione delle criticità, evidenziandone anche la gravità: rosso (elevato), arancio (medio), giallo (basso), verde (idoneo). Per eseguire la ricerca è richiesta la definizione di una regola, che può essere o scritta ex novo dall’utente o modificata dal pacchetto predisposto nel programma. Per il fine che ci siamo posti, è stato sufficiente modificare una regola di base, poiché volevamo solo testare l’effettivo funzionamento del modello. Le prove eseguite ricercano criticità nel campo della sicurezza antincendio.

La prima verifica è stata di tipo dimensionale sulle porte: ricercare gli elementi con larghezza di 120 cm (2 moduli) e altezza 220 cm. Si è utilizzato la regola denominata “Door Minimum Dimensions”. I risultati mostrano quali porte non sono verificate, la causa e l’identificativo.

La seconda verifica eseguita controlla la presenza di un oggetto in una stanza, grazie alla regola denominata “General Intersection Rule”. L’idea è di verificare se c’è intersezione tra l’oggetto e la stanza, percepita come un volume al netto dei muri. Verifichiamo in quali stanze ci sono gli estintori.

Da notare che per la formulazione della domanda in questo caso sono evidenziati in rosso i risultati positivi. Analizzando i risultati è possibile determinare i riferimenti identificativi sia dello spazio e che dell’oggetto in questione. Le regole sono flessibili e si adattano a qualsiasi tipo di ricerca, come la seconda regola, che è stata usata per evidenziare le sale contenenti i cartelli relativi alla via di esodo.

Si nota come il modello non solo sia leggibile in tutte le sue parti da un visualizzatore e, quindi,anche da un programma di Code Checking, ma sia anche verificabile attraverso semplici regole preimpostate al fine di valutarne, ad esempio, la sicurezza antincendio.

CONCLUSIONI

Lo studio approfondito della rete di connessioni tra le caratteristiche geometriche, i rischi e gli utenti, unito ad una corretta modellazione degli ambienti, ha prodotto risultati soddisfacenti. Ciò viene avvalorato non soltanto dalla corretta visualizzazione del progetto e dei suoi parametri nel software Solibri Model Viewer, ma anche dalla verifica del modello, attraverso regole di sicurezza antincendio, nel programma di Code Checking. Durante la modellazione ci siamo resi conto che Revit ha una struttura rigida, improntata sulla progettazione del nuovo, che si piega con difficoltà alle regole più evanescenti degli edifici antichi.

Il linguaggio internazionale IFC, per contro, risulta flessibile alla codifica e all’esportazione di qualsiasi tipo di dato. Il lavoro eseguito si colloca, ovviamente, all’interno di uno studio più ampio di gestione e parametrizzazione della realtà degli edifici complessi.

Il prossimo sviluppo è sicuramente quello di catalogare analiticamente tutto l’edificio e, a nostro parere, di implementare lo schema relazionale in un’applicazione per tablet per dotare il personale tecnico di uno strumento pratico e funzionale.