CollaborativeWorking

Il BIM come flusso di informazioni secondo le norme tecniche BS 1192 e le Pas 1192-2

BIM e modello virtuale: sviluppo e flusso di informazioni all’interno del Common Data Environment (CDE) secondo le BS 1192 e le Pas 1192-2. I blocchi WIP (Work in Progress) e SHARED

Nella costruzione di un modello virtuale BIM è fondamentale stabilire qual è il corretto flusso di informazioni. In questo articolo analizziamo proprio come si struttura in maniera corretta il flusso informativo, a partire dalla fase progettazione del modello virtuale, secondo le indicazioni delle BS 1192 e PAS 1192-2. Dunque la metodologia BIM non va vista solo come un insieme software e tecnologie specifiche, ma anche come un flusso di informazioni che segue regole ben definite.

I tecnici e le imprese che operano nel settore delle costruzioni hanno oggi maturato una maggiore consapevolezza, anche solo rispetto a pochi anni fa, di quel che significhi il BIM per l’attività professionale: una metodologia basata su tecnologie innovative, in grado di favorire modalità di lavoro collaborative e più efficienti.

Grazie a questa tecnologia l’obiettivo di una migliore condivisione dei dati e delle scelte progettuali tra differenti professionalità, senza perdita di informazioni nei passaggi da una fase ad un’altra, si concretizza nella messa a disposizione di modelli virtuali dell’edificio in grado di dialogare tra di loro.

Tale possibilità è tecnicamente garantita dalla diffusione di formati di dati condivisi tra i differenti software, il più noto e diffuso dei quali è certamente il formato IFC (V. art. “BIM e IFC: l’interoperabilità dei software e il Building Smart International”).

Si realizza, così, il modello virtuale dell’edificio, il prototipo, operativamente costituito da una “federazione” di modelli virtuali, ciascuno ascrivibile ai principali ambiti applicativi: architettonico, strutturale, impiantistico, ecc. (V. art. “Evoluzione del BIM e del modello virtuale dell’edificio”).

E’ chiaro però che se l’aspetto meramente tecnico del “dialogo” tra modelli è gestito efficacemente in ambito software, le modalità con cui i vari team di progettazione si rapportano tra loro nel rendere disponibili i rispettivi modelli virtuali e relative informazioni, afferisce certamente ad un aspetto “comportamentale” determinante per il raggiungimento degli obiettivi di lavoro collaborativo e condiviso.

Ed è questa una delle ragioni dell’ampia produzione di linee guida, protocolli, progetti pilota, ecc. redatti nei vari Paesi da Amministrazioni Pubbliche o private, associazioni di categoria, enti di normazione, in cui vengono anche “riprogettati” gli aspetti di tipo contrattuale, documentale e legale, e i mutui rapporti di questi ultimi con le fasi di creazione e scambio dati tra i modelli virtuali.

Il Common Data Environment (CDE) secondo le BS 1192 e le Pas 1192-2

Le Pas 1192-2:2013, pubblicate dall’ente di normazione inglese British Standard Institution e facenti parte di un ampio corpo di linee di indirizzo e norme organicamente concepito, bene chiariscono questi due aspetti nella seguente rappresentazione grafica.

 

 

Pas1192-2 (1)

Figura 1 – Pas1192-2 (1)

 

Tale rappresentazione è ottenuta dalla sovrapposizione dei 2 seguenti schemi:

 

Pas1192-2 (2)

Figura 2 – Pas1192-2 (2)

 

Pas1192-2 (3)

Figura 3 – Pas1192-2 (3)

 

Come è evidente in quest’ultima immagine, le fasi di realizzazione del prototipo virtuale dell’edificio (creazione, sviluppo e interrelazioni tra i modelli) si svolgono all’interno di un’area definita come Common Data Environment (CDE).

È già qui che occorre descrivere i processi e le procedure atte a ben definire forme e modalità, ruoli e responsabilità con cui possono svilupparsi rapporti collaborativi tra i vari team di tecnici coinvolti.

Questo aspetto, come è facile intuire, non può essere sviluppato staticamente una volta per tutte, avulso dalla tipologia e dall’entità dell’intervento edilizio in questione o non dimensionato alle reali risorse professionali in gioco; se si procedesse in questo modo, con buona probabilità, si creerebbe un corpo procedurale ipertrofico o sottodimensionato.

Le numerose linee di indirizzo redatte e la necessità della disponibilità di progetti pilota, nascono proprio come supporto alla vasta casistica possibile nella pratica quotidiana.

Il corpo normativo britannico offre una possibile, ben strutturata, organizzazione di quest’area dei dati comuni, formalizzando le modalità operative, dalla nomenclatura da dare ai file, all’organizzazione degli archivi, alle modalità di scambio dati.

Il “cuore” del Common Data Environment è illustrato nell’immagine seguente è composto da 4 sub-aree, connesse tra loro dal flusso (principale) delle informazioni, che si svolge in senso antiorario partendo dalle aree in lavorazione (Work in Progress) per terminare nell’area Archivio.

 

Collaborative Working (1)

Figura 4 – Collaborative Working (1)

 

Le quattro sub-aree sono:

  1. Work in Progress: sono qui collocate le aree “in lavorazione” relative ai vari ambiti applicativi come, ad esempio, l’area afferente alla progettazione architettonica, alla progettazione strutturale, ecc.. In ciascuna di tali aree viene sviluppata la specifica parte del progetto e la documentazione prodotta, con le varie rilavorazioni e revisioni, permarrà all’interno dell’area fino al raggiungimento di un concordato grado di sviluppo, quando potrà essere resa disponibile agli altri team del progetto.
    Tuttavia, fino al raggiungimento di questa soglia di sviluppo, tutta la documentazione sarà utilizzabile esclusivamente dal team di tecnici di riferimento dell’area.
  2. Shared: è l’area in cui i vari team di progettazione depositano i successivi avanzamenti del proprio lavoro, nei vari stadi concordati di sviluppo, condividendoli: È da notare come in questa fase il progetto sia ancora in lavorazione e la documentazione ciclicamente depositata e prelevata dai vari team consente a tutti di allinearsi con rapidità alle eventuali modifiche e perfezionamenti apportate da ciascuno di essi.
  3. Published Documentation: è dove viene depositata la documentazione di progetto ultimata e condivisa dai vari team di progettazione e approvata dalla committenza; la documentazione depositata è adeguata alla fase realizzativa.
  4. Archive: è l’area in cui sono conservate le informazioni progettuali del manufatto come realizzato, ai fini della conservazione e disponibilità di tutte le relative informazioni, come dei requisiti progettuali, normativi e legali.

Il flusso delle informazioni nel “core” del Common Data Environment (CDE)

Come è gestito il flusso delle informazioni tra queste quattro aree?
È la BS 1192 a fornirci un semplice esempio, partendo dalla fase di progettazione architettonica.

Il team di progettazione architettonica, utilizzando la propria organizzazione (strumenti, software e consulenti esterni), avvia e sviluppa l’architettonico dell’edificio. In figura, a titolo di esempio, sono mensionati i muri, i pilastri, ecc.

CollaborativeWorking (2)

Figura 5 – CollaborativeWorking (2)

Durante tale attività si succederanno varie revisioni della documentazione, che saranno disponibili esclusivamente al team stesso. La documentazione prodotta sarà caratterizzata da un codice di idoneità (posto pari a “S0”, fin tanto che la documentazione è ad uso interno al team) e da un codice di versione, che viene aggiornato ad ogni progressivo aggiornamento (Pnn,nn).
Quando il grado di sviluppo raggiunge lo step concordato, dopo una fase di controllo e verifica di conformità ai requisiti cogenti e progettuali, la documentazione relativa viene spostata nell’area condivisa, Shared, ed il suo codice di idoneità viene aggiornato in S1 (idoneo al coordinamento).

 

CollaborativeWorking (3)

Figura 6 – CollaborativeWorking (3)

Il team di progettazione strutturale, procederà ad acquisire il progetto architettonico depositato nell’area Shared, per utilizzarlo come riferimento nella propria attività.

CollaborativeWorking (4)

Figura 7 – CollaborativeWorking (4)

La parte strutturale verrà quindi sviluppata dal team, in quanto legittimamente titolare di questa parte del progetto, a partire da quanto previsto in prima istanza dal team di progettazione architettonica. Si susseguiranno, naturalmente, vari aggiornamenti (contrassegnati, anche in questo caso, dal codice di idoneità “S0” e codice di versione “Pnn,nn”).

CollaborativeWorking (5)

Figura 8 – CollaborativeWorking (5)

Giunti ad una configurazione delle strutture tale da poter essere condivisa, i documenti del progetto strutturale (nell’esempio i pilastri) sono caricati nell’area Shared.

CollaborativeWorking (6)

Figura 9 – CollaborativeWorking (6)

Nell’area Shared, però, si avrebbe la contemporanea presenza di 2 documentazioni strutturali (nell’esempio i pilastri): quella prodotta dal team di progettazione architettonica e quella prodotta dal team di progettazione strutturale.

Essendo, evidentemente, questi ultimi i legittimi titolari di questa parte del progetto, la documentazione strutturale prodotta dai progettisti architettonici verrà rimossa, salvaguardando l’univocità delle informazioni contenute in Shared.

CollaborativeWorking (7)

Figura 10 – CollaborativeWorking (7)

Ma come chiarito efficacemente nella figura 10, a questo punto è il team architettonico che dovrà provvedere ad aggiornare la parte strutturale del suo progetto, prelevandola dall’area Shared, per poter poi proseguire nella propria attività.
Ad una valutazione sull’adottabilità della struttura predisposta dal team di progettazione strutturale, seguirà eventualmente un aggiornamento della parte architettonica, con una nuova revisione e un nuovo caricamento nell’area condivisa.

La metodica illustrata dalla norma BS 1192 a scopo esemplificativo, si presta facilmente ad essere estesa anche a tutti gli altri aspetti della progettazione, come mostrato nella seguente figura.

CollaborativeWorking (8)

Figura 11 – CollaborativeWorking (8)

Quando i tutti i cicli di implementazione saranno stati percorsi e tutti i documenti del progetto, coordinato e validato, saranno stati depositati nell’area Shared, la committenza dovrà esprimersi in merito ai risultati raggiunti dall’intero ufficio di progettazione.

La sua approvazione consentità la pubblicazione dei documenti (nell’apposita area “Published Documentation“) che, quindi, potranno essere utilizzati per la realizzazione dell’edificio.

Il modello virtuale secondo l’ AEC(UK) BIM Technology Protocol

In conclusione è interessante rilevare come la struttura funzionale illustrata così come suggerita nella BS 1192, è stata ripresa nel “AEC(UK) BIM Technology Protocol” (documento redatto dall’AEC (UK) Committee) e utilizzata efficacemente per realizzare un esempio di strutturazione di un archivio elettronico del progetto.

Struttura-Repository

Figura 12 – Struttura-Repository

 

Clicca qui per conoscere Edificius, il software BIM di ACCA

 

Vuoi rimanere aggiornato su questo argomento e sulle principali novità legate al mondo dell'edilizia?

Iscriviti GRATIS alla Newsletter

3 commenti

Trackbacks & Pingbacks

  1. […] la finalità e la corretta codificazione dei campi 9 e 10 invitiamo a leggere l’art. “Il BIM come flusso di informazione secondo le norme tecniche BS 1192 e PAS 1192-2“. In breve possiamo dire che il flusso delle informazioni che fluisce all’interno del […]

  2. […] Come abbiamo già visto, nella costruzione di un modello virtuale BIM è fondamentale stabilire qual è il corretto flusso di informazioni secondo le norme tecniche BS 1192 e PAS 1192-2. […]

  3. […] “Il BIM come flusso di informazioni secondo le norme tecniche BS 1192 e le Pas 1192-2” ci siamo occupati di BIM cercando di approfondirne il significato principalmente dal punto […]

Lascia un Commento

Vuoi partecipare alla discussione?
Fornisci il tuo contributo!

Lascia un commento

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *