"Digital twin" è finita nella stessa categoria di "esperienza immersiva": si usa per qualunque modello 3D con sopra un logo. Capita di vedere presentati come twin dei fly-through registrati, cioè video.
La distinzione che usiamo noi è brutale e funziona: cosa posso cambiare, e cosa mi risponde il sistema? Se la risposta è "niente", è visualizzazione. Utile quanto vi pare, ma è un'altra cosa, e costa e vale diversamente.
Guardare e provare sono due prodotti diversi
Un modello navigabile è una visita. Si entra, si guarda, si esce. Va benissimo per vendere un appartamento o raccontare un bene culturale, e spesso è esattamente quello che serve.
Un twin è un banco di prova. Ha uno stato che cambia, riceve dati dall'esterno e reagisce a un'azione che modifica il risultato. Le tre cose insieme, non una sola.
È una distinzione che conviene fare prima di commissionare, perché cambia tutto: il budget, chi lavora al progetto, cosa si consegna e soprattutto chi deve mantenerlo acceso dopo.
Dati che entrano, decisioni che escono
La parte che quasi nessun capitolato specifica è il flusso.
In ingresso serve una sorgente dichiarata: sensori di campo, una simulazione, un modello BIM, un gestionale. E una frequenza: in tempo reale, ogni notte, a ogni revisione di progetto. Un twin alimentato una volta sola è una fotografia in 3D.
In uscita serve qualcosa che sopravviva alla sessione. Un export, un report, una configurazione salvata, un confronto tra due scenari. Se dopo un'ora di lavoro nel modello non resta un file, la decisione presa lì dentro non è tracciabile, e nelle organizzazioni una decisione non tracciabile è una decisione che non è stata presa.
È il punto che separa uno strumento da una demo. Le demo finiscono quando si toglie il visore.
Copenaghen: metti una barriera, guarda dove va l'acqua
Il programma ImmerseOn dell'Agenzia Spaziale Europea voleva verificare una cosa precisa: se mettere insieme dati satellitari e visualizzazione immersiva aiutasse le città a prepararsi agli eventi climatici. La domanda non era "si vede bene?", era "si decide meglio?".
Abbiamo costruito un'applicazione VR in Unity, sulla nostra piattaforma Explore, che ricostruisce una porzione di Copenaghen in scala 1:1 a partire da dati geografici e riprese aeree. Gli scenari di allagamento (mareggiate, innalzamento del mare al 2050 e al 2100, accumulo di pioggia) sono calcolati sui server dell'ESA; l'applicazione li riceve come mappe di altezza dell'acqua via API REST, in JSON, e li trasforma in una superficie che sale mentre la simulazione avanza.
Fin qui è visualizzazione, molto curata ma visualizzazione. Il salto è quello dopo.
L'utente posiziona barriere virtuali, dighe, argini, paratoie, e la simulazione ricalcola dove finisce l'acqua. Si confrontano affiancati lo scenario con e senza intervento. Più persone possono stare nello stesso ambiente e discutere mentre guardano la stessa strada allagarsi; le sessioni si registrano e le configurazioni si esportano per l'analisi ingegneristica.
Da "ecco cosa succederà" a "proviamo cosa succede se". È tutta lì la differenza.
Una nota sulla scala 1:1, che sembra un dettaglio estetico e non lo è. Una mappa colorata dice che in quella via ci saranno cinquanta centimetri d'acqua. Stare in piedi in quella via con cinquanta centimetri d'acqua è un'informazione diversa, e chi deve votare un investimento da qualche milione la riceve in modo diverso. Non è emozione: è capire dove arriva il livello rispetto a una soglia, a un quadro elettrico, alla rampa di un garage.
I sette requisiti di un twin che si usa
Questa è la lista che tiriamo fuori quando qualcuno ci chiede un digital twin, prima di parlare di tecnologia.
- Uno stato che cambia. Se la scena è sempre uguale, è un modello.
- Un input che l'utente controlla. Posizionare, spostare, sostituire, accendere. Qualcosa che sia una scelta, non una preferenza di visualizzazione.
- Una sorgente dati dichiarata, con la sua frequenza di aggiornamento scritta nero su bianco.
- Un'uscita che sopravvive alla sessione. Export, report, configurazione, confronto.
- Un contesto riconoscibile. Scala reale e punti di riferimento veri: servono a orientarsi e a fidarsi di quello che si vede.
- Prestazioni. In VR, sotto una certa soglia di frame rate, la gente si toglie il visore e il resto non conta. È un requisito funzionale, non una rifinitura.
- Qualcuno che lo mantiene. Un nome, dentro l'organizzazione, non nel contratto del fornitore.
Se ne mancano tre o quattro, quello che vi serve probabilmente è una bella visualizzazione: costa meno, si consegna prima e nessuno resta deluso.
Il costo vero è tenerlo vivo
Costruire un twin costa. Mantenerlo allineato costa di più, e quasi nessuno lo mette a budget.
La sorgente dati cambia formato. L'impianto viene modificato e il modello no. La persona che sapeva come funzionava cambia ruolo. Dopo un anno il twin mostra uno stato che non esiste più, qualcuno se ne accorge in riunione, e da quel momento non lo apre più nessuno. È il modo più comune in cui questi progetti muoiono: non con un errore, con l'obsolescenza silenziosa.
Due contromisure, entrambe organizzative più che tecniche. Decidere prima chi aggiorna e ogni quanto. E partire piccolo: un reparto, un edificio, un quartiere. Un twin ristretto e aggiornato batte sempre un twin completo e fermo al collaudo.
Una domanda per capirci in cinque minuti
Quando qualcuno ci chiede un digital twin, la prima domanda che facciamo è: quale decisione volete prendere guardandolo, e chi la prende?
Se la risposta arriva subito e contiene un nome e una scelta, dove mettiamo le barriere, quale layout di linea produciamo, in che ordine facciamo la manutenzione, allora il progetto ha un senso e sappiamo cosa costruire. Se la risposta è "far vedere ai clienti come siamo avanti", serve un altro lavoro, che sappiamo fare e costa molto meno.
Se il vostro twin non può essere smentito da nessuno, probabilmente non serve a decidere.
Lavoriamo su piattaforme XR e software 3D per industria, real estate e istituzioni: cosa facciamo con System, oppure raccontateci il caso e vi diciamo se vi serve un twin o altro.