Digital Twin

Executive summary

Nella produzione industriale, nella gestione delle infrastrutture e in numerosi altri settori, comprendere in anticipo il comportamento di un sistema fisico complesso consente di prevenire guasti, ridurre i costi operativi e migliorare la qualità dei processi. La replica digitale di un sistema reale, costantemente aggiornata con i dati provenienti dal sistema stesso, rappresenta una delle risposte tecnologiche più studiate a questa esigenza. Questo articolo analizza le architetture, i modelli matematici e gli standard internazionali che rendono possibile la costruzione di queste repliche digitali, esaminando sia le soluzioni disponibili sia le sfide ancora aperte. Dall'analisi emerge che i risultati più significativi si ottengono quando i modelli matematici tradizionali vengono combinati con tecniche di apprendimento automatico, ma che la distanza tra i prototipi di ricerca e le implementazioni operative in produzione resta un problema concreto da affrontare.

Background

Il concetto di digital twin affonda le proprie radici nel paradigma della gestione del ciclo di vita del prodotto (Product Lifecycle Management). Nel 2002, Michael Grieves formalizzò per la prima volta l'idea di una rappresentazione digitale informativa di un sistema fisico, legata bidirezionalmente al suo corrispettivo reale attraverso flussi di dati continui [1]. La formulazione originale, denominata "Conceptual Ideal for PLM", conteneva già gli elementi fondamentali del paradigma: uno spazio fisico, uno spazio virtuale, un collegamento per il flusso dati dal reale al virtuale e un collegamento inverso per il flusso informativo dal virtuale al reale [1]. Il termine "digital twin" fu coniato nel 2010 da John Vickers, ingegnere della NASA, durante una collaborazione con Grieves [1].

La formalizzazione tecnica del concetto in ambito ingegneristico si deve in larga misura a Glaessgen e Stargel, che nel 2012 proposero il paradigma del digital twin per i veicoli aerospaziali della NASA e della U.S. Air Force [2]. In questa formulazione, il digital twin integra simulazioni ad altissima fedeltà con il sistema di gestione della salute strutturale del veicolo (Integrated Vehicle Health Management), la storia manutentiva e tutti i dati storici e di flotta disponibili, con l'obiettivo di rispecchiare la vita operativa del gemello fisico e abilitare livelli senza precedenti di sicurezza e affidabilità [2]. Questa visione spostò il digital twin dal dominio concettuale a quello dell'ingegneria dei sistemi complessi, stabilendo un nesso diretto tra modellazione computazionale, acquisizione dati in tempo reale e decisioni operative.

Nel decennio successivo, il concetto si è esteso ben oltre l'ambito aerospaziale. Rasheed, San e Kvamsdal definiscono il digital twin come "un modello adattivo di un sistema fisico complesso", abilitato da dati e simulatori per la predizione in tempo reale, l'ottimizzazione, il monitoraggio, il controllo e il supporto alle decisioni [3]. La progressiva convergenza tra capacità computazionali, solutori multifisica, intelligenza artificiale e infrastrutture per la gestione dei dati ha reso il paradigma tecnicamente realizzabile su scala industriale [3]. Jones et al., attraverso una revisione sistematica della letteratura su 92 pubblicazioni, hanno identificato 13 caratteristiche distintive del digital twin e sette lacune di conoscenza prioritarie, evidenziando la necessità di fondamenta condivise per orientare la ricerca futura [4].

Il rapporto della National Academies of Sciences, Engineering, and Medicine pubblicato nel 2024 ha ulteriormente inquadrato lo stato del campo, definendo il digital twin come un sistema che accoppia modelli computazionali a un corrispettivo fisico, aggiornato dinamicamente attraverso flussi di dati bidirezionali al variare delle condizioni operative [5]. Il rapporto sottolinea la necessità di separare le affermazioni aspirazionali dai risultati effettivamente dimostrati, per rafforzare la credibilità della ricerca nel settore [5].

Architettura e modelli di riferimento

Il modello a cinque dimensioni

Il framework architetturale più influente nella letteratura è il modello a cinque dimensioni proposto da Tao et al. nel 2019 [6]. Questo modello identifica cinque componenti fondamentali di un digital twin completo: l'entità fisica (Physical Entity, PE), l'entità virtuale (Virtual Entity, VE), le connessioni (Connection, CN), i dati del digital twin (DT Data) e i servizi (Services, SS). L'entità fisica comprende l'asset reale con i suoi sensori, attuatori e controllori. L'entità virtuale è il modello computazionale che replica il comportamento del sistema fisico in uno spazio digitale. Le connessioni garantiscono la sincronizzazione bidirezionale tra i due spazi. I dati del digital twin costituiscono il fondamento per la generazione di nuova conoscenza, integrando dati provenienti da sensori, simulazioni, modelli analitici e fonti esterne. I servizi rappresentano l'interfaccia attraverso cui il digital twin fornisce valore operativo: monitoraggio, predizione, ottimizzazione, supporto decisionale [6].

graph TB
    PE["Physical Entity (PE)<br/>Asset, sensori, attuatori"] 
    VE["Virtual Entity (VE)<br/>Modello computazionale"]
    CN["Connection (CN)<br/>Sincronizzazione bidirezionale"]
    DD["DT Data<br/>Sensori + simulazioni + analytics"]
    SS["Services (SS)<br/>Monitoraggio, predizione, ottimizzazione"]

    PE <-->|"Flusso dati"| CN
    CN <-->|"Flusso informativo"| VE
    PE --> DD
    VE --> DD
    DD --> SS
    SS --> VE
    SS --> PE

Figura 1, Architettura a cinque dimensioni del digital twin secondo Tao et al. [6].

La forza di questo modello risiede nella sua generalità: si applica tanto a un componente meccanico quanto a un'intera linea di produzione. Tuttavia, la sua natura astratta lascia aperti problemi implementativi significativi, in particolare sulla granularità della sincronizzazione, sulla gestione della consistenza tra dati eterogenei e sull'orchestrazione dei servizi in contesti multi-twin [6].

Lo standard ISO 23247

Lo standard ISO 23247, pubblicato nel 2021, fornisce un framework normativo per i digital twin nel contesto manifatturiero [7]. Lo standard si articola in quattro parti: la Parte 1 definisce i principi generali e i requisiti; la Parte 2 propone un'architettura di riferimento con viste funzionali; la Parte 3 elenca gli attributi informativi di base per gli elementi manifatturieri osservabili; la Parte 4 specifica i requisiti tecnici per lo scambio informativo tra entità [7, 8].

L'architettura di riferimento di ISO 23247 si struttura attorno a quattro entità funzionali: l'entità di raccolta dati (Data Collection Entity), che acquisisce informazioni dall'elemento manifatturiero osservabile; l'entità dispositivo (Device Communication Entity), che gestisce la comunicazione tra il mondo fisico e il digital twin; l'entità nucleo del digital twin (Digital Twin Entity), che contiene i modelli e la logica di sincronizzazione; l'entità utente (User Entity), che fornisce l'interfaccia verso le applicazioni e gli operatori [8]. Lo standard definisce un "Digital Twin in Manufacturing" come una "rappresentazione digitale fit for purpose di un elemento manifatturiero osservabile, con sincronizzazione tra l'elemento e la sua rappresentazione digitale" [7].

Un aspetto rilevante è l'evoluzione in corso: la Parte 6, attualmente in fase di Draft International Standard, affronta il tema della composizione di digital twin, definendo principi e metodologie per la configurazione, la comunicazione, la combinazione e la collaborazione tra twin multipli [7]. Questo sviluppo riflette la crescente necessità di architetture federate, in cui digital twin di componenti, sottosistemi e sistemi interagiscono in modo coerente.

L'analisi condotta dal NIST sullo standard evidenzia che ISO 23247 fornisce una guida generica applicabile a processi manifatturieri discreti, batch e continui, ma lascia margini significativi per l'interpretazione implementativa, il che può rappresentare sia un punto di forza (flessibilità) sia un limite (ambiguità nelle scelte progettuali) [8].

Modelli computazionali: dall'approccio fisico al data-driven

La costruzione del nucleo computazionale di un digital twin implica una scelta architetturale fondamentale tra tre paradigmi: modelli basati sulla fisica (physics-based), modelli guidati dai dati (data-driven) e modelli ibridi che combinano entrambi gli approcci. La scelta dipende dalla disponibilità di equazioni governanti, dalla quantità e qualità dei dati osservati e dai requisiti di accuratezza, latenza e interpretabilità del caso d'uso specifico.

Modelli physics-based

I modelli physics-based si fondano sulla formulazione matematica delle leggi fisiche che governano il sistema: equazioni differenziali ordinarie e alle derivate parziali, modelli agli elementi finiti (FEM), fluidodinamica computazionale (CFD), modelli termici e strutturali. Questi approcci offrono alta interpretabilità e la capacità di estrapolare il comportamento del sistema in condizioni non osservate, a patto che le equazioni governanti siano note e ben poste [3]. Il limite principale è il costo computazionale: una simulazione FEM ad alta fedeltà di un componente aeronautico può richiedere ore o giorni di calcolo, rendendola incompatibile con i requisiti di sincronizzazione in tempo reale tipici di un digital twin operativo [2, 3].

Per mitigare questo problema, la letteratura ha sviluppato tecniche di riduzione dell'ordine del modello (Reduced-Order Models, ROM), che proiettano la dinamica del sistema su un sottospazio a bassa dimensionalità, preservando le caratteristiche essenziali del comportamento con un costo computazionale ridotto di ordini di grandezza [9]. I ROM consentono di eseguire simulazioni quasi in tempo reale, ma introducono errori di approssimazione che devono essere quantificati e controllati, specialmente in applicazioni safety-critical.

Modelli data-driven

All'estremo opposto dello spettro, i modelli data-driven apprendono il comportamento del sistema direttamente dai dati osservati, senza richiedere la formulazione esplicita delle equazioni fisiche. Reti neurali profonde, modelli di regressione, tecniche di apprendimento per rinforzo e metodi statistici consentono di catturare relazioni complesse e non lineari tra variabili di input e output del sistema [9]. Il vantaggio è la flessibilità: un modello data-driven può essere addestrato su qualsiasi sistema per cui siano disponibili dati sufficienti, indipendentemente dalla complessità delle equazioni governanti sottostanti.

I limiti sono speculari rispetto ai modelli fisici: la capacità di estrapolazione è generalmente limitata al dominio dei dati di addestramento; l'interpretabilità è ridotta, il che rende difficile diagnosticare errori o garantire il comportamento in condizioni anomale; la dipendenza dalla quantità e qualità dei dati è elevata [3, 9]. In contesti industriali, dove le condizioni operative possono variare significativamente rispetto al regime nominale, si pensi a guasti incipienti, transitori di avvio, condizioni ambientali estreme, un modello puramente data-driven rischia di produrre predizioni inaffidabili proprio nelle situazioni in cui il digital twin è più necessario.

Modelli ibridi e Physics-Informed Neural Networks

L'approccio più promettente nella letteratura recente è l'integrazione dei due paradigmi attraverso modelli ibridi. Le Physics-Informed Neural Networks (PINN) rappresentano la formalizzazione più studiata di questa integrazione: la conoscenza fisica viene incorporata nel processo di apprendimento sotto forma di vincoli nel termine di loss della rete neurale, combinando il residuo delle equazioni differenziali con l'errore sui dati osservati [10, 11].

Yang et al. hanno proposto il framework Data-Driven Physics-Informed Neural Networks (DD-PINN), specificamente orientato alla realizzazione di digital twin [10]. Il framework è stato validato su equazioni di Navier-Stokes parametriche, dimostrando che le PINN non necessitano di riaddestramento al variare del numero di Reynolds, una proprietà cruciale per digital twin che devono operare su un range di condizioni operative. Particolarmente significativo è il risultato sulle DD-PINN multi-fidelity, che integrano dataset acquisiti a diversi livelli di fedeltà e sparsità: queste mostrano un miglioramento del 42-62% nelle prestazioni predittive rispetto all'approccio single-fidelity, anche in task di estrapolazione [10]. Il framework include inoltre la quantificazione dell'incertezza attraverso metodi ensemble, una capacità essenziale per digital twin in contesti decisionali critici [10].

La review di Chen et al. del 2026 sistematizza l'integrazione tra fisica e intelligenza artificiale nei digital twin attraverso un framework a quattro stadi: modellazione del gemello fisico tramite approcci physics-informed, mirroring nel simulatore digitale con sincronizzazione in tempo reale, intervento tramite modellazione predittiva e ottimizzazione, gestione autonoma tramite foundation model e agenti intelligenti [9]. Tra le tecniche emergenti, i Neural Operator (DeepONet, Fourier Neural Operator) e lo Sparse Identification of Nonlinear Dynamics (SINDy) offrono vie complementari per apprendere operatori che mappano tra spazi funzionali, con speedup di ordini di grandezza rispetto ai solutori numerici convenzionali [9].

Figura 2, Spettro dei modelli computazionali per digital twin.

Piattaforme cloud e implementazione

L'implementazione di digital twin su scala industriale richiede infrastrutture capaci di gestire l'ingestione di dati da migliaia di sensori, l'esecuzione di modelli computazionali, la persistenza dello stato e l'integrazione con sistemi enterprise esistenti. I principali cloud provider hanno sviluppato servizi dedicati che incarnano architetture di riferimento distinte.

Azure Digital Twins

Azure Digital Twins è un'offerta Platform-as-a-Service (PaaS) di Microsoft che consente la creazione di grafi di twin basati su modelli digitali di ambienti completi: edifici, stabilimenti, reti energetiche, infrastrutture ferroviarie, intere città [12]. L'architettura si fonda su tre elementi centrali. Il primo è il Digital Twins Definition Language (DTDL), un linguaggio di modellazione basato su JSON-LD che definisce i tipi di entità secondo proprietà di stato, componenti e relazioni. Il secondo è il grafo dei twin (twin graph), una struttura a grafo in cui i nodi rappresentano istanze di twin e gli archi le relazioni tra essi. Il terzo è il sistema di event routing, che propaga le modifiche di stato verso servizi downstream attraverso Event Hubs, Event Grid e Service Bus [12].

L'integrazione con IoT Hub consente la connessione diretta con dispositivi IoT e IoT Edge, mentre le API REST e i connettori verso Logic Apps abilitano l'ingestione di dati da sistemi di business. Il servizio supporta la storicizzazione automatica dei dati verso Azure Data Explorer e l'interrogazione del grafo tramite un linguaggio di query dedicato [12]. Un aspetto architetturalmente rilevante è la separazione tra il piano di modellazione (definizione dei tipi tramite DTDL e ontologie di settore) e il piano di istanziazione (creazione dei twin e del grafo delle relazioni), che favorisce il riuso dei modelli e l'adozione di vocabolari condivisi.

AWS IoT TwinMaker

AWS IoT TwinMaker adotta un'architettura entity-component per la rappresentazione dei sistemi fisici [13]. Il modello concettuale si articola in tre fasi: connect (connessione alle sorgenti dati), model (modellazione tramite entità e componenti organizzati in un knowledge graph) e compose (composizione di scene 3D e dashboard per la visualizzazione) [13]. Il knowledge graph di TwinMaker consente di rappresentare le relazioni gerarchiche e topologiche tra gli asset fisici, mentre i componenti incapsulano la logica di accesso ai dati provenienti da sorgenti eterogenee: serie temporali da AWS IoT SiteWise, dati da Amazon S3, risultati di simulazioni [13].

Considerazioni architetturali trasversali

Le due piattaforme riflettono approcci progettuali complementari. Azure Digital Twins enfatizza la modellazione semantica tramite un linguaggio dedicato (DTDL) e un grafo dei twin come struttura dati centrale, favorendo scenari in cui la complessità relazionale tra entità è elevata. AWS IoT TwinMaker privilegia la composibilità tramite un pattern entity-component e l'integrazione nativa con i servizi di data analytics dell'ecosistema AWS [13].

In entrambi i casi, l'adozione di una piattaforma cloud introduce vincoli di vendor lock-in che devono essere valutati rispetto ai benefici di time-to-market e riduzione della complessità operativa. Lo standard ISO 23247 fornisce un framework di riferimento indipendente dal fornitore, ma la distanza tra l'architettura astratta dello standard e l'implementazione concreta su una piattaforma specifica rimane significativa [7, 8]. Per implementazioni mission-critical, è opportuno progettare un livello di astrazione intermedio che isoli la logica applicativa dalla piattaforma sottostante, preservando la portabilità.

Sincronizzazione in tempo reale e edge computing

La sincronizzazione bidirezionale tra il sistema fisico e il suo gemello digitale rappresenta il requisito architetturale più critico e, al contempo, la sfida tecnica più complessa. Un digital twin che non riflette lo stato corrente del sistema fisico con latenza accettabile si riduce a un modello statico, perdendo la caratteristica distintiva del paradigma [3, 5].

Architettura del flusso dati

Il flusso dati tipico di un digital twin industriale si articola su tre livelli. Al livello di campo (field layer), sensori, attuatori, PLC e macchinari industriali generano dati continui su grandezze fisiche: temperatura, vibrazione, coppia, portata, consumo energetico. Al livello di edge, dispositivi di edge computing eseguono il preprocessing locale, filtraggio del segnale, aggregazione temporale, rilevamento di anomalie a basso livello, imputazione di valori mancanti, riducendo il volume di dati trasmessi e la latenza [14]. Al livello cloud o on-premise, il modello computazionale del digital twin riceve i dati preprocessati, aggiorna il proprio stato interno e produce output predittivi, diagnostici o di ottimizzazione.

graph LR
    subgraph "Field Layer"
        S1["Sensori"] 
        A1["Attuatori"]
        PLC["PLC"]
    end
    subgraph "Edge Layer"
        EP["Preprocessing<br/>Filtraggio, aggregazione,<br/>anomaly detection"]
    end
    subgraph "Cloud / On-Premise"
        DT["Digital Twin<br/>Modello computazionale"]
        AN["Analytics & Servizi<br/>Predizione, ottimizzazione"]
    end

    S1 --> EP
    PLC --> EP
    EP -->|"Dati preprocessati"| DT
    DT --> AN
    AN -->|"Comandi, setpoint"| A1
    DT -->|"Feedback"| EP

Figura 3, Architettura a tre livelli per la sincronizzazione di un digital twin industriale.

La scelta della frequenza di sincronizzazione dipende dalla dinamica del processo monitorato. Un digital twin di un processo chimico continuo può richiedere aggiornamenti ogni pochi secondi, mentre un digital twin strutturale per la manutenzione predittiva può operare con cicli di minuti o ore. La letteratura recente riporta latenze dell'ordine di 42 ms per architetture che combinano edge computing locale e co-simulazione distribuita [14], un valore compatibile con applicazioni di controllo in closed-loop per processi con dinamiche dell'ordine del secondo.

Sfide di sincronizzazione

La sincronizzazione bidirezionale in tempo reale è limitata da larghezza di banda, latenza di rete e integrità dei dati [14]. In ambienti industriali con centinaia o migliaia di sensori, il volume aggregato di dati grezzi può saturare la capacità di trasmissione, rendendo necessarie strategie di compressione, campionamento adattivo e comunicazione event-driven (trasmissione solo al verificarsi di variazioni significative). La consistenza temporale tra dati provenienti da sorgenti diverse, sensori con clock non sincronizzati, ritardi di trasmissione variabili, buffer di diversa profondità, introduce ulteriori complessità che richiedono meccanismi di time-stamping e allineamento temporale robusti.

Quattro criteri misurabili emergono dalla letteratura per valutare la fedeltà della sincronizzazione: la fedeltà di stato (corrispondenza tra stato fisico e stato del modello), la tempestività della sincronizzazione (latenza massima tollerabile), il mirroring comportamentale (capacità del modello di replicare la dinamica del sistema fisico) e la validazione in condizioni di failover (comportamento del twin in caso di interruzione del flusso dati) [14].

Limiti e problemi aperti

Scalabilità e composizione

La scalabilità rappresenta una sfida persistente quando il digital twin si estende dal singolo componente all'intero sistema produttivo o, nel caso delle smart city, a infrastrutture urbane complete. Il volume e la complessità dei dati crescono in modo non lineare con il numero di entità modellate, e le piattaforme devono scalare dinamicamente senza degradazione delle prestazioni [15]. La composizione di digital twin multipli, ciascuno sviluppato indipendentemente per un sottosistema, introduce problemi di coerenza semantica, sincronizzazione temporale e gestione dei conflitti tra modelli con assunzioni diverse [15].

Interoperabilità

L'interoperabilità tra digital twin sviluppati con tecnologie, standard e piattaforme diverse resta un problema largamente irrisolto [15]. I sistemi legacy presentano difficoltà nell'armonizzare dati provenienti da formati incompatibili e standard di comunicazione eterogenei. Soluzioni basate su middleware con API standardizzate e ontologie di dati sono state proposte, ma la loro adozione è ostacolata dall'assenza di regolamentazione unificata e da impedimenti proprietari [15]. Lo standard ISO 23247 affronta parzialmente il problema definendo un framework comune, ma non prescrive protocolli specifici né formati di scambio dati interoperabili a livello implementativo [7, 8].

Validazione e quantificazione dell'incertezza

La validazione di un digital twin è intrinsecamente più complessa rispetto alla validazione di un modello di simulazione tradizionale, poiché il twin evolve nel tempo e la sua accuratezza dipende dalla qualità dei dati in ingresso, dalla fedeltà del modello e dall'efficacia della sincronizzazione. Il rapporto della National Academies sottolinea la difficoltà nel separare le affermazioni aspirazionali dai risultati effettivamente dimostrati [5]. La quantificazione dell'incertezza, attraverso metodi Monte Carlo, inferenza bayesiana e analisi di sensibilità, resta essenziale per garantire l'affidabilità del twin in applicazioni safety-critical, ma aggiunge un livello di complessità computazionale significativo [9, 10].

Sicurezza e privacy

Un digital twin che replica fedelmente un sistema fisico critico, un impianto di produzione, una rete energetica, un dispositivo medicale, diventa esso stesso un asset da proteggere. L'accesso non autorizzato al twin può esporre informazioni operative sensibili, mentre la compromissione del flusso dati bidirezionale può alterare le decisioni basate sul modello. La letteratura recente esplora l'integrazione di federated learning e tecniche privacy-preserving per consentire l'addestramento distribuito dei modelli senza centralizzare i dati grezzi [14, 15].

Distanza tra ricerca e produzione

Nonostante i progressi architetturali e algoritmici, il gap tra i prototipi di ricerca e le implementazioni in produzione rimane significativo. L'implementazione di un digital twin operativo richiede competenze multidisciplinari, ingegneria del dominio, modellazione computazionale, data engineering, infrastruttura cloud, sicurezza, e un investimento iniziale che la letteratura industriale quantifica nell'ordine di 200.000-600.000 USD per progetti pilota mirati, con tempi di ritorno dell'investimento tra 18 e 36 mesi [16]. La maturità tecnologica varia considerevolmente tra settori: aerospazio, automotive e utilities energetiche presentano tassi di adozione superiori al 70% per progetti pilota o in produzione, mentre altri settori sono ancora in fase esplorativa [16].

Implicazioni pratiche

L'adozione di un digital twin in contesto industriale richiede una valutazione sistematica che bilanci il potenziale valore operativo con la complessità implementativa. Le evidenze disponibili suggeriscono linee guida concrete per la progettazione e il deployment.

La scelta del modello computazionale deve essere guidata dal caso d'uso, non dalla tecnologia disponibile. Per sistemi le cui equazioni governanti sono note e ben caratterizzate, processi termodinamici, strutture meccaniche, circuiti elettrici, i modelli physics-based o i ROM offrono maggiore robustezza e interpretabilità. Per sistemi con dinamiche complesse e difficilmente formalizzabili, processi chimici con interazioni non lineari multiple, sistemi biologici, comportamento aggregato di flotte, i modelli data-driven o ibridi rappresentano l'alternativa più pragmatica [3, 9, 10].

L'architettura della sincronizzazione deve essere dimensionata sulla dinamica del processo e non sul massimo tecnicamente ottenibile. Una sincronizzazione più frequente del necessario genera costi infrastrutturali senza valore aggiunto, mentre una sincronizzazione insufficiente degrada la qualità predittiva del twin. L'adozione di un'architettura edge-to-cloud, con preprocessing locale e comunicazione event-driven, rappresenta il compromesso più efficace per la maggior parte dei contesti industriali [14].

La conformità a standard come ISO 23247 fornisce un framework di riferimento per strutturare l'architettura del twin, ma non sostituisce le decisioni progettuali specifiche del dominio [7, 8]. L'adozione di piattaforme cloud dedicate, Azure Digital Twins, AWS IoT TwinMaker, accelera il time-to-market ma introduce dipendenze che devono essere gestite con un livello di astrazione adeguato [12, 13].

Infine, la quantificazione dell'incertezza non è un'aggiunta opzionale ma un requisito di progettazione. Un digital twin che produce predizioni senza una stima della propria affidabilità non è adeguato per supportare decisioni operative in contesti critici [5, 9, 10]. L'integrazione di metodi ensemble, inferenza bayesiana o quantili di previsione deve essere prevista fin dalla fase di progettazione del modello.

Riferimenti

[1] M. Grieves, "Origins of the Digital Twin Concept," Florida Institute of Technology, 2016. https://www.researchgate.net/publication/307509727_Origins_of_the_Digital_Twin_Concept

[2] E. Glaessgen, D. Stargel, "The Digital Twin Paradigm for Future NASA and U.S. Air Force Vehicles," in Proc. 53rd AIAA/ASME/ASCE/AHS/ASC Structures, Structural Dynamics and Materials Conference, 2012. https://ntrs.nasa.gov/citations/20120008178

[3] A. Rasheed, O. San, T. Kvamsdal, "Digital Twin: Values, Challenges and Enablers From a Modeling Perspective," IEEE Access, vol. 8, pp. 21980-22012, 2020. https://arxiv.org/abs/1910.01719

[4] D. Jones, C. Snider, A. Nassehi, J. Yon, B. Hicks, "Characterising the Digital Twin: A Systematic Literature Review," CIRP Journal of Manufacturing Science and Technology, vol. 29, pp. 36-52, 2020. https://doi.org/10.1016/j.cirpj.2020.02.002

[5] National Academies of Sciences, Engineering, and Medicine, "Foundational Research Gaps and Future Directions for Digital Twins," The National Academies Press, 2024. https://nap.nationalacademies.org/catalog/26894

[6] F. Tao, W. Liu, M. Zhang et al., "Five-Dimension Digital Twin Model and Its Ten Applications," Computer Integrated Manufacturing Systems, vol. 25, no. 1, pp. 1-18, 2019. https://www.researchgate.net/publication/332710511

[7] ISO, "ISO 23247-1:2021 — Automation Systems and Integration — Digital Twin Framework for Manufacturing — Part 1: Overview and General Principles," 2021. https://www.iso.org/standard/75066.html

[8] S. Lu, R. Quilici, K. Morris, B. Kulvatunyou, "An Analysis of the New ISO 23247 Series of Standards on Digital Twin Framework for Manufacturing," in Proc. ASME MSEC, 2023. https://www.nist.gov/publications/analysis-new-iso-23247-series-standards-digital-twin-framework-manufacturing

[9] Y. Chen et al., "Digital Twin AI: Opportunities and Challenges from Large Language Models to World Models," arXiv:2601.01321, 2026. https://arxiv.org/abs/2601.01321

[10] S. Yang, H. Kim, Y. Hong, K. Yee, R. Maulik, N. Kang, "Data-Driven Physics-Informed Neural Networks: A Digital Twin Perspective," Computer Methods in Applied Mechanics and Engineering, vol. 421, 2024. https://arxiv.org/abs/2401.08667

[11] A. Kapusuzoglu, S. Mahadevan, "Physics-Informed and Hybrid Machine Learning in Additive Manufacturing: Application to Fused Deposition Modeling," JOM, vol. 72, pp. 4695-4705, 2020. https://doi.org/10.1007/s11837-020-04438-4

[12] Microsoft, "Azure Digital Twins Documentation," 2025. https://learn.microsoft.com/en-us/azure/digital-twins/overview

[13] Amazon Web Services, "Guidance for Digital Twin Framework on AWS," 2024. https://aws.amazon.com/solutions/guidance/digital-twin-framework-on-aws/

[14] G. Abbas et al., "Digital Twin Driven Smart Factories: Real Time Physics Based Co-Simulation Using Edge A.I. and Federated Learning," Scientific Reports, vol. 15, 2025. https://www.nature.com/articles/s41598-025-28466-9

[15] I. David et al., "Interoperability of Digital Twins: Challenges, Success Factors, and Future Research Directions," in Proc. ISoLA, 2024. https://www.nist.gov/publications/interoperability-digital-twins-challenges-success-factors-and-future-research

[16] McKinsey & Company, "Digital Twins: The Key to Smart Product Development," McKinsey Digital, 2022. https://www.mckinsey.com/capabilities/operations/our-insights/digital-twins-the-key-to-smart-product-development