Ambiente di Condivisione Dati (ACDat/CDE)

L'Ambiente di Condivisione Dati — in italiano ACDat, dall'inglese Common Data Environment (CDE) — è la piattaforma tecnologica e organizzativa su cui si basa l'intero flusso informativo di un progetto BIM. Non si tratta semplicemente di un server condiviso o di un sistema di cloud storage: l'ACDat è un ambiente strutturato che governa la creazione, la revisione, l'approvazione e la distribuzione delle informazioni di progetto secondo regole predefinite.

La ISO 19650-1 definisce il CDE come "la singola fonte di informazioni concordata per qualsiasi progetto o asset, utilizzata per raccogliere, gestire e disseminare ogni contenitore informativo approvato attraverso un processo gestito". Questa definizione evidenzia due aspetti fondamentali: l'unicità della fonte (single source of truth) e la presenza di un processo gestito di validazione e approvazione.

In pratica l'ACDat può essere implementato attraverso piattaforme dedicate come Autodesk Construction Cloud (ACC), Trimble Connect, Aconex, Projectwise, usBIM.platform o altre soluzioni commerciali. Può anche essere implementato mediante una combinazione di strumenti — server, cartelle condivise, sistemi di gestione documentale — purché siano garantite le funzionalità essenziali: controllo degli accessi, gestione delle versioni, workflow di approvazione e tracciabilità delle operazioni.

L'importanza dell'ACDat nel processo BIM non può essere sottovalutata. Senza un ambiente di condivisione dati correttamente configurato e utilizzato, il lavoro collaborativo si riduce a uno scambio disordinato di file — esattamente la situazione che il BIM intende superare. L'ACDat garantisce che ogni membro del team lavori sulla versione corretta delle informazioni, che le modifiche siano tracciate e che le consegne avvengano in modo controllato.

La configurazione dell'ACDat è una delle prime attività operative di un progetto BIM e deve essere definita nel piano di gestione informativa (pGI). La struttura delle cartelle, i permessi di accesso, le regole di denominazione, i workflow di approvazione e le procedure di backup devono essere stabiliti prima dell'inizio delle attività progettuali e comunicati a tutti i soggetti coinvolti. Modifiche successive alla struttura dell'ACDat sono possibili ma costose, perché richiedono la riorganizzazione dei file esistenti e la riformazione del team.

Il flusso informativo nell'ACDat è organizzato in quattro stati — o aree — che rappresentano il livello di maturità e di approvazione delle informazioni. Questa struttura, definita dalla ISO 19650 e ripresa dalla UNI 11337, garantisce che le informazioni attraversino un processo di validazione prima di essere utilizzate ufficialmente. I quattro stati sono: lavorazione (work in progress), condivisione (shared), pubblicazione (published) e archiviazione (archived).

Lo stato di lavorazione è l'area in cui i singoli professionisti o i team disciplinari sviluppano i propri modelli e documenti. Le informazioni in quest'area sono considerate in fase di elaborazione e non possono essere utilizzate da altri team come base per il proprio lavoro. Ogni disciplina ha la propria area di lavorazione, con accesso limitato ai soli membri del team disciplinare. I file in questo stato possono essere modificati liberamente e non sono soggetti a procedure formali di approvazione.

Lo stato di condivisione è l'area in cui i team disciplinari pubblicano le versioni del proprio lavoro destinate alla visione e all'uso da parte degli altri team. Il passaggio dallo stato di lavorazione allo stato di condivisione avviene attraverso una verifica interna — il team disciplinare controlla la qualità del proprio modello prima di condividerlo. Le informazioni in quest'area possono essere utilizzate dagli altri team come riferimento, ma non hanno ancora lo status di informazione ufficiale approvata.

Lo stato di pubblicazione è l'area che contiene le informazioni ufficialmente approvate dal coordinatore o dal responsabile del progetto. Il passaggio dallo stato di condivisione allo stato di pubblicazione avviene attraverso una verifica interdisciplinare — il coordinamento verifica la coerenza e la completezza delle informazioni provenienti dai diversi team. Le informazioni pubblicate costituiscono la base ufficiale del progetto e sono quelle che vengono consegnate al committente.

Lo stato di archiviazione conserva le versioni superate delle informazioni e i documenti relativi al processo di gestione — verbali di riunione, report di clash detection, comunicazioni formali. L'archiviazione garantisce la tracciabilità del processo decisionale e consente di ricostruire la storia delle scelte progettuali. Ogni passaggio di stato viene registrato con data, autore e motivazione, creando un audit trail completo.

La gestione rigorosa di questi quattro stati è ciò che trasforma un semplice archivio condiviso in un vero ACDat. Senza questa struttura, il rischio è che i team lavorino su versioni non aggiornate delle informazioni o che utilizzino modelli non ancora verificati come base per le proprie attività, generando errori e incongruenze che si manifestano nelle fasi successive del progetto.

Le convenzioni di denominazione dei file sono un elemento apparentemente banale ma in realtà cruciale per il funzionamento efficiente dell'ACDat. In un progetto BIM complesso, il numero di file — modelli, elaborati, documenti — può raggiungere facilmente le diverse migliaia. Senza un sistema di denominazione chiaro e coerente, la ricerca e l'identificazione dei file diventano attività frustranti e soggette a errore.

La UNI 11337 e la ISO 19650 forniscono le linee guida per la struttura dei nomi dei file, che tipicamente includono campi codificati separati da trattini o underscore. Una struttura comune prevede i seguenti campi: codice progetto, codice fase, codice disciplina, codice zona o edificio, codice tipo documento, numero progressivo e codice stato (revisione). Ad esempio, un nome come "PRJ01-PD-ARC-ED01-MOD-001-S2" identifica il modello architettonico dell'edificio 01, fase progetto definitivo, revisione S2.

La coerenza nell'applicazione delle convenzioni è più importante della specificità delle convenzioni stesse. Un sistema di denominazione semplice ma applicato rigorosamente è preferibile a un sistema sofisticato ma applicato in modo disomogeneo. Per questo motivo è essenziale che le convenzioni siano definite nel pGI, spiegate a tutti i membri del team durante un kick-off meeting dedicato e verificate periodicamente durante il progetto.

Oltre alla denominazione dei file, la codifica degli oggetti all'interno dei modelli BIM è un tema altrettanto importante. Ogni oggetto deve essere identificabile attraverso un sistema di classificazione — come la UNI 8290, la Uniclass, la OmniClass o la classificazione specifica del progetto — che ne consenta la ricerca, il filtraggio e l'estrazione dei dati. La scelta del sistema di classificazione deve essere concordata nel capitolato informativo e applicata coerentemente da tutti i team disciplinari.

La gestione delle revisioni è strettamente legata alle convenzioni di denominazione. Ogni file nell'ACDat deve essere versionato secondo un sistema chiaro — tipicamente un codice alfanumerico progressivo — che consenta di distinguere le versioni in lavorazione (P01, P02...), le versioni condivise (S1, S2...) e le versioni pubblicate (A1, A2...). Il sistema di versionamento deve garantire che le versioni superate siano archiviate ma non eliminate, preservando la tracciabilità del processo.

Il concetto di LOD (Level of Development) è uno dei più discussi e fraintesi nel panorama BIM. Originariamente introdotto dall'AIA (American Institute of Architects) e poi adottato dalla norma UNI 11337-4, il LOD definisce il grado di affidabilità e completezza delle informazioni associate a un elemento del modello in una determinata fase del processo. Non si tratta semplicemente del "livello di dettaglio grafico", ma del livello di maturità complessiva dell'informazione — geometrica, alfanumerica e documentale.

La UNI 11337-4 articola il LOD su una scala dalla lettera A alla lettera G. Il LOD A corrisponde a un oggetto simbolico, utilizzato nelle fasi iniziali di studio di fattibilità. Il LOD B rappresenta un oggetto generico con dimensioni approssimative. Il LOD C definisce un oggetto con geometria definita e proprietà tecniche di massima. Il LOD D raggiunge il livello di dettaglio della progettazione esecutiva, con geometria precisa e proprietà complete. Il LOD E corrisponde al livello costruttivo e il LOD F all'as-built. Il LOD G è il livello di gestione e manutenzione, aggiornato durante la vita utile dell'opera.

Il LOIN (Level of Information Need), introdotto dalla norma EN 17412-1 e recepito nella revisione della ISO 19650, rappresenta un'evoluzione concettuale rispetto al LOD. Mentre il LOD tende a essere applicato in modo uniforme — "tutto il modello al LOD D" — il LOIN consente una definizione più granulare e orientata allo scopo. Il LOIN stabilisce il fabbisogno informativo per ciascun oggetto o gruppo di oggetti in relazione allo scopo specifico per cui l'informazione è necessaria.

Il LOIN si articola in tre componenti: il livello di dettaglio geometrico (LOG — Level of Geometry), il livello di informazione alfanumerica (LOI — Level of Information) e la documentazione associata. Questa scomposizione consente di calibrare con precisione il contenuto informativo richiesto: per uno studio di fattibilità energetica, ad esempio, potrebbe essere sufficiente un LOG basso (geometria semplificata) ma un LOI alto (trasmittanze, ponti termici), mentre per un rendering architettonico serve un LOG alto ma un LOI minimo.

La corretta definizione dei livelli informativi è un'attività critica nella redazione del capitolato informativo. Richiedere LOD troppo alti nelle fasi iniziali genera costi e tempi inutili; richiedere LOD troppo bassi nelle fasi avanzate compromette la qualità della documentazione. Il professionista deve saper bilanciare le esigenze informative del progetto con le risorse disponibili, utilizzando il LOIN come strumento per definire requisiti mirati e giustificati.

Nella pratica italiana, molti capitolati informativi utilizzano ancora il concetto di LOD della UNI 11337-4, ma il LOIN sta progressivamente guadagnando terreno, soprattutto nei progetti più complessi e nei contesti internazionali. I professionisti devono familiarizzare con entrambi i concetti e saper tradurre le richieste del committente in specifiche informative chiare e misurabili per il team di progettazione.

Il model checking è il processo di verifica e validazione dei modelli BIM attraverso strumenti automatici e semi-automatici. In un processo BIM maturo, i modelli non vengono semplicemente "guardati" per individuare errori: vengono sottoposti a controlli sistematici che verificano la conformità a regole predefinite — geometriche, informative e normative.

Si distinguono tre livelli di model checking. Il primo livello è la verifica formale (o BIM validation), che controlla la qualità tecnica del modello: presenza di duplicati, elementi sovrapposti, oggetti non assegnati a livelli, proprietà mancanti, geometrie invalide. Questo tipo di verifica viene eseguito internamente dal team disciplinare prima della condivisione del modello e può essere largamente automatizzato.

Il secondo livello è la verifica di interferenze (clash detection), che analizza le sovrapposizioni tra modelli disciplinari diversi. La clash detection viene eseguita sul modello federato — l'assemblaggio dei modelli architettonico, strutturale, impiantistico e degli altri modelli disciplinari — e produce report che elencano le interferenze individuate, classificate per gravità e responsabilità. Le interferenze vengono poi discusse nelle riunioni di coordinamento (coordination meeting) e assegnate ai team competenti per la risoluzione.

Il terzo livello è la verifica normativa (code checking), che controlla la conformità del modello alle norme tecniche applicabili — distanze minime, rapporti aeroilluminanti, accessibilità, requisiti antincendio. Questo tipo di verifica è il più complesso e il meno maturo dal punto di vista degli strumenti disponibili, ma rappresenta la frontiera più promettente del model checking, con il potenziale di automatizzare una parte significativa dell'attività di verifica progettuale.

I principali strumenti di model checking disponibili sul mercato includono Solibri Model Checker, Navisworks (Autodesk), BIMcollab, SimpleBIM e la piattaforma usBIM di ACCA software. Questi strumenti importano i modelli in formato IFC e applicano set di regole (ruleset) configurabili per le diverse tipologie di verifica. La scelta dello strumento e la definizione dei ruleset devono essere concordate nel piano di gestione informativa.

Il model checking non è un'attività da eseguire solo alla fine del processo, ma deve essere integrato nel flusso di lavoro come pratica continua. Verifiche frequenti — settimanali o bisettimanali — consentono di individuare e risolvere i problemi quando sono ancora gestibili, evitando l'accumulo di interferenze e incongruenze che alla fine del progetto diventano difficili e costose da risolvere. La frequenza e le modalità del model checking sono definite nel pGI e monitorate dal BIM Coordinator.