Software strutturali: la complessità del modello non è sinonimo di affidabilità

Negli ultimi anni la modellazione strutturale ha attraversato una trasformazione profonda: il modello di calcolo, un tempo strumento per produrre sollecitazioni e verifiche, si è progressivamente trasformato in un oggetto informativo, capace di raccogliere dati geometrici, materici e costruttivi lungo tutto il ciclo di vita dell'opera. A questo si è affiancato lo spostamento del baricentro professionale dal nuovo all'esistente, con la crescente complessità della valutazione della sicurezza e degli interventi di rinforzo, e una mole di output — dalle analisi non lineari alle fasi costruttive — che pone al progettista una domanda nuova: non più come calcolare, ma come interpretare.

È in questo scenario che si inserisce la nostra intervista a 2S.I., azienda che sviluppa e distribuisce PRO_SAP, software BIM/FEM per l'analisi e la progettazione di strutture in calcestruzzo armato, acciaio, muratura, legno e XLAM, ed entrata dal 2025 a far parte del gruppo Rocscience.

Con l'ing. Gennj Venturini, Technical Marketing Manager di 2S.I., abbiamo approfondito un nodo centrale del dibattito tecnico attuale: la sofisticazione di un modello non coincide automaticamente con la sua affidabilità. Un modello complesso, se costruito su parametri assunti per default o per analogia, non aggiunge informazione ma incertezza — e rischia di nasconderla dietro un risultato apparentemente più raffinato.

Da qui discendono temi che attraversano l'intera intervista: il ruolo del software nell'intercettare errori concettuali prima che nell'analisi, il confine tra assistenza tecnica e responsabilità progettuale, le procedure di validazione di algoritmi e solutori, e - non ultimo - il modo in cui l'automazione e l'intelligenza artificiale dovranno ridisegnare il rapporto tra strumento e professionista, distinguendo con chiarezza tra automazione dell'esecuzione e automazione della decisione.

Dal modello di calcolo al modello informativo: i tre cambiamenti che hanno ridisegnato la modellazione strutturale

Negli ultimi anni la modellazione strutturale ha conosciuto un'evoluzione molto rapida. Quali sono stati i cambiamenti più significativi nel modo di rappresentare le strutture e di utilizzare i software di calcolo?

I cambiamenti più rilevanti che ho osservato sono tre.

Il primo è il passaggio dal modello come oggetto di calcolo al modello come oggetto informativo. Fino a dieci anni fa il modello serviva quasi esclusivamente a produrre sollecitazioni e verifiche; oggi contiene informazioni geometriche, di materiale, di dettaglio costruttivo e viene interrogato in fasi diverse del progetto e della vita dell'opera.

Il secondo è lo spostamento del baricentro dell'attività professionale dal nuovo all'esistente. Il patrimonio costruito italiano ha imposto strumenti per la valutazione della sicurezza, la verifica degli interventi di rinforzo (incamiciature in acciaio e c.a., FRP, FRCM), i cinematismi nella muratura. È una modellazione che richiede scelte più delicate rispetto alla progettazione ex novo, perché il modello deve rappresentare una struttura che esiste già e di cui si ha conoscenza parziale.

Il terzo è la crescita della quantità di output da governare. L'analisi non lineare, le fasi costruttive, la storia di carico, i modelli con migliaia di elementi producono una mole di risultati che nessuno legge integralmente. Il problema non è più calcolare, ma capire quale parte del risultato è significativa e quale no.

Più complessità non è più affidabilità: i rischi di un modello sofisticato ma non governato

Una maggiore sofisticazione del modello corrisponde sempre a una maggiore affidabilità del risultato? Quali sono i rischi di una modellazione eccessivamente complessa o non adeguatamente governata dal progettista?

No, e ritengo che questo sia oggi il principale equivoco del settore.

L'affidabilità di un modello dipende dalla coerenza tra le ipotesi assunte e il comportamento reale dell'opera, non dal numero di gradi di libertà. Un modello sofisticato introduce parametri aggiuntivi (legami costitutivi non lineari, rigidezze di collegamento, molle di interazione terreno-struttura) ciascuno dei quali richiede una scelta del progettista. Se quei parametri sono assunti per default o per analogia, la complessità non aggiunge informazione: aggiunge incertezza, e la nasconde dietro un risultato apparentemente più raffinato.

I rischi concreti che riscontriamo più spesso sono:

• perdita di controllo sull'ordine di grandezza: il progettista non ha più un riferimento semplice con cui confrontare il risultato del calcolatore;
• sensibilità non indagata: il modello complesso restituisce risultati che variano molto al variare di un parametro assunto, e questa variabilità non viene esplorata;
• non ripetibilità: un modello con molte scelte implicite è difficile da rivedere, da verificare da parte di terzi e da mantenere nel tempo;
• disallineamento con il dettaglio costruttivo: si modella un comportamento che il dettaglio realizzato in cantiere non è in grado di garantire.

La nostra posizione è che la complessità del modello debba essere proporzionata alla domanda progettuale e al grado di conoscenza disponibile. Un modello semplificato, costruito consapevolmente e validato con un controllo di ordine di grandezza, è più affidabile di un modello raffinato non governato.

Controlli di congruenza, trasparenza sui default e lettura grafica: come il software intercetta l'errore concettuale

In che modo il software può aiutare il professionista a individuare errori concettuali, incoerenze o semplificazioni non compatibili con il comportamento reale dell'opera?

Il software non può sostituire il giudizio ingegneristico, ma può ridurre lo spazio in cui l'errore concettuale passa inosservato. Lo fa su tre livelli.

Controlli di congruenza sul modello. Verifica di labilità, elementi non connessi, elementi sovrapposti, vincoli mancanti, elementi con nodi intermedi. Sono controlli automatici che intercettano l'errore prima dell'analisi.

Trasparenza sulle assunzioni implicite. Ogni parametro assunto per default deve essere visibile e modificabile, e il software deve dichiarare esplicitamente quale ipotesi sta adottando. Un default nascosto è la principale fonte di errore non rilevato: il progettista non può controllare una scelta di cui non sa di aver delegato la decisione.

Rappresentazione grafica del risultato. La visualizzazione di deformate, diagrammi di sollecitazione, modi di vibrare e mappe di verifica è lo strumento diagnostico più efficace di cui il progettista dispone: un errore di vincolo o di rigidezza è quasi sempre evidente nella deformata prima che nei numeri. In PRO_SAP abbiamo investito molto sulla leggibilità immediata di questi output, proprio perché il controllo visivo è il primo filtro contro l'errore concettuale.

Restano invece integralmente in capo al progettista le scelte di schema statico, la definizione delle condizioni al contorno e la valutazione della ragionevolezza del risultato.

Assistenza tecnica e responsabilità progettuale: dove finisce il supporto del software, dove inizia la scelta del tecnico

Quanto è importante oggi l'assistenza tecnica fornita dalle aziende di software? Le richieste sono aumentate o diminuite? Dove termina l'assistenza sul software e dove inizia la responsabilità progettuale del tecnico?

Le richieste sono aumentate, ed è un dato che riteniamo fisiologico: aumentano le funzionalità disponibili, aumenta la complessità normativa, aumenta la quota di lavoro sull'esistente. In termini di tipologia, la maggior parte delle richieste riguarda l'uso funzionale del programma e l'impostazione operativa del modello; una quota minore riguarda l'interpretazione dell'output.

L'assistenza tecnica di 2S.I. interviene sull'uso funzionale del software e sulle segnalazioni. Non entra nel merito delle scelte progettuali.

Detto questo, riteniamo che la qualità dell'assistenza sia oggi un elemento distintivo quanto la qualità del solutore. Un software che il progettista non riesce a governare non produce sicurezza. Per questo affianchiamo al supporto diretto un percorso strutturato di formazione (documentazione, manuali, video-corsi) che ha l'obiettivo di rendere l'utente autonomo, non dipendente.

Benchmark, letteratura e riscontro sul campo: come si valida l'affidabilità di algoritmi e solutori

Quali procedure adottate per verificare l'affidabilità degli algoritmi, dei solutori e delle diverse funzioni del software? E come rendete queste attività conoscibili e verificabili dal professionista?

La validazione è un'attività continuativa e stratificata, non un adempimento una tantum. Le procedure che adottiamo sono:

• benchmark teorici su casi a soluzione analitica nota, per la verifica del solutore e degli elementi finiti;
• confronto con casi di letteratura e con risultati sperimentali documentati, in particolare per le analisi non lineari e per la muratura;
• comparazione con altri strumenti di calcolo su casi di riferimento;
• riscontro sui casi reali segnalati dagli utenti attraverso il canale di assistenza, che costituisce di fatto un banco di prova esteso e continuo.

Sul fronte della conoscibilità, mettiamo a disposizione del professionista la documentazione di affidabilità e i manuali tecnici con l'esplicitazione delle formulazioni adottate e i riferimenti normativi implementati. Riteniamo che il progettista debba poter risalire dalla verifica restituita dal software alla formulazione normativa che la genera: è la condizione minima perché possa assumersi consapevolmente la responsabilità del risultato.

Automazione dell'esecuzione sì, automazione della decisione con cautela: il rapporto tra IA e progettista

Con l'automazione e l'intelligenza artificiale, come deve evolvere il rapporto tra software e professionista? Quali competenze dovranno restare in capo al progettista e quali responsabilità dovranno assumersi le aziende che sviluppano strumenti sempre più autonomi e prescrittivi?

Il criterio che riteniamo corretto è distinguere tra automazione dell'esecuzione e automazione della decisione.

L'automazione dell'esecuzione (generazione della mesh, predimensionamento, ricerca di incongruenze, produzione degli elaborati, organizzazione dell'output) è un guadagno netto: libera tempo che il progettista può dedicare alle scelte concettuali, che sono la parte del lavoro dove si genera davvero valore e sicurezza.

L'automazione della decisione è un terreno diverso. Uno strumento che propone uno schema strutturale, seleziona un legame costitutivo o suggerisce un'ottimizzazione sta compiendo scelte di merito. In questo caso valgono due condizioni: la proposta deve essere sempre esplicita, tracciabile e modificabile, mai un default silenzioso; e il progettista deve poter ricostruire il criterio con cui la proposta è stata generata.

Le competenze che devono restare in capo al progettista sono quelle non delegabili: la comprensione del comportamento strutturale, la capacità di stimare l'ordine di grandezza del risultato atteso, il giudizio sulla compatibilità tra modello e realtà costruttiva.

Materiali integrati, normativa italiana e formazione continua: perché scegliere PRO_SAP e 2S.I.

Perché un professionista dovrebbe scegliere i vostri software e affidarsi ai vostri servizi? Quali elementi distintivi offrite in termini di affidabilità, trasparenza del calcolo, aggiornamento normativo, assistenza tecnica, formazione e supporto alla crescita professionale?

La nostra proposta si colloca in uno spazio preciso: strumenti accessibili che uniscano rapidità del flusso di lavoro e risultati validati.

Gli elementi che riteniamo distintivi sono:

• Gestione integrata dei materiali. Cemento armato, acciaio, muratura, legno e XLAM in un unico ambiente, con la verifica degli interventi di rinforzo su esistente e PRO_SAM per l'analisi non lineare della muratura. È una copertura che gli strumenti verticali non offrono e che nelle piattaforme internazionali richiede la composizione di più applicativi.
• Aderenza alla normativa italiana. Le NTC non sono un adattamento locale dell'Eurocodice: implementarle correttamente richiede un presidio normativo dedicato e continuativo, che manteniamo internamente.
• Trasparenza del calcolo e documentazione di affidabilità. Formulazioni esplicitate nella documentazione, riferimenti normativi tracciabili, output leggibile e verificabile.
• Assistenza rapida e competente: supporto sull'uso del software, nel rispetto della competenza del tecnico.
• Formazione continua, attraverso manuali, docum

• entazione e video-corsi, con l'obiettivo dell'autonomia dell'utente.

Dal 2025 2S.I. fa parte del gruppo Rocscience. È un passaggio che rafforza la struttura di sviluppo e amplia le competenze disponibili, in particolare sul fronte geotecnico, mantenendo il presidio italiano su normativa e assistenza.

---

Chi è 2S.I.

2S.I. sviluppa e distribuisce PRO_SAP, software BIM/FEM per l'analisi e la progettazione di strutture in cemento armato, acciaio, muratura, legno e XLAM, inclusi interventi di rinforzo e valutazione di edifici esistenti. Dal 2025 2S.I. fa parte del gruppo Rocscience, realtà internazionale specializzata in software geotecnici.