| Incollo da una mail della Softing che ho ricevuto oggi:
Parliamo di BIM di Roberto Spagnuolo
Inizio questa nuova rubrica su FP nella quale mi riprometto di toccare quegli argomenti di ingegneria che spesso vengono visti solo dal lato tecnico e non da quello “politico”. E' chiaro che è molto più facile un dibattito tecnico, che si fa su temi e con strumenti consolidati, che un dibattito politico che richiede una visione più ampia e che, oltretutto, nel mondo dell'ingegneria si è sempre preferito non affrontare. Mi sono accorto che, probabilmente, sono il decano degli sviluppatori di software tecnico italiano. Dico probabilmente, perché nel mondo degli sviluppatori di software in campo tecnico vi è stata sempre un arcigno isolamento per cui non si sa molto dell'aspetto umano dei colleghi. Comunque, se non sono il decano, sono uno dei più “maturi” sviluppatori ancora sulla breccia del fare software e non solo del parlarne o del commercializzarlo. E qui faccio una precisazione che può essere utile. Progettare software e programmare sono due attività che stanno come l'architetto al muratore. Ovviamente non per fare una gerarchia di valori, ma di ruoli. E per progettare (bene) software bisogna saper programmare, ma non viceversa. E io sono uno dei (pochi e certo tra i più “maturi”) progettisti di software tecnico italiani. Dunque mi sento non solo autorizzato ma anche in dovere di dire la mia.
Un tema di fondo sul quale occorrerebbe ragionare più spesso è quello della normativa tecnica. Del fatto che sia assurdo che sia cogente, abbiamo già parlato spesso. Qui aggiungo che la normativa tecnica dal 2003 si è illusa di avere un substrato computazionale (chi l'ha redatta non conosceva e continua a non conoscere se non addirittura a rifiutare la meccanica computazionale) ma non lo ha formalmente recepito. Il confronto della Pubblica Amministrazione con la digitalizzazione è semplicemente penoso in tutte le sue manifestazioni. Anche in campo fiscale, dove ovviamente ci si è sforzati molto di più, si continuano a fare errori su errori. A vessare il contribuente con richieste che sarebbero inutili se solo si incrociassero i dati già in possesso del Fisco.
Bene, nel caso dell'ingegneria, la normativa ha fatto voto al santo protettore del modello matematico senza conoscerne il culto ma sperando egualmente nella sua intercessione. Il risultato è che abbiamo una generazione di ingegneri che conosce a mena dito la normativa ma che ha mandato in pensione il buon senso e la “sensibilità strutturale”. La meccanica computazionale si è ridotta a dimensione di normativa e quindi si è ridotta a foglio di calcolo perché la normativa dà formule, ma poi sui metodi computazionali fa voli e salti ridicoli perché neanche si accorge delle omissioni che compie in favore di formulette in confronto banali e ridicole. Che un elemento finito non passi un patch test non ha importanza, ma che il braccio delle forze interne per il taglio sia invariabilmente 0.9 l'altezza utile è sancito per legge quando non è minimamente vero.
Quali sono i danni collaterali di questa impostazione culturale imposta dalla normativa? Che oggi il progetto strutturale è più immagine che sostanza, è più burocrazia che conoscenza. E questo lo vediamo dappertutto. Ora lo vediamo anche nel BIM, che è il secondo tema di queste Chiacchiere.
Sul BIM su OpenBIM, su buildingSmart e IFC rimando ad altre fonti, magari, non ricordo, anche già su FB. Qui mi soffermo sul fatto che supportare la lettura o scrittura di un file IFC è oggi questione di programmazione e neanche troppo impegnativa visto che esistono librerie “free” che supportano le funzionalità principali di questo compito. Però si straparla di BIM perché è di moda. Lo è per chi vuol imporlo per ragioni di marketing, lo è per la Pubblica Amministrazione che anela a essere moderna ed efficiente con le penne di un pavone che non conosce e quindi spesso si fa bella con le penne di un pollo credendolo pavone. E non esagero.
Quello che non si è visto del BIM è l'aspetto “politico”. Precisiamo che l'IFC allo stato attuale allo strutturista non serve a molto ma, se ci fosse una visione “politica”, si vedrebbero almeno due aspetti importanti.
Primo aspetto. Un formato dati, un “linguaggio” per l'edilizia porterebbe ad una “interoperabilità” che consentirebbe l'uso di programmi di calcolo specializzati nelle varie funzioni. Si potrebbe usare SAP2000 per una analisi ed EasyBeam per il progetto delle armature. Si potrebbe trasmettere un file di risultati ottenuti con analisi non lineari in Nòlian al collega che usa un programma austriaco per le strutture in legno. E questo allo strutturista sarebbe più che utile, ed anche economico.
Secondo aspetto: la pratica digitale. Oggi in Italia per motivi biechi o di mancanza di coordinamento, ogni regione prevede il deposito del progetto secondo proprie modalità. E' ridicolo, ma chi lo dice a voce alta? Bene, l'IFC sarebbe un formato dati che contiene TUTTE le informazioni sul progetto dal quale la pubblica amministrazione potrebbe in qualsiasi momento estrarre TUTTI i dati per qualsiasi esigenza: dalla verifica alla consultazione degli esecutivi per eventuali futuri interventi. Tutto. E tutto non è poco! Ma chi glielo dice a voce alta? I soliti pochi, pochissimi. In italico stile, molti si lamentano, pochi si indignano. I più preferiscono andare a braccetto con il “potere”. Quando da queste pagine criticavo il SIERC mentre i miei “colleghi” già lo avevano recepito nel loro software passivamente, sembravo il solito “pierino”, cioè sciocco e noioso rompiscatole. Dove è finito il SIERC? Mi direte che ha fatto una brutta fine per motivi formali dell'appalto. Può essere, ma questo accade quando la comunità tutta dei tecnici attraverso ordini, sindacati, associazioni, tace e quando i professionisti, le softwarehouse che da decenni lavorano al servizio dell'ingegneria strutturale non sono neanche interpellate. Avrei voglia di dire: ben gli sta! per fare un po' davvero il “pierino” ma paghiamo sempre e solo noi... E vedrete che il tonfo di questi sistemi fatti senza una profonda, matura conoscenza dei problemi, sarà prima o poi un bel tonfo. E pensare che basterebbe l'IFC e qualche buon progettista di software. Ma pensate ad una fabbrica di cioccolatini che riesce a fare solo prodotti mediocri e vede una piccola cioccolataia che ne fa di ottimi. Cosa gli conviene fare? Andare dalla piccola cioccolataia, farsi dare la ricetta e aumentare la qualità oppure far chiudere il negozio alla piccola cioccolataia in modo che nessuno, nel confronto, si accorga che i suoi prodotti sono mediocri? Per questo alla Pubblica Amministrazione non conviene interpellare i piccoli cioccolatai bravissimi che da anni fanno software italiano per l'ingegneria italiana.
Dunque l'IFC, cioè un formato ormai affermato, di dati per l'edilizia è una soluzione ottima, economica, che già esiste. Cosa manca all’IFC oggi? Manca un modello dati per l'analisi sismica. Direte che non è poco. Concordiamo anche se non ci è chiaro il motivo per cui se ne sia accorta solo la Softing. O forse, ci è chiaro: noi siamo quelli che fanno ottimi cioccolatini! Fatta questa scoperta, ci siamo rimboccati le maniche ed abbiamo scritto le specifiche in EXPRESS (modalità standard di openBIM) per supportare l'analisi sismica nel formato IFC. Lo abbiamo fatto, non abbiamo solo detto che sarebbe utile farlo. Ci siamo “sporcati le mani” e non abbiamo solo pronunciato auli discorsi nei soliti convegni.
Il documento è lì, autori Amedeo Farello, responsabile dello sviluppo software di Softing, e lo scrivente. Stiamo ora operando perché sia recepito dal comitato buildingSmart. Fate il tifo per noi, che, se la faccenda riuscissimo a farla accettare a livello europeo, sarebbe un buon risultato per tutti ed anche per la bistrattata informatica italiana.
|
|
.