Si è già parlato del PGI nella sezione dedicata relativa al processo edilizio BIM, si ricorda che questo costituisce un documento contrattuale vincolante che comprende le richieste sviluppate nel capitolato informativo dalla committenza, in questo caso l’Agenzia del Demanio pubblico.
Il PGI risponde alle linee guida fornite dall’amministrazione pubblica denominate “BIMMS: Method Statement Process LINEE GUIDA Produzione Informativa BIM” queste descrivono nel dettaglio le richieste avanzate dalla PA nei confronti di:
❖ Sistemi di codifica:
o Relativi a modelli ed elaborati;
o Codifiche degli elementi;
o Codifiche dei materiali;
o Codifiche in genere.
❖ Struttura ed organizzazione dei modelli digitali:
o Federazione di modelli;
o Sistemi di coordinate condivise;
o Piani di riferimento dei modelli;
o Specifiche di inserimento degli elementi nel modello;
o Livelli di coordinamento;
o Tolleranze geometriche.
❖ Organizzazione del contenuto informativo;
o Contenuto geometrico dei modelli;
o Contenuto alfanumerico dei modelli;
o Contenuto documentale nell’ACDat.
❖ Strumenti informativi:
o Formati di scambio delle informazioni;
o Dimensioni massime dei modelli digitaliM o upDAT, ACDat e Repository
In questo caso le linee guida, sviluppate in itinere, hanno avuto vera e propria funzione di capitolato informativo digitale per quanto riguarda la metodologia
112 BIM. Come più volte affermato dalla PA quanto svolto in “Caserma Perotti di Bologna” è uno dei primi sforzi di approcciarsi al procedimento edilizio in un approccio full BIM. La commessa infatti è stata strutturata secondo le direttive che sono state descritte nella sezione dedicata e sono stati seguite tutte le procedure normate.
Come è possibile notare nel C.I. prima introdotto non si fa riferimento a quelli che sono i model uses che l’amministrazione pubblica ha previsto per i modello. Questo ha comportato alcuni elementi di confusione per quanto riguarda la modellazione digitale, infatti, uno dei parametri che in genere determina il contenuto, in termini quantitativi ed informativi di oggetti, del modello informativo è proprio il motivo per cui questo vuole essere utilizzato;
ad esempio rimanendo nell’ambito della progettazione impiantistica, se si vuole utilizzare un modello per fare delle analisi energetiche è necessario che tutti gli elementi contengano i dati di flusso così come i sistemi dovranno necessariamente essere collegati al fine che possa avvenire il calcolo dei flussi. Allo stesso modo, invece, se un modello è stato strutturato solo al fine di computo metrico estimativo poco importa che i sistemi siano bene strutturati o che vengano inserite le informazioni di flusso negli elementi di modello, importerà, piuttosto, che questi siano tutti presenti e codificati in modo univoco cosicché gli si possa attribuire un valore economico. Poco realistica è la pretesa di strutturare modelli informativi che possano coprire tutte le dimensioni del BIM, questo comporterebbe, in primo luogo un dispendio in termini di risorse non affrontabile ed in secondo luogo un appesantimento dei modelli informativi, che per forza di cose, perderebbero di efficienza nella singola applicazione.
Si è scelto di descrivere i contenuti del piano di gestione informativa perché ritorneranno centrali, soprattutto nel discorso sopra citato, nella seconda parte applicativa dell’elaborato, dove in base ai contenuti informativi prescritti si cercherà di estrapolare le esigenze della PA rientranti nella dimensione 5D del BIM e di conseguenza descrivere quelli che sarebbero i requisiti informativi relativi agli oggetti necessari per la corretta strutturazione dei modelli.
113 In questa introduzione, per questioni ovvie legate alla privacy si escluderanno le parti del PGI riguardanti le responsabilità specifiche e le infrastrutture hardware e software, che comunque non avrebbero avuto nessun interesse applicativo, ci si limiterà piuttosto ad esplicare il sistema di condivisione del lavoro, la struttura dell’ACDat, un’introduzione sommaria sulle codifiche di modelli, elmenti e materiali ed infine sulla strutturazione dei PSet per gli schemi IFC di condivisione.
L’ACDat è stato sviluppato con il supporto della piattaforma di condivisione cloud di Autodesk BIM 360, dall’azienda ArchLivIng seguendo la classica suddivisione dettata dalla PAS 1192 e poi ripresa dalla UNI 11337 che prevede la strutturazione di cartelle date da:
❖ WIP: Work In Progress, ovvero la cartella all’interno della quale alloggiano tutte le discipline riguardanti il progetto, in questa i professioni sti di ogni disciplina nella loro cartella hanno l’opportunità di inserire i loro modelli e di lavorarci indipendentemente dagli altri attori del processo.
❖ SHARED: questa è la cartella di condivisione degli elementi, in questa cartella viene inserito tutto il materiale necessario al coordinamento dei vari professionisti e stakeholder del processo. In questa cartella con scadenze concordate devono essere caricati i modelli di disciplina di modo tale che sia possibile il coordinamento e la validazione successiva dei modelli digitali, secondo i metodi di code e model checking già citati nei precedenti paragrafi, trattando la dimensione 3D del BIM.
❖ PUBLISHED: come il nome fa presagire in questa cartella vengono caricati gli elaborati finali o gli elaborati per le validazioni con la committenza.
❖ ARCHIVED: rappresenta la cartella di archiviazione in cui vengono conservate le precedenti versioni degli elementi di successivi alla validazione, questo archivio è fondamentale per tenere traccia delle modifiche che sono state effettuate.
114 In generale è possibile affermare che tutte le aziende coinvolte nel processo hanno adottato un metodo di condivisione del lavoro dettato dal seguente schema:
Figura 50: Schema di condivisione del lavoro. Fonte: personale
Questo schema è già stato introdotto nei processi collaborativi e rappresenta la metodologia di lavoro più diffusa in assoluto; i modelli di disciplina sono dei modelli centrali, questo permette a vari professionisti della singola azienda di lavorare sullo stesso modello, senza avere dispersione del dato. Nel panorama però multidisciplinare, viene strutturato un modello federato. In questo modo si ha il meglio dei due modi di approcciare alla condivisione del lavoro uno derivante da workset e l’altro dai modelli federati, per ulteriori approfondimenti si consiglia di consultare la sezione dedicata.
ARC
ELE
HVC
STR PDS
FSS
115 Nel caso in questione, le discipline coinvolte sono quelle riportate in figura cioè:
❖ Architettonica;
❖ Strutturale;
❖ Elettrica;
❖ HVAC;
❖ Plumbing;
❖ Fire security engineering.
Per ognuno di queste discipline sono stati redatti 3 modelli digitali, infatti, la struttura è stata divisa in tre blocchi funzionali:
❖ Torre ad uso uffici codificata BO0359012;
❖ Conservatoria BO0359013;
❖ Archivio BO0359014;
Le linee guida della PA prevedevano la creazione di due modelli di coordinamento:
❖ Il modello di coordinamento di blocco funzionale;
❖ Il modello di coordinamento globale.
Secondo quanto riportato dallo schema:
Figura 51: Schema di coordinamento dei modelli digitali. Fonte: PGI commessa, ArchLivIng
116 La PA ha previsto una codifica di modello per ogni singolo blocco funzionale che è stata strutturata secondo quanto segue:
Figura 52: Schema di codifica dei modelli informativi digitali. Fonte: PGI, ArchLivIng Inoltre, sono state definite delle codifiche per quanto riguarda la denominazione degli oggetti del modello digitale, i tipi delle famiglie, infatti, sono stati rinominati seguendo la specifica nella seguente tabella:
Figura 53: Schema di codifica della denominazione degli oggetti digitali. Fonte: PGI, ArchLivIng
117 Gli ultimi elementi ad essere stati classificati dopo i modelli digitali e gli oggetti digitali sono stati i materiali utilizzati nel progetto secondo lo schema strutturato dal seguente:
Figura 54: Schema di codifica della denominazione dei materiali di progetto. Fonte: PGI, ArchLivIng.
Oltre ai sistemi di codifica sopra riportati, come compete al CI e poi deve essere ribadito nel PGI sono stati riportati i formati di consegna e di interscambio. È stato richiesto, il formato proprietario e i files di schema IFC strutturati secondo i seguenti PropertySet di cui viene riportato una minima parte solo a scopo illustrativo:
Figura 55: PSet richiesti dalla P.A. nelle linee guida. Fonte, P.G.I. & C.I., ArchLivIng
118 Si fa notare come questi PSet abbiano corrispondenza poi sul modello informativo digitale a parametri che possono essere come nel caso delle sezioni relative a Ifc.Site e Ifc.Building al progetto, oppure, come nel caso del PSet Ifc.Element, agli oggetti del modello digitale.
Come si può notare quindi già solo dal piccolo estratto, viene richiesta una varietà di parametri molto grande e di differenti tipologie; infatti, alcuni riferiscono ai certificati degli oggetti, piuttosto che al produttore mentre altri alle schede di manutenzione o al cantiere. Questo non è ideale sotto l’aspetto metodologico perché fa intendere che il modello non abbia una funzione precisa, anzi, che sia stata cercata di seguire l’utopia del modello omnicomprensivo.
I parametri, siccome vincolati da contratto, rispecchiano quanto indicato dai PSet sono stati inseriti nel modello come parametri di progetto, dopo essere stati redatti come parametri condivisi di modo tale che tutte le aziende coinvolte ne potessero usufruire:
Figura 56: Parametri inseriti nel progetto. Fonte: personale
119