BIM Pratica vs Teoria
Il mio ultimo post a tema BIM si concludeva con la frase: “se è vero che le basi teoriche sono splendide, non è tutto oro quel che luccica”, quindi where’s the catch?
La fregatura, al momento, sta proprio nella messa in pratica. I software attualmente in commercio non sono in grado di coprire la produzione e/o l’immagazzinamento di tante informazioni/oggetti esistenti nel mondo AEC, anzi risultano spesso limitati e limitanti.
Se da un lato il modello informativo, così come un modello economico, è creato mediante una semplificazione della realtà (vedi il mio articolo n.2 a riguardo), è altrettanto vero che i modelli informativi attualmente generati dai software di BIM Authoring sono spesso fin troppo semplificati, finendo per depauperare e circoscrivere le capacità e con esse lo scopo finale del modello stesso.
Cosa non funziona nei software attuali? La limitata presenza di classi di oggetto (vedi il mio articolo n.3 se vuoi approfondire questo tema), la poca plasticità dei comandi nel generare geometrie, la ridotta presenza dell’intelligenza artificiale nel coadiuvare la progettazione, la macchinosa gestione dei dati, la scarsa interoperabilità con software esterni a specifici ecosistemi e la considerevole presenza di bug (ormai insita in certi applicativi!).
Nella prassi professionale si è, volenti o nolenti, spesso portati a scendere a compromessi con queste mancanze trovando vari escamotage al fine di portare a compimento la commessa. Tuttavia, questa non dovrebbe essere la normalità, soprattutto se l’obiettivo è raggiungere un efficiente flusso di lavoro mediante il BIM. Sarebbe quindi auspicabile che le case software apportino consistenti migliorie nei programmi commercializzati. L’attuale reiterazione annuale di software leggermente aggiornati, ma venduti come nuove e strabilianti versioni di certo non cambierà la situazione.
Questa evoluzione dei software sarebbe ancor più che auspicabile (probabilmente inderogabile) se si vede la questione dal punto di vista dei progettisti. Dati alla mano, la più che considerevole mole di lavoro passata a raggirare le falle dei software ha un notevole impatto nell’efficienza operativa dei progettisti, specialmente nell’ottica in cui queste operazioni li porta ad allontanarsi da quello che è il loro scopo originario: la progettazione. Sembra lapalissiano dirlo, ma il fine del progettista è quello di pensare e creare ambienti che diano benessere ai futuri fruitori, non quello di improvvisarsi informatico suppletivo (e con questo potrei aprire un enorme parentesi su quella che è la perversa e fallace concezione della figura dei BIM Specialist nel mercato del lavoro contemporaneo, ma lascio questo argomento ad un futuro post).
Oltretutto, il cospicuo lasso di tempo perso nell’escogitare trick volti alla creazione di un modello informativo è concettualmente l’operazione più antitetica all’idea stessa di modello informativo che ci possa essere. Il modello informativo dovrebbe essere lo strumento che aggevola e non lo scopo del mio lavoro (come spesso in maniera disastrosa si tende a travisare).
Un esempio pratico, tra il serio e il faceto, può essere la modellazione dei battiscopa/zoccolini all’interno di un modello informativo di un complesso residenziale. Nell’esempio per creare il modello informativo utilizzerò Autodesk Revit, tuttavia si potrebbe fare la stessa procedura con Allplan della Nemetschek, e altri BIM Authoring, il risultato non cambierebbe.
Dunque, siamo in Revit, e dopo aver modellato tutti i muri è il momento di modellare i battiscopa. Dopo qualche ricerca ci si accorge facilmente che non esiste alcuna “famiglia battiscopa” nella “categoria muri” (in Revit le classi di oggetto vengono categorie, vedi il mio articolo n.3, ogni categoria è suddivisa in sottoinsiemi denominati famiglie). Provando a sfogliare le proprietà della famiglia “Muro di base” ci si accorge che non esiste alcuna stratigrafia dedicata a tale scopo tra quelle messe a disposizione da Revit (di seguito due immagini esplicative a riguardo). Il software di per sé non ha idea di cosa sia questo entità AEC.
Non esiste una famiglia battiscopa/zoccolino
Non esiste una stratigrafia battiscopa/zoccolino
A questo punto ci si trova a daver fare fronte a varie considerazioni per capire come risolvere questa mancanza, ad esempio ci si può chiedere: Che LOD ci è stato chiesto per il modello? Se faccio un computo delle quantità con il modello, il non modellare i battiscopa mi costa doverli computare manualmente? Se faccio dei render del modello da mostrare al nostro committente, non inserire un bel battiscopa nelle abitazioni potrebbe provocare delle rimostranze che ci costano la giusta remunerazione del lavoro svolto? Se si, scelgo di non modellare comunque i battiscopa e aggiungerli manualmente in Photoshop oppure modellarli comunque? Le domane possono essere davvero tante, le risposte altrettanto varie. Nell’esempio proposto ipotizziamo che il capitolato informativo ci richieda una progettazione full BIM è un modello informativo elaborato in LOD D, quindi il battiscopa deve esserci necessariamente come normativa UNI. A questo punto le soluzioni fattibili sono due: o istanzio un oggetto della famiglia “Muro di base”, alto 10 cm e spesso 1 e lo chiamo battiscopa, oppure uso una particolare famiglia di Revit chiamata “Estrusioni muro” (che mi permette di modellare generiche geometrie 3D associate a una famiglia muro) e chiamo l’oggetto creato battiscopa (di seguito due immagini di esempio di quanto appena detto).
Zoccolino modellato istanziando la famiglia “Muro di base”
Zoccolino modellato istanziando la famiglia “Estrusioni muro”
Ora, qualsiasi opzione scegliamo il risultato non cambierà, perché se da punto di vista prettamente geometrico entrambe risolvono il problema, ma da un punto di vista BIM (strumento modello informativo che è trasposizione virtuale di oggetti reali), ho creato degli oggetti piuttosto strani, perché non basta chiamare un muro o un oggetto generico “battiscopa” per far sì che quell’oggetto diventi un battiscopa virtuale, lo potranno essere per un lettore umano che interpreta il modello (mentalità CAD, vedi il mio articolo n.4) ma non per l’IA, che continuerà a leggerli o come muri molto piccoli o come generici oggetti tridimensionali indistinguibili da altri generici oggetti tridimensionali presenti nel modello (cosa in generale da non fare la creazione di oggetti generici). Qual è dunque la soluzione migliore? Non esiste, semplicemente bisognerà di volta in volta capire qual è la più consona rispetto al nostro problema e accordarla tra i vari attori del processo.
Di esempi come “il problema del battiscopa/zoccolino” se ne potrebbero fare tanti altri, tipo l’acquisizione nel modello informativo di dati provenienti da database esterni (prezziari, tempistiche, WBS, ecc.). Solitamente è molto difficile, se non impossibile, collegare la considerevole mole di dati in ingresso da queste fonti a specifiche proprietà del modello che possono essere direttamente o indirettamente corellate al dato esterno. Il piu delle volte i software attualmente a disposizione permettono semplicemente di scrivere i dati in maniera statica, copiando il dato esterno e immagazzinandolo in semplici parametri di testo. Ciò comporta che ad ogni ed eventuale variazione del modello non corrisponderà una altrettanta ed automatica variazione della voce importatata. Un esempio pratico può essere il cambio del tipo di muro, se io passo da un muro in cartongesso a un muro in blocchi di cemento, un'eventuale voce da prezziario importata per il cartongesso e scritta tra i valori di istanza, non cambierà se questa è stata assegnata in maniera statica,ne consegue chiaramente una considerevole probabilità di errori che possono venire a crearsi.
Quindi il problema in qualche modo si risolve, si dovrà sempre risolvere per poter completare una commessa, salvo decidere che a causa dei battiscopa (per citare il primo esempio) non consegniamo un progetto, però bisogna essere coscienti del caos che creiamo utilizzando soluzioni inesatte a livello informativo, al fine di:
- gestire in maniera ottimale uno sforzo di tempo ed energie assolutamente non marginale e in parte avulso da quello che è il fine di un attore del processo edilizio;
- comprendere che i modelli con simili soluzioni perdono tanta dell’interattività automatica e dell’assistenza al progettista per cui nascono (vedi articolo n.3) quindi necessitano di un maggior controllo umano, ergo è bene limitare al massimo il ricorso a classi oggetto generico e classi improprie per il nostro scopo;
Perché un maggior controllo umano? riprendendo l’esempio del battiscopa, per l’IA che gestisce il modello questi o sono muri o sono oggetti generici, quindi non li gestirà separatamente da altri oggetti muro o generici. Inoltre pensate a quanti se ne possono creare di oggetti battiscopa in un progetto di grandi dimensioni, sarà certamente difficolto gestirli manualmente. Non bisogna per di più dimenticare che va continuamente verificato, in caso di modifiche, che il fautore delle stesse abbia agito correttamente perché non sarà la macchina a controllare che il battiscopa rimanga battiscopa. Il problema non è fare un battiscopa, ma è dopo che cambieremo un progetto 50 volte che non sapremo più se i battiscopa disegnati in prima versione sono rimasti dei battiscopa. E chiaro dunque che se non usato con coscienza critica il modello informativo rischia moltiplicare i problemi anziché risolverli.
Alla luce di tutto ciò dovrebbe apparire abbastanza chiaro perché qualche riga piu su ho suggerito di non utilizzare oggetti generici in generale, perché se da un lato è vero che con degli oggetti della classe “generico”, che i software di BIM Authoring ci mettono a disposizione, ci si può far di tutto è altrettanto vero che per la IA un oggetto generico rimane un oggetto generico benché lo possiamo nominare “Caldaia” oppure “Finestra”. Utilizzare oggetti generici è come tornare alle geometrie anonime del CAD, significa debilitare il potere del modello.
In accordo a quanto detto, dunque, solo un cosciente ed oculato utilizzo dei software può far sì che lo strumento modello informativo generato funzioni e sia realmente performante ai fini della realizzazione di un cespite immobile.
In conclusione, potremmo chiederci quanto sia logico porre tutto ciò in capo a un professionista del settore edilizio specializzato nella progettazione/costruzione/gestione, ma probabilmente questa domanda va posta alle case software per capire il loro parere...