T RANS -D OMAIN D IGITAL T WIN : C ONCEPTUAL F OUNDATIONS , A RCHITECTURE , AND R ESEARCH O UTLOOK
Mansoorali Amiri DIRO University of Montreal Montreal, QC [email protected]
arXiv:2607.15908v1 [cs.SE] 17 Jul 2026
A BSTRACT Complex systems comprise heterogeneous domains whose states, uncertainties, risks, and control consequences can cross domain boundaries. Existing cross-domain digital twin approaches broadly focus on comparison, reuse, semantic mapping, standardization, and interoperability, but do not inherently require operational connections among domain states, errors, objectives, constraints, decisions, and controls. This article proposes the trans-domain digital twin as an operational formulation along the continuum of Composite/Federated Digital Twin Systems. This approach connects heterogeneous domain twins through an aligned shared state, explicit coupling of data, models, states, errors, objectives, and controls, heterogeneous temporal coordination, joint decision-making, and feedback-based adaptation. The proposed framework presents a seven-layer conceptual architecture, a trans-domain orchestration core, minimum compliance conditions, a general operational formalism, progressive fast–meso–slow loops, and a single-episode offline training mechanism linked to bounded online adaptation. It also describes conceptual validation and evaluation criteria, a maturity model, a reference deployment architecture, and requirements for runtime safety, provenance, versioning, and model lifecycle management. The framework is conceptually mappable to standards for digital twins, model exchange, distributed simulation, and smart transducers; however, its formal compliance and operational effectiveness must be examined through independent benchmarks, uncertainty quantification, ablation testing, and field validation. Keywords Digital Twin · Trans-Domain Digital Twin · Composite/Federated Digital Twins · Digital Twin System-ofSystems · Operational Coupling · Shared Trans-Domain State · Multi-Scale Temporal Coordination · Feedback-Based Adaptation
1
Introduction
The initial objective of the Digital Twin (DT) was to provide a virtual representation of a physical system for monitoring, prediction, and decision-making throughout its life cycle [1, 2, 3]. Despite the rapid growth of this concept across different industries, there is still disagreement regarding its definition, level of integration, role of real-time data, implementation method, and validation [2, 3, 4]. Current studies show that the common patterns of these twins, such as simulation and optimization, are mainly focused on comparison and general development, and do not necessarily lead to operational coupling among heterogeneous domains [5, 6]. On the other hand, highly complex systems are inherently not single-domain, and a change in one domain alters the state and decisions of other domains [7, 8, 9, 10]. Accordingly, the Trans-Domain Digital Twin (TDDT) is defined in this article as a proposed formulation that connects multiple domain-specific twins through a shared state, coupled models, and decision-making loops [7, 8, 10, 11]. The objective of this article is to clarify the distinction between TDDT and other twins, to present its conceptual architectural framework, and to outline a future pathway for the development of self-adaptive and verifiable trans-domain twins [4, 5, 8, 11].
Trans-Domain Digital Twin: Conceptual Foundations, Architecture, and Research Outlook
1.1
The Evolution of Digital Twins from Single-Domain Systems to Multi-Domain Systems
This evolution has been driven by the complexity of real-world systems and the need to integrate virtual entities and distributed twins [3, 12, 13]. In the single-domain approach, the initial focus was on monitoring, virtual representation, and data exchange between the physical system and the model within a limited domain, such as a machine or a building [3]; however, due to the interdependence of the components of real-world systems, decisions cannot always be considered independently of other domains [7, 9]. Although Cross-Domain studies have been conducted with the aim of identifying multi-faceted development patterns and enhancing interoperability across diverse domains, ranging from manufactured components to smart cities [6, 14], the full realization of an integrated system requires a transition toward a “multi-domain and system-of-systems” approach, so that independent distributed twins can exchange shared information, objectives, and decisions by overcoming technological, data, model, and architectural heterogeneities [12, 15, 16]. This transition toward a trans-domain approach, in addition to the bidirectional flow of data, model, network, and application, requires operational connection of state, uncertainty, error, objective, decision, and control among domainspecific twins [13]. Optimal, proactive, and real-time decision-making in today’s problems has a multi-objective and multi-domain nature and is better achieved only through a connected and trans-domain network, in order to prevent systemic errors arising from local and uncoordinated controls [12, 13, 15]. 1.2
The Necessity of Introducing the Concept of the Trans-Domain Digital Twin
In real-world multi-domain systems that are modeled using single-domain or separate digital twins, error, risk, and uncertainty in one domain can affect other domains; therefore, local decision-making and separate optimization of each domain may lead to an inconsistent or high-risk decision at the whole-system level [12, 10, 17]. Cross-domain studies show that DTs in different domains have reusable common patterns, requirements, and mechanisms; in contrast, the literature on Digital Twin Systems-of-Systems raises the issue of composing and integrating multiple independent DTs at the level of larger systems. However, the cross-domain approach mainly focuses on identifying common patterns, comparison, structured development, and reuse across domains [6, 5]. Therefore, this article argues that a trans-domain conceptual design is necessary to cover the operational coupling of data, model, state, error, objective, and control, as well as to manage multi-scale systems, enable online adaptation with feedback from the real environment, and establish a clear framework for the classification, architecture, and validation of this generation of twins [18, 19, 12, 10, 17, 20]. 1.3
Objective, Main Questions, and Structure of the Article
The objective of this review is to clarify the position of TDDT as a proposed and emerging approach for the operational connection of domain-specific twins in complex systems. Accordingly, the article addresses four main questions: Q1. What is a trans-domain digital twin, and how does it differ from a single-domain, multi-domain, and Cross-Domain Digital Twin? This question is based on the existing ambiguity in the definition of DT, the difference in the level of data connection in the Digital Model, Digital Shadow, and Digital Twin, and the distinction between cross-domain reuse and trans-domain operational coupling in the proposed formulation of this article [2, 3, 6, 5]. Q2. What is the position of TDDT in the classification, and why can it be considered along the continuum of Composite/Federated Digital Twin System-of-Systems? This question relies on studies that extend DT from the level of a single asset to the level of composable, multi-source, and system-of-systems structures, and examine the possibility of connecting multiple independent twins within a shared architecture [6, 12, 10]. Q3. How should the conceptual architecture of TDDT connect data, model, state, error, objective, decision, and control among heterogeneous domains? This question arises from the need to integrate virtual entities, enable interoperability, manage heterogeneous data and models, and support decision-making based on a shared state in complex systems [3, 12, 17, 13]. Q4. How can TDDT support trans-domain decision-making through fast inner loops and slow outer loops, offline learning, online tuning, and feedback from the real environment? This question is based on the logic of self-adaptive DTs, applications in smart agriculture, complex system design, and the trans-domain framework proposed in this article [10, 7, 20]. 2
Trans-Domain Digital Twin: Conceptual Foundations, Architecture, and Research Outlook
To answer these questions, the background and common classifications of digital twins are first reviewed; then, the concept of TDDT and its distinction from single-domain, multi-domain, and cross-domain approaches are explained. Next, the conceptual framework of TDDT, including domain-specific twins, the trans-domain shared state, types of coupling, fast and slow loops, and online adaptation mechanisms, is presented. Subsequently, selected applications of TDDT in different areas of complex systems are reviewed. Finally, the advantages, challenges, validation limitations, data and security issues, and future directions for the development of lightweight, self-adaptive, and trustworthy TDDTs are summarized. 1.4
Contributions and Innovations of the Article
The main contributions of this article are as follows: 1) defining TDDT as an operational formulation of a Composite/Federated Digital Twin System-of-Systems and distinguishing it from single-domain, multi-domain, and CrossDomain twins [5, 6, 12, 17, 21, 22]; 2) presenting a seven-layer architecture and the Trans-Domain Orchestration Core (TDOC) for coordinating domain twins, the shared state, decisions, and feedback [12, 20, 17, 22]; 3) classifying trans-domain coupling into data, model, state, error, objective, and control, and defining fast, meso, and slow loops [5, 12, 20, 17, 22]; 4) presenting a single-episode offline training and online adaptation mechanism for experience transfer, error correction, and reducing learning risk in the real environment [11, 20, 23, 24, 25]; and 5) explaining the conceptual mapping capability of the architecture with Functional Mock-up Interface (FMI) and High Level Architecture (HLA) [26, 27]. The innovation of the article does not lie in the independent invention of all components, but rather in their integrated combination and formulation for operational trans-domain coupling, multiscale coordination, and joint decision-making [5, 6, 12, 20, 17, 21, 22]. 1.5
Article Structure
To answer these questions, the background and common classifications of digital twins are first reviewed; the concept of TDDT and its distinction from single-domain, multi-domain, and cross-domain approaches are then explained. Next, the conceptual framework of TDDT, including domain twins, the shared trans-domain state, coupling types, fast and slow loops, and online adaptation mechanisms, is presented. Selected applications of TDDT across different complex-system domains are then reviewed. Finally, the advantages, challenges, validation limitations, data and security issues, and future directions for developing lightweight, self-adaptive, and reliable TDDTs are summarized. 1.6
2
Nomenclature and Abbreviations
Abbreviation
Full Form
DT CDDT TDDT SoS TDOC STD CRP SARG MRG SS-KStore SETD-KStore LCI MPC FMI FMU HLA ROM PINN VVUQ
Digital Twin Cross-Domain Digital Twin Trans-Domain Digital Twin System-of-Systems Trans-Domain Orchestration Core Shared Trans-Domain State Context Reference Patterns Stage-Aware Reference Guidance Meso Reference-Guidance Step-Stream Memory Knowledge Store Single-Episode Trans-Domain Knowledge Store Loop Current Index Model Predictive Control Functional Mock-up Interface Functional Mock-up Unit High Level Architecture Reduced-Order Model Physics-Informed Neural Network Verification, Validation, and Uncertainty Quantification
Background and Current State of Digital Twins
The concept of the Digital Twin (DT) was initially introduced in connection with product lifecycle management and reducing the gap between a physical asset and its digital representation [28, 1]. In the aerospace literature and later in 3
Trans-Domain Digital Twin: Conceptual Foundations, Architecture, and Research Outlook
smart manufacturing, this concept went beyond a simple information model and became a framework for combining operational data, health monitoring, simulation, prediction, and decision-making throughout the system lifecycle [1, 29, 30]. With the growth of IoT1 , CPS2 , Industry 4.0, artificial intelligence, and data analytics, DT has become one of the main mechanisms for monitoring, prediction, and optimization in domains such as manufacturing, healthcare, smart cities, and smart agriculture [30, 18, 7]. However, systematic reviews show that the definition, conceptual boundary, level of data connection, role of feedback, and method of DT validation remain diverse and sometimes inconsistent [2, 3, 18]. On the other hand, recent studies show that the evolution of DT is moving from a single asset toward connected, multi-domain, interoperable, and system-of-systems (SoS) digital models; this trajectory provides the theoretical basis required for proposing trans-domain digital twins in this article [6, 4]. 2.1
General Definition of Digital Twin and Its Distinction from Digital Model and Digital Shadow
A digital twin, in its general sense, is a digital representation of an object, machine, process, or physical system that uses data, models, computation, and, where available, feedback to reflect the behavior and state of the real system over time [7, 31, 32]. The main distinction among a Digital Model, a Digital Shadow, and a Digital Twin depends on the level of automation and the direction of data flow between the physical system and the digital model [2]. In a Digital Model, the digital representation is independent of the physical system, and data updates or effects on the real system are not performed automatically [18, 31, 2]. In a Digital Shadow, data flow is established automatically but unidirectionally from the physical system to the digital model, and the model can reflect the real state but does not automatically affect the physical system [2]. In a DT, the connection is automatic, purposeful, and, where an execution infrastructure exists, bidirectional; that is, data from the real system update the model, and the model output can also be returned to the physical system in the form of recommendations, corrections, or control [32, 30, 4, 2]. This distinction is important for TDDT because TDDT is not limited to the representation or monitoring of a single domain but seeks the operational connection of multiple domain twins at the levels of state, error, objective, decision, and control. 2.2
Common Classifications of Digital Twins: Monitoring, Predictive, Prescriptive, and Autonomous
One common classification of DT divides it based on the level of decision-making function and the degree of automation. In this view, the twin begins at the level of state monitoring, then progresses to future prediction, action recommendation, and finally automatic control or correction [7, 2, 18, 4]. In smart agriculture, types such as Monitoring, Predictive, Prescriptive, and Autonomous have also been used to explain the functional maturity of DT [7]. At the Monitoring level, the main objective is to increase observability and reflect the current state of the system [7, 2, 3]. At the Predictive level, physical, data-driven, or simulation models are used to predict future behavior and assess risk [7, 18, 4]. At the Prescriptive level, the twin evaluates intervention options, “what-if” scenarios, constraints, and the cost function, and recommends the appropriate decision [7, 4, 30]. At the Autonomous level, the output of the twin can affect the physical system automatically or semi-automatically through feedback, control, or reconfiguration [2, 18, 33]. This classification shows that moving from monitoring to control requires the connection of data, model, feedback, and decision; however, it still does not necessarily explain how several heterogeneous domains should be integrated into a shared state and operationally coupled decision-making. 2.3
Cross-Domain Approaches in Digital Twins and Their Limitations
Cross-Domain Digital Twin (CDDT): In this article, the term CDDT is used as an abbreviation for cross-domain approaches in the digital twin literature; approaches whose objective is to identify common features, reusable patterns, general development methods, and interoperability mechanisms among different domains [6, 5]. In this approach, the main focus is on how the concepts, architectures, data, models, and tools of the digital twin can be generalized from one domain, such as manufacturing, maintenance, product, infrastructure, or cyber–physical systems, to other domains [1–3]. For example, cross-domain studies in software engineering show that DTs in diverse domains, despite their application-specific differences, have common requirements such as modeling, data connectivity, synchronization, simulation, monitoring, and decision support [6]. Structured cross-domain analyses also show that DT development is a combination of domain-independent and domain-dependent steps; in this sense, part of the architecture, data, and development process can be generic, while an important part of the meaning, model, and decision objective remains dependent on the specific domain [5]. Therefore, in this article, CDDT is not considered a formal standard category, but rather an operational naming for the level of comparison, standardization, reuse, semantic mapping, data exchange, and interoperability among domains [6, 5, 17]. 1 2
Internet of Things Cyber–Physical Systems
4
Trans-Domain Digital Twin: Conceptual Foundations, Architecture, and Research Outlook
Despite these advantages, CDDT does not inherently and by itself require that the output of one domain be able to operationally change the state, constraint, objective, error, decision, or control of another domain; although, in specific implementations, it can be combined with decision-making or control mechanisms [5, 17, 3]. Therefore, although the cross-domain approach is necessary for reducing conceptual fragmentation, increasing reusability, and developing general DT frameworks, this article argues that, for the objective intended in this article, namely the operational and time-dependent coupling of data, model, state, error, objective, decision, and control among domains, it is not considered sufficient [3, 12, 10]. In such systems, twins must not only be comparable or reusable, but also be able to be connected in a composite and operational manner in the form of a Digital Twin System-of-Systems [3, 12]. Therefore, this limitation provides the basis for introducing the concept of the Trans-Domain Digital Twin; a proposed approach in which the connection among domains goes beyond the level of interoperability and reuse and becomes the coupling of data, model, state, error, objective, decision, and control [12, 10, 20]. In the inferential architecture of this article for CDDT, analytical or intelligent outputs, including recommendations generated by AI, are mainly located in the Cross-Domain Application layer in the form of monitoring, dashboard, reporting, and decision support; this level is not equivalent to operationally coupled control among domains. Figure 1 shows the general overview of CDDT.
CDDT Conceptual Layered View 1. Physical Multi-Domain System
Legend
physical / biological / cyber / economic / environmental states sensors, events, disturbances, human decisions
interoperability / reuse flow
.
2. Independent Domain-Specific Twins DT1 climate / environment
DT2 biological / health / growth
DT3 energy / resources
DT4 network / cyber / infrastructure
DTn economy / risk / policy
3. Cross-Domain Interoperability Layer data exchange APIs
standards ontology semantic mapping
model adapters
No shared fused state / no inherent operational coupling
4. Common Reference / Reuse Layer common features reusable patterns
reference models shared platform tools
No shared fused state / no inherent operational coupling
5. Cross-Domain Application / Decision-Support Layer comparison benchmarking
monitoring decision support
dashboard reporting
No shared fused state / no inherent operational coupling
Limitation: operational coupling across state, error, objective, decision and control is not inherent
Figure 1: Layered Architecture of CDDT - Independent domain-specific twins are connected through data exchange, APIs, standards, semantic mapping, and reference models for comparison, monitoring, reporting, and decision support, without inherently creating operational coupling of decision and control among domains.
3
Definition and Position of the Trans-Domain Digital Twin
3.1
Research Gap in the Operational Connection of Domain Twins
The digital twin literature covers representation, monitoring, prediction, interoperability, and the composition of multiple independent twins; however, it does not provide an explicit and integrated method for the time-dependent transfer of the effect of one domain to the state, error, objective, constraint, decision, or control of another domain [3, 4, 6, 12, 10, 17]. Cross-Domain approaches mainly focus on comparison, reuse, standardization, and semantic mapping [5, 6, 17], 5
Trans-Domain Digital Twin: Conceptual Foundations, Architecture, and Research Outlook
while Composite/Federated architectures and DT System-of-Systems also enable the composition of twins, but do not establish a common requirement for a fused state, operational coupling, multiscale coordination, and cross-domain error feedback [12, 20, 10, 17, 21, 22]. Therefore, the main gap is the absence of a framework that simultaneously defines, executes, and evaluates these relationships. This gap is characterized by four measurable deficiencies: 1) the absence of a shared state for aligning time, units, context, and uncertainty; 2) the absence of explicit coupling among the state, error, objective, and control of the domains; 3) the absence of a mechanism for coordinating heterogeneous temporal loops; and 4) the absence of a traceable pathway for effect transfer and error feedback among the twins [12, 13, 20, 10, 17, 21, 22].
3.2
Definition and Positioning of the Trans-Domain Digital Twin
In this article, TDDT is an architecture at the System-of-Systems (SoS) level that connects multiple heterogeneous DTs through data, models, a shared state, multi-criteria objectives, and a shared decision cycle [2, 3, 4, 5, 6, 7, 8]. In this architecture, the output of one domain can change the input, state, constraint, risk, objective, or decision of another domain [5, 6, 12, 20, 17, 21]. Therefore, TDDT is positioned along the continuum of Composite/Federated Digital Twin System-of-Systems, but its distinction lies in the requirement for operational and time-dependent coupling for trans-domain decision-making and control [12, 20, 17, 21].
3.3
Minimum and Measurable Requirements of TDDT
A system is considered a TDDT when it includes at least two heterogeneous domain twins, an aligned shared state, at least one coupling at the level of state, error, objective, or control, a traceable cross-domain effect, a temporal synchronization policy, and a feedback pathway for correcting the model or coupling. Data exchange, an API, or semantic mapping, without satisfying these conditions, is not sufficient to classify a system as a TDDT [5, 6, 12, 20, 10, 17]. Figure 2 summarizes the measurable architectural gap between existing digital twin configurations and the proposed TDDT.
Capability Requirement
Single-Domain DT
Multi-Domain DT
Cross-Domain DT (CDDT)
Composite/Federate d DT
Proposed TDDT
Shared state across domains
Domain-local state only
Optional or partial
Not inherently required
Possible; architecturedependent
Required
Objective–Control Coupling
Local to one domain
Limited or implementationdependent
Not inherent
Possible; implementationdependent
Core architectural capability
Multi-Scale Temporal Loops
Possible within one domain
Possible
Not inherently specified
Possible
Explicitly defined
Error transmission between domains
Not applicable
Possible but often implicit
Not inherent
Possible; implementationdependent
Explicit and traceable
Joint DecisionMaking
Local decisionmaking
Optional
Mainly decision support
Possible
Required for trans-domain operation
Not applicable Absent / not inherent Not inherently specified Local to one domain
Optional / partial Decision support Architecture / implementation-dependent Possible
Explicitly defined / traceable Required / mandatory Core architectural capability
Figure 2: Measurable research gap between existing digital twin configurations and the proposed TDDT. This table distinguishes capabilities that are local, optional, implementation-dependent, or explicitly required for trans-domain operations.
The architecture presented in Section 4 directly addresses this gap; the shared state, operational coupling, temporal coordination, and error feedback are realized in Layers 3.1, 3.2, 3.3, and 7, respectively. 6
Trans-Domain Digital Twin: Conceptual Foundations, Architecture, and Research Outlook
4
Conceptual Framework and Architecture of TDDT
The conceptual framework of TDDT includes seven main layers: the multi-domain physical layer, domain-specific twins, the trans-domain shared state, the coupling layer, fast and slow loops, the multi-criteria decision-making layer, and the feedback and online adaptation layer. Figure 3 shows these layers. The position of this framework is defined along the continuum of Digital Twin System-of-Systems and Federated/Composite Digital Twins; however, its distinction in this article lies in establishing operational coupling among domains for trans-domain decision-making and control [22, 12, 17, 11, 20]. The trans-domain orchestration core, or TDOC, is the central orchestration mechanism of TDDT, which coordinates data exchange, shared state, operational coupling, temporal synchronization, decision-making, and error return among domain-specific twins, the fused model, the decision layer, and online adaptation. In this architecture, the role of “device communication, data acquisition, timestamping, unit conversion, data quality control, and command transmission to actuators” is considered as an interface sublayer between Layer 1 and Layer 2; this sublayer is functionally mappable to the Device Communication Entity in ISO 23247 and to the smart transducer interface layer in IEEE 1451. 4.1
Scope, Principles, and Minimum Requirements for TDDT Compliance
The criteria presented in this section constitute the article’s proposed minimum requirements for distinguishing TDDT from merely multi-domain, Cross-Domain, and Composite/Federated architectures [5, 6, 11, 12, 17, 21, 22]. This architecture is based on the relative independence of domain twins, composability, traceable operational effects, temporal coordination, and feedback [11, 12, 18, 17, 22]. In this formulation, a system is minimally considered a TDDT when it includes at least two heterogeneous twins, an aligned shared or distributed representation, at least one coupling at the level of model, state, error, objective, or control, a traceable cross-domain effect, a temporal coordination policy, multi-domain-based decision-making, and a feedback pathway. This indicates that data exchange, an API, an ontology, or a shared dashboard without operational effects among domains is insufficient [5, 6, 12, 17]. The seven-layer architecture, TDOC, the meso loop, single-episode training, Context Reference Patterns (CRP), Stage-Aware Reference Guidance (SARG), Meso Reference-Guidance (MRG), and KStores are the formulations and mechanisms proposed in this article; therefore, their exact implementation is not a general requirement for classification, provided that equivalent functions for the shared state, coupling, coordination, decision-making, and feedback are realized. 4.2
Multi-Domain Physical Layer
The first layer includes real entities, subsystems, processes, resources, and actors in the operational environment, such as climate, energy, humans, living organisms, infrastructure, industrial assets, networks, economy, or the natural environment. In the real world, these entities are not independent and affect one another through causal, temporal, spatial, and operational dependencies. In complex systems, information management must cover the stages of design, construction, operation, and maintenance, alongside technical, organizational, data-related, and interoperability dimensions [22, 12, 5, 17]. In TDDT, this layer is the main source of data, disturbances, uncertainty, and feedback. In practical implementation, each sensor and actuator in this layer should be described together with operational metadata such as a unique identifier, quantity type, unit, location, sampling rate, accuracy, measurement range, health status, timestamp, data quality, and uncertainty. This metadata can be maintained as TEDS or Virtual TEDS according to the logic of IEEE 1451, so that raw data from the real environment can be interpretable, validatable, and synchronizable before entering the domain-specific twins. 4.3
Domain-Specific Twins and Specialized Sub-Simulators
The second layer includes domain-specific twins. Each domain has a specialized twin that can be built based on a physical model, data-driven model, agent-based model, simulator, statistical model, machine learning model, or a combination of them; therefore, the construction, encapsulation, and preparation of the domain-specific model or simulator are located in this layer, and its objective is to reflect the state, predict behavior, and generate indicators that can be used by other domains. This idea is consistent with the DT literature, which considers DT as a set of models, data, and technologies connected to the physical world for monitoring, prediction, and decision-making [18, 22]. At 7
Trans-Domain Digital Twin: Conceptual Foundations, Architecture, and Research Outlook
TDDT layer architecture / algorithms
Legend Moving forward
.
Offline loop
.
Online loop
.
1. Physical Multi-Domain System physical / biological / cyber / economic / environmental states sensors, events, disturbances, human decisions Structural view of the real world
2. Domain-Specific Twins DT1 climate / environment
DT2 biological / health / growth
DT4 network / cyber / infrastructure
DT3 energy / resources
DTn economy / risk / policy
constraints, risks and objectives control status
Route(eTD)
3.2. Trans-Domain Coupling data coupling model coupling
state coupling error coupling
objective coupling control coupling
monitoring / local prediction / local control
Meso-scale loops: slow-state aggregation / faststate update / risk-load signal
4. Prediction + What-if Simulation + Optimization
7. Error Feedback + Online Adaptation update models, states, weights, constraints and couplings
Trans-Domain Orchestration Core
Execution view of Layer 1
5. Decision / Recommendation / Control Action
Slow outer loops: strategy / objective / constraint update
6. Real Operational System / Execution Environment
3.3. Time Synchronization Fast inner loop:
3. Fused Trans-Domain Model
3.1. Shared Trans-Domain State time, context, units, data quality domain states and uncertainty
Figure 3: Architectural–algorithmic overview of TDDT - Layer 1 shows the structural view of the real multi-domain system, namely entities, sensors, actuators, disturbances, and operational constraints; in contrast, Layer 6 represents the execution view of the same real system at the time of decision application. In the online pathway, real data and events enter the domain-specific twins from Layer 1, the decision or control action from Layer 5 is executed in Layer 6, and the observed response of the real system is used as a returned error in Layer 7 to correct models, states, constraints, and couplings. In the offline pathway, training and validation before operational connection to the real system are mainly performed among Layers 2, 3, and 4.
the System-of-Systems level, each domain-specific twin can initially be developed independently, but it must become composable and interoperable within the higher-level architecture [22, 12]. A “sub-simulator” refers to the specialized simulator of a domain or subsystem in Layer 2 and represents only part of the multi-domain system. In the literature, a co-simulator is the framework for scheduling and concurrently executing multiple sub-simulators, such as FMI for the exchange/co-simulation of dynamic models or HLA for distributed simulation. In the TDDT approach, Layer 3 goes beyond co-simulation and transforms the outputs into a shared state, operational coupling, and trans-domain decision-making, which we call the fused trans-domain model [26, 27]. In this layer, each domain twin has three main tasks: reflecting the state of the domain, predicting the behavior of the domain, and generating indicators that can be used by other domains. 8
Trans-Domain Digital Twin: Conceptual Foundations, Architecture, and Research Outlook
4.3.1
Fluid dynamics models for representing climate, flow, and environment
Models from the fluid dynamics family, including CFD3 , RANS4 /LES5 , and FFD6 , are among the most fundamental model families for representing local climate, airflow, heat transfer, humidity, gas, and shear stresses in domains such as closed agricultural halls, aerospace, ventilated buildings, and bioreactors; these models can reveal the spatiotemporal structure of flow and the effects of geometry, boundaries, and actuators [34, 35, 36, 37]. In TDDT, these models can be used in a mechanistic/semi-mechanistic form for accurate simulation, or in the form of FFD, ROM7 , POD8 /DMD9 , and data-driven surrogates for fast prediction that can be used in decision loops [34, 37]. 4.3.2
Lightweighting, analysis, or surrogation
In this layer, high-fidelity models, such as models derived from Computational Fluid Dynamics (CFD), can be transformed into lighter, more analyzable, or fast surrogate models through methods such as Reduced-Order Model (ROM), Proper Orthogonal Decomposition (POD), Dynamic Mode Decomposition (DMD), or interpolation, due to their high computational and time costs. These methods are mainly located in the second layer, because they are used for order reduction, dynamic analysis, reducing computational cost, and producing faster outputs from domain-specific simulators. 4.3.3
Encapsulation and standard interfaces
FMI10 provides the outputs of domain-specific models, after being encapsulated in FMUs11 , to Layer 3 as exchangeable, time-stamped, unit-aware variables with causal direction; it should be noted that FMI/FMU is mainly used for the encapsulation and exchange of dynamic models and domain-specific simulators. In contrast, the standard connection of real sensors and actuators, metadata reading, calibration, health status, and command transmission to transducers can be performed through the logic of IEEE 1451, including TIM12 , NCAP13 , and TEDS14 , in the device communication sublayer. Therefore, in TDDT, FMI for “models” and IEEE 1451 for “real sensors/actuators” play complementary roles. This transition can be part of the twinning process, because it supports the physical–virtual interface for the synchronized representation of the twin with the real system at a specified level of frequency, fidelity, and data quality. 4.4
Fused Trans-Domain Model
The third layer includes the fused trans-domain model or state space, which transforms the outputs of domain-specific twins into a shared, coupled, and temporally synchronized progressive state, so that trans-domain prediction, decisionmaking, and control become possible. This layer is an upstream compositional mechanism that receives the outputs of the twins, simulators, and specialized models of the second layer and reorganizes them into a shared operational state that is couplable, synchronizable, and usable for trans-domain decision-making [22, 12, 17]. Accordingly, in the proposed architecture of this article, the fused state space or fused simulator results from the integration of sublayer 3.1 (sub-section 4.4.2), sublayer 3.2 (sub-section 4.4.3) , and sublayer 3.3 (sub-section 4.4.4). Therefore, the output of these sublayers is transformed into a shared computational–semantic space in which the effect of a change in one domain on other domains can be predicted, evaluated, and controlled [12, 17, 20]. The output of this shared trans-domain state is then transferred to the decision-making, control, and online adaptation layers [17, 11, 20]. 3
Computational Fluid Dynamics Reynolds-Averaged Navier–Stokes 5 Large-Eddy Simulation 6 Fast Fluid Dynamics 7 Reduced-Order Model 8 Proper Orthogonal Decomposition 9 Dynamic Mode Decomposition 10 Functional Mock-up Interface (FMI) is an open and tool-independent standard for the exchange, integration, and co-simulation of dynamic models, which defines the interface and model packaging format for exchange among different tools [26] 11 Functional Mock-up Unit (FMU) is an executable/compressed package compliant with the FMI standard, which contains the model, variables, executable functions, the XML file describing the model, and, if needed, the binaries or code required for simulation. 12 Transducer Interface Module 13 Network-Capable Application Processor 14 Transducer Electronic Data Sheet 4
9
Trans-Domain Digital Twin: Conceptual Foundations, Architecture, and Research Outlook
4.4.1
Ontology, Semantic Mapping, and Conceptual Alignment of Domains
In this layer, first, the objective and scope of the ontology and the competency questions regarding time, location, unit, data quality, domain state, uncertainty, constraints, and decision are determined according to the requirements of the TDDT architecture [38, 39]. Then, the vocabulary of each domain, the main concepts, class hierarchies, relations, data properties, the domain and range of relations, logical constraints, and real or simulated instances are extracted [38, 40]. To connect multiple domain-specific models or twins, the corresponding components are identified through lexical, unit-based, structural, semantic, temporal, spatial, and causal matching, and the type of mapping or relation between them is determined [41, 42]. These mappings can be of the type of SKOS15 relations such as exactM atch, closeM atch, broadM atch, narrowM atch, and relatedM atch, or of the type of ontological/logical relations such as equivalentClass and subClassOf [42, 43]. Finally, the mappings are corrected according to differences in unit, level of abstraction, context, or direction of relation, and are stored as a mapping table, shared vocabulary, or bridge ontology, so that the outputs of domain-specific twins can be transferred to the shared trans-domain state and then to the operational coupling layer [42, 43]. In addition to mapping domain concepts, it is also necessary to align the metadata of sensors and actuators with the shared TDDT ontology; for example, measurement unit, installation location, sampling rate, accuracy, actuator type, health status, and data quality should be mapped to the corresponding concepts in the shared trans-domain state. This makes the data obtained from smart transducers semantically, unit-wise, temporally, and trust-wise consistent before entering the shared state. 4.4.2
Trans-Domain Shared State and Data Exchange among Domains
In Layer 3, Sublayer 3.1 is the point of overlap between CDDT and TDDT and, by using ontology, transforms the important information of each domain into a semantic, temporal, and operational representation of the whole system so that it can be understandable and usable for other domains. The importance of such a layer is consistent with the literature on multi-domain DT; multi-domain models identify and organize domains such as geometry, structure, data, interaction, application, and time span/horizon in order to create a shared understanding of the system [15]. From the perspective of interoperability as well, heterogeneous twins cannot work together effectively without a shared data model, semantics, protocol, and interface [17].
time, context, device metadata, domain states, data quality, uncertainty, ST Dt = constraints, risks, objectives, control status
(1)
The device metadata component includes the sensor/actuator identifier, unit, location, sampling rate, health status, calibration, and timestamp, and acts as a bridge among the physical layer, the device communication sublayer, and the domain-specific twins. In this sublayer, the output of each domain-specific twin is transformed into the shared trans-domain state through state alignment; that is, the heterogeneous states of the domains are aligned in terms of time, unit, context, quality, uncertainty, constraint, objective, and control status, so that they can be used for trans-domain coupling and decision-making. 4.4.3
Coupling among Domains—Data, Model, State, Error, Decision, and Control
In cross-domain DT, the main focus is on extracting common patterns, general development methods, domainindependent steps, and the possibility of reuse across domains [5]. However, in Sublayer 3.2 of Layer 3 of TDDT, the objective is the operational influence of one domain on other domains; that is, the output of one domain should be able to change the input, constraint, objective, error, or decision of another domain. In this layer, the proposed types of operational coupling in TDDT are summarized in Figure 4.
15
Simple Knowledge Organization System
10
Trans-Domain Digital Twin: Conceptual Foundations, Architecture, and Research Outlook
Coupling Type
Description
Data Coupling
Transfer of data and indicators between domains
Model Coupling
Use of the output of one model as input to another model
State Coupling
Effect of the state of one domain on the state of another domain
Error Coupling
Transfer of error and uncertainty between domains
Objective Coupling
Effect of the objectives of one domain on the objective function of another domain
Control Coupling
Effect of the decision of one domain on the actuator or policy of another domain
Figure 4: Proposed classification of operational coupling in TDDT. Data, model, state, error, objective, and control coupling describe progressively stronger forms of cross-domain influence, ranging from information transfer to direct modification of another domain’s objective, decision, or actuator policy. This layer is consistent with the literature on Digital Twin System-of-Systems; individual twins must be composable and integrable horizontally, vertically, and from different perspectives in order to produce the behavior of the larger system [22, 12]. At the same time, the precise classification of data, model, state, error, objective, decision, and control couplings is the specific formulation of this article for distinguishing TDDT from cross-domain DT [5, 20]. 4.4.4
Progressive Coupled Time Loops
In Sublayer 3.3 of Layer 3 of TDDT, operational asynchrony among domains is managed through progressive coupled time loops. Each domain evolves at its own specific speed; domains such as climate, flow, network, energy, or actuators usually require fast inner loops, whereas domains such as growth, health, degradation, economy, resilience, policy, or sustainability change over slower horizons and serve as guides, constraints, or objective-correcting elements for the fast domains. The literature on multi-domain DT, digital twin, and DT systems-of-systems also shows that real-world systems are composed of heterogeneous subsystems, data, models, and behaviors, and operate across different spatial, temporal, and functional scales [18, 22, 12, 5, 17, 11, 20]. Therefore, in the TDDT architecture, to cover this operational asynchrony, at least two main temporal levels are considered: Fast inner loops:
monitoring → prediction → local control ∆t = seconds / minutes
Slow outer loops:
assessment → strategy update → objective correction ∆T = hours / days / weeks
In this architecture, the fast loop is responsible for monitoring, stability, and short-term response, whereas the slow loop corrects objectives, constraints, strategies, and decision weights based on long-term consequences. Between these two, an intermediate temporal level titled meso-scale and its corresponding loop titled meso-loop are defined, which receives data from both the fast and slow loops and establishes the operational connection among temporal horizons by aggregating fast states, updating slow states, and generating risk/load signals. For example, in closed livestock farming, the domain of harmful gases is a meso-scale domain, because its production depends on slow biological factors such as feed intake, growth status, and livestock genotype, whereas its momentary control is performed through actuators in the fast loop. Therefore, the meso-scale loop has a secondary temporal level as follows: Meso-scale loops:
aggregation from slow states + update from fast states → intermediate-domain prediction → constraint / risk / load signal for fast control ∆tm = minutes / hours
Figure 5 shows an overview of these three temporal loops. 11
Trans-Domain Digital Twin: Conceptual Foundations, Architecture, and Research Outlook
Physical Twin
Trans-Domain Digital Twin Legend
Inner loop Outer loop Meso loop
Figure 5: Coupled Time Loops in TDDT: The fast loop performs short-term local control; the slow loop updates long-term objectives and constraints; and the meso-loop transfers intermediate-scale data and guidance between these two loops.
4.4.5
Position of Domain-Specific Model Types in the Fused Model
In the fused model, the outputs of domain-specific twins and sub-simulators are integrated into a shared computational–semantic trans-domain space; a space that can simultaneously support mechanistic, data-driven, probabilistic, semantic, agent-based, rule-based, and control models. In this layer, ODE16 /PDE17 models are used for the precise coupling of physical, mechanical, biological, chemical, and transport phenomena; PINNs18 incorporate physical or biological laws into the learning process; and statistical and data-driven AI19 / Surrogate / ROM models are used for fast approximation of heavy models and reduction of computational cost [44, 45]. In uncertain, incomplete, or timedependent relationships, Bayesian Networks / (DBN)20 are used to represent probabilistic dependencies, uncertainty, and risk; in conceptual relationships, logical constraints, and inferable decisions, Semantic Reasoning / Rule-Based Models play the role of semantic alignment and application of domain rules; and in micro-level behaviors, ABM21 models agent–agent and agent–environment interactions [46, 47, 48, 49]. In addition, control and decision models, such as control policies, control constraints, setpoint/deadband rules, or predictive control, are represented in Layer 3 as part of Objective/Control Coupling; however, the final selection of the action or executable command is still performed in Layer 5. Figure 6 summarizes the roles and architectural positions of the main modeling approaches within the fused trans-domain model. 4.4.6
Concept of Hidden Loop Current and Cyclic Error Signature
In TDDT, hidden loop current means the indirect and detectable effect of a domain that, after passing through several other domains, returns again to the same domain and creates a behavior that cannot be explained by the direct and linear model of that domain alone. This naming is conceptually inspired by the idea of loop-current and the existence of indirect signatures in physical systems, but in TDDT it is redefined as an architectural indicator for detecting cyclic error and hidden couplings [50]. In TDDT, this concept is used to identify hidden couplings, returned error, delayed effects, regime shift, and risks that are not evident in the output of a single domain alone, but after passing through paths such as (Di → Dj → Dk → Di ), appear as a persistent difference between direct prediction and observed behavior (Figure 16
Ordinary Differential Equation Partial Differential Equation 18 Physics-Informed Neural Network 19 Artificial Intelligence 20 Dynamic Bayesian Network 21 Agent-Based Model 17
12
Trans-Domain Digital Twin: Conceptual Foundations, Architecture, and Research Outlook
Approach
Role in the Fused Simulator
Description
Position in Layer 3
ODE / PDE
Deterministic and mechanistic fusion
Accurate coupling of physical, biological, or mechanical phenomena; suitable when the governing relations are formulated.
Trans-Domain Coupling Layer 3.2, especially state coupling and model coupling
AI / Surrogate Models
Fast approximation of heavy models
A faster substitute for computationally expensive models; suitable for near-real-time prediction.
Coupling Layer 3.2 and, in the case of time dependency, Time Synchronization Layer 3.3
PINN
Physics-informed data-driven fusion
A neural network that embeds physical or biological constraints into the learning process.
Model Coupling 3.2; if used for multi-step prediction, connected to Layer 3.3
Bayesian Networks
Probabilistic and risk-aware fusion
Representation of conditional relationships between domains and management of uncertainty.
Shared State 3.1 for uncertainty and risk; Error/Risk Coupling 3.2
Dynamic Bayesian Networks / DBN
Time-dependent probabilistic fusion
Modeling probabilistic dependencies over multiple time steps.
Time Synchronization Layer 3.3 and Error/State Coupling 3.2
Semantic Reasoning & Rule Engines
Semantic and inferential fusion
Transformation of domain data into concepts, constraints, and inferable decisions.
Shared Trans-Domain State 3.1 and Objective/Control Coupling 3.2
ABM
Behavioral, agent-based, and environment-aware fusion
Simulation of independent agents and emergence of macro-level behavior from micro-level interactions.
State Coupling 3.2 and Time Synchronization Layer 3.3
Figure 6: Roles and architectural positions of representative modeling approaches in the fused trans-domain model. Mechanistic, surrogate, physics-informed, probabilistic, semantic, and agent-based models support different combinations of shared-state construction, operational coupling, temporal synchronization, and uncertainty representation.
7). This idea considers hidden loop current not as a direct variable, but as an indirect, persistent, and multi-domain signature. The simple formula of the hidden loop current index (LCI), which stands for Loop Current Index, is as follows: LCIi (t, τ ) = xobserved (t + τ ) − xdirect (t + τ ) , i i
LCIi > θi
where (LCIi ) is the loop index, (xobserved ) is the observed state, (xdirect ) is the direct prediction, (τ ) is the delay i i horizon, and (θi ) is the error threshold, The application of this index is to indicate whether the error of a domain, after passing through several other domains, has returned again to the same domain and changed the decision, control, or uncertainty. If this index is activated, the feedback path can be transferred to Layer 2 for correcting the domain-specific model and/or to Layer 3 for correcting alignment, coupling, and synchronization. In terms of the minimum number of domains, TDDT can conceptually be defined with at least two heterogeneous domains; at minimum, there must be one operational relationship between two domain-specific twins. However, for the effective detection of hidden loop current, the presence of three domains or three independent estimation paths is recommended, so that the returned effect through the indirect path can be compared with the direct prediction. The existence of models that examine a domain from different perspectives is not mandatory for the general definition of TDDT; however, in high-risk or low-sensor domains, having multiple independent models of the same domain, such as physical, data-driven, statistical, or mirror models, is strongly recommended for separating domain-specific error from coupling error. For example, UAV navigation in GNSS-independent environments, due to high risk, limited sensors, and returned errors among inertia, wind, altitude, energy, control, and map, shows that in sensitive applications, using multiple domains, sometimes up to 10 to 12 complementary domains, can make the detection of hidden loop current more reliable. 4.5
Prediction, “What-If” Simulation, and Optimization Operations
Layer 4 uses the output of the fused trans-domain model for future prediction, analysis of what-if scenarios, and evaluation of optimization options. By “what-if”, this article refers to testing interventions, constraints, disturbances, objectives, or alternative decisions and comparing their consequences across multiple domains. This role is consistent with the general definition of DT, which considers DT as a tool for monitoring, prediction, analysis, control, and decision-making [18, 26]. However, in TDDT, prediction is performed in order to evaluate the simultaneous effect of multi-domain state, risk, uncertainty, and constraints; an issue that is also consistent with the literature on Composite 13
Trans-Domain Digital Twin: Conceptual Foundations, Architecture, and Research Outlook
Direct model Da
Trans-domain effect
Re rn
ef
of
fe ct
Hidden loop path
tu
Comparison in domain a
Tr a
ct
ffe
ns f
er
ee
of
th
Direct estimate: Observed state:
Hidden loop current signature The effect of one domain returns to the original domain after passing through one or more independent domains, and becomes observable as an inconsistency among outputs, estimates, or constraints.
Figure 7: Schematic representation of hidden loop current: The effect of domain (Da ) reaches domain (a) through both the direct path and the hidden path passing through independent domains; the difference between the direct estimate and the observed state activates the hidden loop current index (LCI), and is interpreted as a cyclic error signature.
DTs / Systems-of-Systems and multi-domain models of complex infrastructures [22, 15]. When the execution of multi-model scenarios and co-simulation is required, standards such as FMI can also be used for model exchange, co-simulation, and scheduled execution of models [26]. In this layer, to reduce computational cost, generate fast scenarios, and estimate uncertainty, models such as surrogate models, reduced-order models, simplified physics-based models [45], PINN, Gaussian Process emulator [23], or approximate generative models can be used for reducing computational cost, generating fast scenarios, and estimating uncertainty. If the Gaussian model is used for uncertainty prediction, output-error modeling, or generating a fast approximation of scenarios, its main position is in this layer; however, if it is used for error correction with real data, it is transferred to Layer 7 in this architecture. Genetic algorithms [51] are also mainly located in this layer for searching scenarios and finding the optimal combination of variables/parameters.
4.6
Decision, Recommendation, or Control Action
Layer 5 is the layer that transforms the output of prediction and scenario evaluation into an operational decision, managerial recommendation, control policy, or real-time atomic command; that is, it generates the smallest executable action on an actuator, setpoint, or operational policy and sends it to the next layer. In this layer, the decision function simultaneously evaluates multi-domain error, risk, energy, health, cost, quality, sustainability, and uncertainty. This role is consistent with the definition of DT as a tool for representing, monitoring, predicting, controlling, and optimizing cyber–physical systems [18, 11], and in TDDT it is extended to the level of multi-domain decision-making [22, 15]. Since the fused trans-domain model provides the decision layer with the shared state, constraints, uncertainty, and mutual effects of domains, decision-making in TDDT can rely on model-based predictive control such as MPC22 , instead of blindly searching among options, in order to select constrained and executable actions over a future time horizon [22, 52]. Based on the current state, prediction of system behavior over the future horizon, operational constraints, and the multi-criteria objective function, MPC computes an optimal control sequence; usually, its first command or executable action is sent to the execution layer as an atomic command, and the process is repeated in the next step with new data. Therefore, in the TDDT architecture, MPC [52] can transform the multi-domain predictions of Layer 4 into a decision, setpoint, or actuator command [18, 11].
22
Model Predictive Control
14
Trans-Domain Digital Twin: Conceptual Foundations, Architecture, and Research Outlook
4.7
Real Executable System and Decision Application Environment
Layer 6 is the execution view of the real system in TDDT; that is, the part of the multi-domain physical world on which the output of the decision-making layer is applied, and whose real response is returned to Layer 7 for error calculation and online adaptation. The difference between this layer and Layer 1 is that Layer 1 describes the general structure of physical, biological, cyber, economic, and environmental entities as the source of data and the operational context; whereas Layer 6 represents the execution view of the same system at the time of decision application, that is, the place where commands, recommendations, or control actions are actually executed. This role is consistent with the general definition of DT, which emphasizes the bidirectional connection between the physical entity and the digital model/representation [18], and, in cyber–physical systems, also includes the control and optimization of the behavior of the real system [11]. In this layer, real data on disturbances, execution constraints, actuator error, human behavior, and decision consequences appear; this necessity is consistent with the literature on Composite DTs / Systems-of-Systems, the challenges of DT integration, and multi-domain models of complex infrastructures [22, 12, 15]. 4.8
Error Feedback, Online Tuning, and Automatic Adaptation
Layer 7 calculates the error between the predicted output and the real behavior of the system and uses it to update models, states, weights, constraints, parameters, confidence level, uncertainty, and, if needed, the coupling structure; therefore, uncertainty adaptation is performed in this layer, and its output is returned to Layers 2 and 3 so that the next prediction and decision become consistent with real conditions. This is the layer of feedback and online adaptation on offline-learned knowledge, because a DT gains higher operational value when it adapts to new data, the real state, and changing conditions; an issue that is consistent with the definition of DT as a bidirectional connection between the physical system and the digital representation [18], as well as with the role of DT in the control, prediction, optimization, and self-adaptation of cyber–physical systems [11, 20]. Control or corrective feedback, before being applied to the real system, must pass through the device communication sublayer so that the command can be checked in terms of actuator identifier, allowable range, unit, application time, actuator health status, receipt acknowledgment, and safety constraints. Therefore, the online adaptation of TDDT is performed at the conceptual level of models, but its physical execution depends on the standard sensor/actuator interface and the operational gateway. If the Gaussian model is used for online tuning, discrepancy estimation, residual correction, error calibration, or parameter updating with real data, its main position is in Layer 7. In this case, the Gaussian output is not directly a control command; rather, in this architecture, it is a correction for the model, weight, constraint, parameter, or uncertainty, which returns through the feedback path to Layer 2 and Layer 3 and then affects the subsequent decisions of Layers 4 and 5 [23, 24]. 4.9
Single-Episode Offline Training and Transformation of Trans-Domain Experience
In the TDDT framework, single-episode offline training is defined as a continuous process in which domain-specific simulators, the fused model with appropriate fidelity, the predictive decision-maker, and the memory layer are executed together within a single time horizon. The purpose of this training is to provide trans-domain prior knowledge to TDDT before online execution; in such a way that the interaction among state, decision, cost, constraint, and domain feedback is transformed into experience usable by progressive temporal coupling, and the need for costly and high-risk online learning, especially in biological, health, and military applications, is reduced. This logic is aligned with the idea of decision-driven digital twins, predictive control, and multi-domain architectures [25, 53, 15]. In this process, MPC is used as the predictive decision-making layer for selecting control actions under constraints and uncertainty [25]. 4.9.1
Preparation of CRP and SARG Reference Datasets
Data preparation in TDDT is performed through two complementary pathways. In the CRP23 pathway, historical, simulated, or operational data related to the context of each scenario—such as environmental conditions, system state, mission phase, individual characteristics, resources, disturbances, and sensor quality—are collected, cleaned, unit-harmonized, time-synchronized, and resampled at the appropriate temporal scale. Then, for each interval, the contextual feature vector (xc ) is extracted and, after normalization, similar samples are classified into Context Reference K Patterns using clustering or similarity-based methods: (CRP = Ck = (µk , Σk , nk , qk )k=1 ), where (µk ), (Σk ), (nk ), and (qk ) respectively represent the context, dispersion, number of samples, and cluster quality. Therefore, in UAV 23
Context Reference Patterns
15
Trans-Domain Digital Twin: Conceptual Foundations, Architecture, and Research Outlook
navigation, CRP can represent wind regimes, topography, sensor quality, and flight phase; and in personalized treatment, it can represent phenotype, disease stage, patient status, and history of response to treatment. In the SARG24 pathway, the outputs of valid scenarios, optimized simulations, expert opinions, or past successful decisions are divided based on temporal or operational stages, and for each stage, the desired behavior, safe limits, objectives, constraints, and decision weights are extracted. Each guidance pattern can be defined as (Gs = (zs∗ , a∗s , Js∗ , C ∗ s, ws , γs )), which respectively indicates the desired state, reference action, optimal cost or performance, constraints, objective weights, and confidence level of stage (s); as a result, (SARG = Gs ∗ s = 1S ) forms the staged desired pathway. During training or execution, the current context is mapped to the nearest CRP cluster, and the corresponding SARG is transferred to the optimizer as a prior, guidance, or weight adjustment; therefore, CRP answers “what type of context is the system currently in?” and SARG specifies “what is the desired and optimal behavior in this stage and context?”. 4.9.2
Generation, Aggregation, and Transfer of Knowledge in Progressive Single-Episode Loops
At each step of the fast loop, the domain-specific twins and the fused model predict the current state, and the modelbased decision-maker selects the appropriate action under the existing constraints and objectives. The result of each step is stored in the step-stream memory as a temporal record, including the trans-domain shared state, decision, action, cost or reward, active constraints, uncertainty, guidance, and decision weights: efast = STD (t), ŜTD (t + 1), at , Jt , Ct , Ut , gt , wt t
(2)
At the end of each operational period, the set of fast records is aggregated in the slow loop in order to extract long-term trends, the cumulative response of domains, resource consumption, changes in constraints, state coverage, and decision quality. The output of this stage is a compact episodic record that is stored in the single-episode trans-domain knowledge repository. This record preserves the relationship among context, state, decision, outcome, uncertainty, and the mutual effects of domains, and transforms short-period knowledge into experience usable over longer time horizons; then, the guidance extracted from the slow loop is returned to the fast loop to correct the decisions of the next cycle: eepisode = Aggregate d
efast t t∈d
(3)
In the meso loop, the contextual features of the aggregated record are first matched with CRP clusters in order to determine the corresponding Context Reference Pattern; then, according to the current stage and the detected context, the corresponding desired pattern is selected from SARG. The difference between the observed or simulated behavior and the desired pattern, together with constraints, uncertainty, and matching quality, is transformed into an inter-loop guidance signal: CRP SARG gdmeso = MRG eepisode , C , G k s d
(4)
In this relation, MRG25 is the inter-loop guidance process or signal that compresses the result of matching the current context with CRP and comparing the stage-wise behavior with SARG. This signal is returned to the fast loop in the next cycle to correct the objectives, decision weights, constraints, and optimizer parameters. The knowledge-transformation pathway is summarized in Figure 8. At the end of the episode, the fast records, cumulative knowledge, CRP cluster identifier, selected SARG pattern, MRG guidance, and final weights are stored in the trans-domain knowledge package so that the online controller begins its operation from a valid prior knowledge base, not from zero-shot learning. Figure 9 shows the temporal and simplified view of this circulation, and Figure 10 describes the stages of data processing and transformation across the fast, meso, and slow loops. Along this pathway, SS-KStore26 serves as the streaming memory for the step-by-step experiences of the fast loop during training, whereas SETD-KStore27 transforms these experiences, after episodic aggregation, into a compact, trans-domain, and loadable knowledge package for online control. 24
Stage-Aware Reference Guidance Meso Reference-Guidance 26 Step-Stream Memory Knowledge Store 27 Single-Episode Trans-Domain Knowledge Store 25
16
Trans-Domain Digital Twin: Conceptual Foundations, Architecture, and Research Outlook
Fast experience
Episode aggregation
Experience formation
SARG selection / comparison
CRP matching Reference-pattern processing
MRG
Decision-weight update
Guidance and adaptation
Figure 8: Knowledge-transformation pathway in the proposed single-episode TDDT training process. Fast-loop experiences are aggregated into episodic knowledge, matched with CRP, compared with SARG, and compressed into MRG for updating decision weights in the subsequent cycle.
Legend
Domain-specific twins / simulators Fast-step experience records Aggregated episodic knowledge Operational period containing fast steps Beginning of the period End of the period Fast operational loop (Inner) Slow aggregation loop (Outer) Meso reference-guidance loop (Inter) Direction of time CRP context matching and SARG behavior comparison CRP: Context Reference Patterns
TDDT Single-Episode Offline Training Environment
SARG: Stage-Aware Reference Guidance MRG: Meso Reference-Guidance signal
Figure 9: Simplified representation of single-episode learning in the progressive coupled loops of TDDT: At each fast step, state, decision, cost, guidance, and decision weights are stored as short-period knowledge; then this knowledge is aggregated at a slower scale, compared with CRP and SARG, and its result is returned to the optimizer and controller as compact guidance.
5
General Formalism and Operational Logic of TDDT
5.1
General TDDT Formalism
The following formalism provides a minimal representation of the architecture proposed in this article [11, 12, 20, 17, 21, 22]: TTD = ⟨D, STD , C, L, J , U, K, F⟩ ,
D = {Di }ni=1 ,
n≥2
(5)
In this relation, (D) denotes the set of domain twins, (ST D ) the aligned shared or distributed state, (C) the couplings, (L) the temporal policy, (J ) the objectives and constraints, (U) the decision, (K) the optional knowledge, and (F) the feedback. 17
Trans-Domain Digital Twin: Conceptual Foundations, Architecture, and Research Outlook
Modelbased decision
CRP: Context Reference Patterns
State
MRG: Meso ReferenceGuidance signal
Inter-period aggregation
Context
Inter guidance
Weight updating
SARG: Stage-Aware Reference Guidance
Step-Stream Memory (SS-KStore)
Episodic aggregation
Trans-Domain Knowledge Store (SETD-KStore)
Compressed knowledge / Guidance
Prediction
Experience (et)
Action
Figure 10: Data-processing details in the progressive TDDT loops: the fast path generates the sequence of state prediction, model-based decision, action, and experience for each step and stores it in SS-KStore; the slow path transforms step-by-step experiences into cumulative knowledge in SETD-KStore; and the meso path uses CRP, SARG, and MRG to update the context, inter-loop guidance, and decision weights for the next cycle.
STD (t) = A (x1 (t1 ), . . . , xn (tn ), m, q, Σ) zj (t) =
X
(6)
Cij (yi (t − τij ), STD (t))
(7)
i̸=j
u∗TD (t) = arg
min
u∈Ufeasible
" n X
# wi Ji (STD , u) + λR R + λU U
(8)
i=1
eTD (t) = yreal (t) − ŷTD (t)
(9)
ΘTD (t + 1) = H (ΘTD (t), eTD (t), STD (t), UTD (t), Route(eTD ))
(10)
A system is compatible with this formalism only when it includes at least two heterogeneous twins, a traceable operational coupling, an aligned state, multi-domain-based decision-making, and a feedback pathway. The model type, optimizer, number of loops, and memory mechanism are application-dependent. 5.2
Trans-Domain Objective Function and Multi-Criteria Decision-Making
In TDDT, due to the transfer of risk or cost from one domain to other domains, the final decision should not be made based on the local optimization of a single domain. Therefore, the trans-domain objective function must simultaneously consider multiple objectives such as performance, safety, energy, sustainability, cost, health, risk, uncertainty, and control quality; this logic is consistent with the role of DT in optimization, decision-making, and uncertainty management [54, 33]. In general, the TDDT objective function can be represented as follows: JT D = w1 Jphysical + w2 Jbiological + w3 Jenergy + w4 Jcyber + w5 Jeconomic + w6 Jenvironmental + w7 Jrisk + w8 Juncertainty
(11)
In this relation, each (J) represents the cost, error, risk, or objective in a domain, and each (w) indicates the decision weight of that domain. A trans-domain decision is selected when it produces the lowest total cost or the highest total utility while satisfying multi-domain constraints: uT D = arg min JT D uT D
(12)
Therefore, TDDT goes beyond the level of prediction and becomes a decision-support or control-support mechanism that compares different scenarios based on the shared consequences of multiple domains [7, 54, 33]. 18
Trans-Domain Digital Twin: Conceptual Foundations, Architecture, and Research Outlook
5.3
Uncertainty and Model Correction in Offline Training
Considering the scenario-based, low-volume, and structured nature of the preprocessed climate data selected as a dataset from high-importance offline states in the target domain, a lightweight uncertainty estimator can be constructed in the offline loop of Layers 2, 3, and 4. In this framework, the output of domain-specific simulators in Layer 2 is compared with the reference output, mirror output, or the output of the fused model in Layers 3/4, and the resulting residual, together with critical scenarios and boundary states, is transferred to the high-importance offline dataset or Bayesian pseudo-coreset; this set is then used as training data for the mirror error function and the UQ surrogate (Figure 11). The combination of Uncertainty Quantification methods with process approximations creates a fast model surrogate that estimates the predicted mean error and predictive variance for each new scenario. In this case, predictive variance is an indicator of increased uncertainty, departure from the validity domain, or the probability of error transfer among domains; therefore, Coupling Error detection is performed through the combination of residual, predictive variance, and the dependency pattern among the outputs of domain-specific twins [9]. Models such as Sparse GP / inducing points and Random Fourier Features / RFF are candidates for these process approximations [55, 56]. The high-importance offline dataset, in the role of a Bayesian pseudocoreset or statistical coreset, is a small, weighted, and representative subset of the state space that summarizes the posterior distribution of system parameters with minimal approximation error relative to the full data [57]. These data can be selected through methods such as one-shot sampling, active learning, global coverage of the space, and information maximization in sensitive regions [58]. In practice, this set acts as a compact database of residuals, outputs of high-fidelity simulators, and critical/boundary scenarios, and, with the help of a surrogate model, enables fast estimation of uncertainty and error transfer through the Error Coupling path to TDOC without rerunning the full simulator [55, 59]. 5.4
Error Feedback and Model Correction at Runtime
In the online phase, runtime error is generated after the decision is applied in the real execution environment from Layer 6 and is transferred to Layer 7. This feedback from the physical system to the virtual model is considered necessary for validation, updating, completing the simulation model, and increasing prediction accuracy [3, 4, 60]. This feedback can correct the shared state, the parameters of domain-specific twins, the confidence level, and uncertainty, and, in the proposed TDDT framework, in an extended form, it also updates the weights of the objective function, decision constraints, and the coupling intensity among domains [4, 54, 60]. In general, the online trans-domain error after decision execution in the real system is defined as follows: eonline (t) = yreal (t) − yT DDT (t) TD
(13)
This error is traced by the condition (Route(eT D )); that is, the feedback return path is differentiated between Layer 2 and Layer 3 depending on the dominant location where the error is generated. If the error originates from the model, parameter, simulator, or state of a specific twin, the feedback returns to Layer 2; however, if the error is generated after state alignment, construction of the shared state, semantic/time synchronization, coupling, constraints, objectives, or shared uncertainty, the feedback is transferred to Layer 3. In the case of a combined error, simultaneous or sequential correction of Layers 2 and 3 is performed. Layer 2, Route(eTD ) = Layer 3, Layer 2 + 3,
if edomain > τdomain , if ealignment + ecoupling + esync > τTD ,
(14)
if both error groups exceed their thresholds.
Therefore, model correction at runtime can be represented as follows: θTD (t + 1) = θTD (t) + ∆θ eonline TD (t), STD (t), UTD (t), Route(eTD )
(15)
In this relation, (θT D ) denotes the parameters of models, weights, constraints, and couplings; (eonline ) is the observed TD error after real execution; (ST D ) is the trans-domain shared state; (UT D ) is the system uncertainty; and (Route(eT D )) is the condition that determines the feedback path between Layer 2 and Layer 3. Therefore, TDDT creates an online closed loop in which the real environment feeds the domain-specific twins; the twins evaluate the future and scenarios; the trans-domain objective function selects the decision; the decision is executed in the real system; and the returned error, 19
Trans-Domain Digital Twin: Conceptual Foundations, Architecture, and Research Outlook
Offline Error Function and High-Importance Dataset Domain-Specific Twins / Simulators
Inner Simulator
Mirror / Reference Models
≈
Inner Mirror
Compare
Meso Simulator
≈
Meso Mirror
Compare
Outer Simulator
≈
Outer Mirror
Compare
Residuals simulator output − mirror/reference output
High-Importance Offline Dataset .
(Bayesian pseudo-coreset / statistical coreset) critical scenarios + boundary states + weighted samples
.
UQ Surrogate / Mirror Error Function
used for offline training and uncertainty correction
mean predicted error + predictive variance
Error Coupling
TDOC Trans-Domain Orchestration Core
Figure 11: Offline Error Function and High-Importance Dataset: The outputs of the inner, meso, and outer simulators are compared with the corresponding mirror models, and the resulting residual, together with critical scenarios and boundary states, is stored in the form of a high-importance offline dataset or Bayesian pseudo-coreset. This set is used to train the mirror error function, construct the UQ surrogate, estimate the mean error and predictive variance, and then transfer the error through the Error Coupling path to TDOC.
depending on its origin, corrects either the domain-specific models or the fused trans-domain model for subsequent decisions [3, 4, 54, 60].
6
Conceptual and Architectural Distinction between CDDT and TDDT
After examining the details of the conceptual design of TDDT, we can conduct a comparison between the two approaches of TDDT and CDDT. 6.1
Conceptual Distinction between CDDT and TDDT • CDDT: First itemThis approach seeks to identify commonalities, differences, and reusable development processes across different domains in order to create reference models, shared development methods, and generalizable platforms for digital twins [5, 6]. In this case, domains maintain their independent identity, and integration is mainly performed at the levels of data, semantics, model architecture, and software structure. Its key objective is to answer the question of how digital twins in different fields can be made comparable, reusable, interoperable, and, as far as possible, standardized. 20
Trans-Domain Digital Twin: Conceptual Foundations, Architecture, and Research Outlook
• TDDT, with a focus on operational integration and a unified dynamic system: This concept, within the proposed framework of this article, is close to the literature on composite complex systems or System-ofSystems [61, 62, 63] and goes beyond the comparison or semantic connection of domains; its objective is to construct a unified operational system from heterogeneous domains [20]. In this approach, domains are integrated into a shared causal and decision-making dynamic loop, such that the output, error, or behavior of one domain can directly affect the control, prediction, and dynamics of another domain and lead, at the whole-system level, to emergent behaviors and simultaneous multi-domain decision-making. In fact, CDDT asks: “How can digital twins in different domains be compared, standardized, made reusable, and rendered interoperable with one another?” Whereas TDDT asks: “How can several heterogeneous domains be connected within a single digital twin in such a way that the output, error, and decision of each domain change the behavior and control of other domains?”
6.2
Layered Architectural Distinction between CDDT and TDDT
This section shows their difference in terms of layered arrangement and the flow path of data, model, state, decision, and control. In a CDDT, the layers usually include physical/domain systems, independent twins of each domain, the interoperability and semantic mapping layer, the reference model or reusable components layer, and the comparative applications or decision-support layer. The objective of this architecture is to discover common patterns, standardize, share data, develop general-purpose tools, and increase reusability across domains [6, 64]. In contrast, in TDDT, the intermediate layer is transformed into a fused trans-domain model that creates the shared state, operational coupling, and temporal synchronization; therefore, the output of one domain is not used only for comparison or interoperability, but can change the state, error, constraint, objective, decision, or control of another domain [65]. Accordingly, Figure 12 should be read as the architectural representation of this transition: the transition from CDDT layers based on interoperability and reuse to TDDT layers based on fused state, operational coupling, feedback, and trans-domain control.
CDDT
TDDT
Cross-Domain Digital Twin
Trans-Domain Digital Twin
Typical focus: comparison, standardization, interoperability, reuse
Focus: operational coupling between domains
Typical connection: data exchange, APIs, semantic/ontology mapping, model adapters
Type of connection: data, model, state, error, objective, control
Domain status: semantically/interoperably connected, but operationally mostly independent
Domain status: dependent and mutually influential
Output: cross-domain monitoring, dashboard, reporting, decision support
Output: joint decision-making and joint control
Limitation: no inherent operational coupling
Key capability: shared state + feedback loop
Transition from interoperability
Trans-domain decision-making Joint decision-making and control between domains
Reuse and comparison between domains
Figure 12: Layered Distinction between CDDT and TDDT: On the CDDT side, domain-specific twins are mainly connected through the layers of interoperability, semantic mapping, reference models, and comparative/decision-support applications; however, on the TDDT side, the outputs of domain-specific twins enter the fused trans-domain model and, through the shared state, operational coupling, temporal synchronization, decision-making, and online feedback, lead to multi-domain control or correction. 21
Trans-Domain Digital Twin: Conceptual Foundations, Architecture, and Research Outlook
This distinction is also consistent with the literature on composite and federated DTs; for example, in federated simulation, a production line can be constructed from several independent DTs with separate simulation models, but this composition still requires a formal mechanism for model interaction and composition [65].
7
Conceptual Validation of the Proposed TDDT Framework
The validation presented in this section is conceptual and based on internal consistency, requirements traceability, and scenario-based walkthrough; therefore, it does not replace verification, validation, uncertainty quantification, or field evaluation of a real implementation [3, 66, 67]. The objective is to examine whether the architectural components can coherently address the gaps and requirements defined in Sections 3 and 4. 7.1
Scope and Level of Validation
Validation is conducted at three levels: 1. Structural : the presence of the required architectural components; 2. Behavioral : the capability to transfer effects among domains; 3. Decision-related : the use of multiple domains in decision-making and feedback. The numerical validity of the models, prediction accuracy, and operational safety are outside the scope of this conceptual evaluation and must be examined in future implementations [66, 67, 68]. 7.2
Structural Validation and Requirements Traceability
To examine internal consistency, each research gap and minimum requirement is mapped to its corresponding architectural component. Figure 13 presents a conceptual mapping between the minimum TDDT requirements and the architectural components proposed in this article.
Measurable Requirement
Responding Architectural Component
Conceptual Evidence
Status
At least two heterogeneous digital twins
Layer 2
{Di}, n ≥ 2
Covered
Temporal and semantic alignment
Layer 3.1
and the alignment operator
Covered
Operational coupling
Layer 3.2
and coupling types
Covered
Temporal coordination
Layer 3.3
Synchronization policy and temporal loops
Covered
Trans-domain decision-making
Layers 4 and 5
Shared objective function and joint decision
Covered
Decision execution
Layer 6
Command execution in the real system
Covered
Error feedback and correction
Layer 7
and Route
Covered
STD
Cij
eTD
Figure 13: Conceptual traceability matrix between the minimum TDDT requirements and the corresponding architectural components. The matrix shows how heterogeneous twins, state alignment, operational coupling, temporal coordination, trans-domain decision-making, execution, and error feedback are represented in the proposed architecture. This mapping only demonstrates the conceptual completeness of the architecture and does not prove the correctness, adequacy, or practical performance of each component. The framework is considered conceptually consistent if: 1. each minimum requirement is addressed by at least one architectural component; 2. no trans-domain decision is generated without data or states from multiple domains; 3. each coupling has a specified source, destination, type, and temporal scale; 22
Trans-Domain Digital Twin: Conceptual Foundations, Architecture, and Research Outlook
4. each observed error has a defined correction pathway. 7.3
Walkthrough of a Representative Scenario
In an enclosed livestock facility, the climate, biology/growth, energy, and control twins are considered heterogeneous domains. An increase in temperature and gas concentration changes the climate state; growth status and feed intake update the biological constraints; and energy cost affects the decision function. These outputs are aligned in (ST D ) and enter the ventilation decision through state, objective, and control coupling. The actual system response is then returned to the feedback layer as an error [69, 70, 71].
Progressive sequence
Figure 14 illustrates the proposed trans-domain sequence for the closed-livestock example, from environmental change to decision execution and error feedback.
Stage
Input / Event
Trans-Domain Transfer
Output
1
Temperature and gas increase
Climate → Biology / Energy
Update STD
2
Health and energy constraints
Objective coupling
Revise weights and constraints
3
Scenario evaluation
Multi-domain decisionmaking
Ventilation command
4
Real-system response
Error coupling
Model or coupling correction
Figure 14: Illustrative trans-domain walkthrough for a closed livestock environment. Temperature and gas changes propagate to the biological and energy domains, revise objectives and constraints, generate a ventilation decision, and return the observed system response through error coupling for model or coupling correction. Accordingly, four tests are proposed: • Removal of the shared state : decisions are restricted to unaligned information; • Removal of objective/control coupling : the system is reduced to multiple parallel twins; • Removal of temporal coordination : domain outputs may become inconsistent; • Removal of feedback : errors are not corrected in subsequent cycles. Failure in any test indicates that the removed component has a structural role in the proposed TDDT formulation; however, the magnitude of its effect must be determined through ablation or practical experimentation. 7.4
Acceptance Criteria and Validation Limitations
Figure 15 summarizes the proposed conceptual acceptance dimensions used to assess the internal conformity of a TDDT architecture. Satisfaction of these criteria only indicates conceptual compliance with the proposed architecture. Practical validity requires code and model verification, validation using real-world data, uncertainty quantification, sensitivity analysis, robustness testing, and safety evaluation [66, 67, 68, 72].
8
TDDT Maturity Model
The maturity model presented in this section is a proposed classification for describing the transition from independent twins to adaptive TDDT. A higher level is not necessary or desirable for every application, and the target level should be 23
Trans-Domain Digital Twin: Conceptual Foundations, Architecture, and Research Outlook
Dimension
Conceptual Acceptance Criterion
Completeness
Coverage of all minimum requirements
Traceability
Clear identification of the source, destination, and type of each coupling
Temporal
Definition of a synchronization rate or policy
Decision-Making
Participation of at least two domains in the decision
Feedback
Ability to route an error to the component that can be corrected
Uncertainty
Recording the source or level of uncertainty
Figure 15: Proposed conceptual acceptance dimensions for TDDT. The criteria assess completeness, coupling traceability, temporal coordination, multi-domain participation in decision-making, feedback routing, and uncertainty recording; satisfying them indicates conceptual conformity rather than practical validity.
selected based on risk, cost, data, and decision-making requirements [2–4,7,12,18,22,29,30]. This model differs from the Monitoring–Predictive–Prescriptive–Autonomous functional classification; a DT may be functionally autonomous, yet without coupling among domains, it is not considered a TDDT [2,7,18,28].
Increasing architectural maturity
Figure 16 presents the proposed architectural maturity levels from independent domain twins to adaptive and trustworthy TDDT.
Level
Title
Core Capability
Minimum Criterion
L0
Independent Twins
Separate models and decisions
Each domain operates independently
L1
Data Connectivity
Data exchange, APIs, or a shared dashboard
Data are transferred between at least two domains
L2
Interoperability and Aligned State
Semantic, unit, temporal, and quality mappings
An aligned shared state or distributed representation exists
L3
Operational Coupling
The model, state, or error of one domain affects another
At least one traceable cross-domain effect exists
L4
Trans-Domain Decision-Making
Objectives, constraints, and decisions based on multiple domains
At least two domains participate in the final decision
L5
Trans-Domain Closed-Loop Control
Decision execution and feedback from the real system
Error is routed back to a model, state, or coupling
L6
Adaptive and Trustworthy TDDT
Bounded adaptation, uncertainty, safety, and auditability
Adaptation, VVUQ, fallback, and decision-path logging are present
Figure 16: Proposed maturity levels for TDDT implementations. Levels L0–L2 represent independent, connected, and interoperable multi-domain prerequisites; minimum conformity with the proposed TDDT definition begins at L3 with traceable operational coupling, while L4–L6 progressively add joint decision-making, closed-loop feedback, and bounded trustworthy adaptation. Levels L0 to L2 are multi-domain prerequisites, and minimum compliance with TDDT begins at L3. Advancement should be based on evidence of alignment, coupling validity, joint decision-making, feedback, and assurance; the mere presence of an API, dashboard, automated control, or the TDOC designation is not sufficient for level advancement. 24
Trans-Domain Digital Twin: Conceptual Foundations, Architecture, and Research Outlook
Moreover, a higher level does not necessarily guarantee greater accuracy, safety, or practical value and must be assessed using the evaluation protocol of the article [12,22,109].
9
TDDT Deployment Architecture and Software Components
The architecture presented in this section is a proposed reference view for mapping the conceptual layers of TDDT to executable components. The components may be deployed locally, in an edge–cloud configuration, centrally, or in a distributed manner, provided that interoperability, temporal coordination, coupling, decision-making, and feedback are preserved [12, 17, 21, 22, 73]. The logical view includes a device and safety gateway, a message/event bus, domain-twin services, a model adapter, TDOC or an equivalent orchestrator, a shared-state and time service, an ontology service, prediction and decision services, a time-series store, a model registry, a knowledge store, and monitoring/audit. It is not necessary for all components to exist as independent services, and lightweight implementations may integrate multiple roles. Figure 17 shows a reference deployment view that maps these logical roles to the main runtime and supporting software components.
Physical System
Sensors / Actuators
Device & Safety Gateway
Message / Event Bus
Domain-Twin Services
TDOC + Shared-State + Time Service
Prediction / Optimization / Decision
Command Gateway
Actuators
Error / Monitoring / Adaptation
Data Store
Model Registry
Knowledge Store
Ontology
Audit / Provenance
Figure 17: Proposed reference deployment view of the TDDT architecture. Sensor and actuator data pass through the device and safety gateway and message bus to the domain-twin services; TDOC coordinates the shared state, timing, prediction, and decision services, while monitoring, adaptation, data storage, model registration, ontology, knowledge storage, and provenance support the operational lifecycle. Components may be deployed centrally, at the edge, or in a distributed configuration. In the online flow, sensor data are transferred to the domain twins after timestamping, unit conversion, and quality control; TDOC aligns and couples the outputs and sends the decision to the safety gateway; the actual response is then returned to correct the model, state, or coupling. TDOC is a logical role and may be implemented centrally or in a distributed manner. 25
Trans-Domain Digital Twin: Conceptual Foundations, Architecture, and Research Outlook
FMI/FMU can be used for model packaging, HLA for distributed simulation, and ISO 23247 for the conceptual mapping of roles [26, 27, 74]. Data contracts should retain at least the identifier, timestamp, unit, quality, uncertainty, version, and context [17, 73, 75, 76]. This mapping does not imply formal compliance. Low-latency and safety-critical tasks are preferably executed close to the edge, while computationally intensive training, archiving, and model management may be placed on the central platform. Each decision should be traceable to the active versions of the model, data, coupling, and parameters. Latency, availability, scalability, security, observability, and recoverability should also be evaluated in accordance with the level of risk [75, 66, 77, 78].
10
TDDT Evaluation Criteria and Protocol
The criteria presented in this section do not constitute a formal benchmark for all TDDTs, but rather the article’s proposed minimum protocol for evaluating future implementations. The type of metric, baseline, and acceptance threshold should be determined according to the application, risk level, data, and degree of automation [3, 54, 66, 67]. The evaluation should separately examine the domain models, shared state, coupling, temporal coordination, decisionmaking, uncertainty, robustness, computational cost, and end-to-end performance, because validity at one level does not guarantee validity at the other levels [66, 67, 68]. 10.1
Evaluation Dimensions and Criteria
Figure 18 summarizes the proposed evaluation dimensions and representative metrics for future TDDT implementations.
Evaluation Dimension
Example Metrics
Domain Model
MAE/RMSE, bias, calibration, and validity range
Shared State
Temporal, unit, semantic, quality, and missing-data alignment errors
Coupling
Correctness of effect direction, transfer error, and cross-domain consistency
Temporal Coordination
Latency, jitter, synchronization error, and missed deadlines
Prediction
Short- and long-horizon errors and uncertainty-interval coverage
Decision and Control
Objective-function value, feasibility, stability, and constraint-violation rate
Uncertainty
Coverage, calibration, and decision sensitivity
Robustness
Performance degradation and recovery under noise, delay, failure, and context shifts
Computation
Execution time, memory use, processor utilization, and scalability
System Level
Improvement over baselines and safe-failure rate
Figure 18: Proposed evaluation dimensions and example metrics for TDDT implementations. The dimensions separately address domain-model validity, shared-state alignment, coupling, temporal coordination, prediction, decision and control, uncertainty, robustness, computational performance, and system-level improvement. The listed metrics are illustrative and should be selected according to the application and risk level. These metrics are illustrative, and not all of them are mandatory in every application; however, the omission of any dimension should be justified [54, 66, 67]. The following relations can be used to evaluate certain TDDT-specific components:
Rcv =
Nviolated Nevaluated
which represents the constraint violation rate, and: 26
(16)
Trans-Domain Digital Twin: Conceptual Foundations, Architecture, and Research Outlook
GTD =
MTDDT Mbaseline
(17)
which represents the gain or change in TDDT performance relative to the baseline. The direction of the difference should be determined according to the nature of the metric, such as benefit, cost, or error. 10.2
Minimum Evaluation Protocol
The proposed protocol includes the following steps: 1. Define the application domain, objectives, constraints, and risk level; 2. Determine the reference data, scenarios, and validity range; 3. Independently validate each domain twin; 4. Evaluate the shared state and data alignment; 5. Separately test each coupling; 6. Evaluate temporal coordination and latency; 7. Evaluate decision-making, feasibility, and constraint satisfaction; 8. Compare against baselines; 9. Conduct ablation, sensitivity analysis, and stress testing; 10. Report uncertainty, computational resources, limitations, and reproducibility. The acceptance criterion for each stage should be defined before testing and based on the application risk, and should not rely solely on a general threshold [66, 67]. 10.3
Baselines and Ablation Testing
The minimum baselines should include independent domain twins, a multi-domain architecture with data exchange but without operational coupling, TDDT without online adaptation, and the conventional application-specific decisionmaker. The superiority of TDDT should be claimed only when an improvement in the target metric is observed without an unjustified increase in constraint violations, uncertainty, risk, or computational cost. To determine the contribution of the architectural components, the complete system should, where possible, be compared with versions without a shared state, without state coupling, without objective/control coupling, without online feedback, and without an uncertainty model. Removal of the meso loop or single-episode training mechanisms should be examined only in implementations that include these components, because these components are not general requirements for all TDDTs. 10.4
Robustness and Uncertainty Testing
Robustness should be tested at least against sensor noise, delay, missing data, model error, coupling error, failure of a twin, and context changes. In each test, performance degradation, decision changes, error propagation, recovery time, and fallback behavior should be reported [66, 67, 68, 72]. Uncertainty should also be distinguished at least by its data, model, coupling, and decision sources. Its evaluation should include coverage, calibration, sensitivity analysis, and examination of decision changes under uncertainty; a narrow interval alone is not an indication of validity [24, 54, 67, 68]. 10.5
Temporal Performance and Results Reporting
In online applications, in addition to the mean execution time, high latency percentiles, jitter, missed deadlines, memory consumption, and changes in cost as the number of twins increases should be reported. The use of surrogate models, Sparse GP, or computational-cost reduction methods should be evaluated together with the potential loss of accuracy and changes in uncertainty [55, 56, 57, 58]. Each evaluation should report the data and scenarios, model versions, active couplings, temporal rates, baselines, metrics, uncertainty intervals, computational resources, failure tests, and limitations of generalization. Simulation results only indicate performance within the simulated scenario and should not be generalized to laboratory, field, or operational validity without independent evidence [3, 66, 67]. 27
Trans-Domain Digital Twin: Conceptual Foundations, Architecture, and Research Outlook
11
Failure Management, Fallback, and Operational Safety
This section presents the proposed reference requirements for limiting the effects of failures and uncertain decisions in TDDT. The type of response and level of redundancy should be determined according to the application and the consequences of the hazard [18, 33, 66, 67]. Failures may originate from sensors, data, models, coupling, timing, networks, decisions, or adaptation, and may propagate to other domains through the shared state [3, 66, 67, 68]. Before execution, the safety gateway should verify the command range, rate of change, timing, actuator health, hard constraints, and confidence. A command is executed only if it passes the safety test; otherwise, the system should revert to the last valid bounded state, exclusion of the uncertain domain, a local controller, a conservative policy, human override, or safe shutdown. The fallback mechanism should be simple, independent, and pre-validated, and its objective should be to preserve safety or minimum service rather than to continue optimal operation [52]. In the event of a failure in a twin or coupling, its effects should be mitigated or quarantined, and the system should operate in a degraded mode. Online updates should also be bounded, versioned, and rollback-capable, and should be suspended when data are insufficient, uncertainty is high, or a constraint is violated [11, 24, 54, 67, 68]. Return to normal operation should be permitted only after a health check, alignment, consistency verification, and a period of stable operation. All failure, veto, fallback, rollback, and recovery events should be recorded together with the versions of the models, data, and active couplings. The presence of these mechanisms does not demonstrate safety, and their adequacy should be examined through hazard analysis, fault-injection testing, stress testing, VVUQ28 , and practical evaluation [66, 67, 68, 72, 77, 78]. Figure 19 summarizes the proposed runtime-safety, failure-management, fallback, and recovery requirements and their corresponding verifiable evidence.
Safety and Recovery Requirement
Verifiable Evidence
Health Monitoring
Health status of data, models, couplings, and actuators
Command Validation
Checks on operating range, rate of change, timing, and constraints
Fault Isolation
Ability to disconnect or reduce the influence of a faulty component
Degraded Operation
A limited and explicitly defined service mode
Fallback
A validated alternative controller or policy
Safe Stop
Ability to perform a controlled shutdown
Rollback
Restoration of models and parameters to a validated version
Human Override
Risk-proportionate human intervention capability
Audit
Complete logging of causes, decisions, and versions
Recovery Test
A clear criterion for returning to normal operation
Figure 19: Proposed runtime-safety, failure-management, and recovery requirements for TDDT. The table links health monitoring, command validation, fault isolation, degraded operation, fallback, safe stopping, rollback, human override, audit, and recovery testing to their expected verifiable evidence. These requirements support safety assessment but do not by themselves constitute a formal safety guarantee.
12
Provenance, Versioning, and Model Lifecycle
The requirements presented in this section constitute the proposed minimum mechanisms for tracing data, models, coupling, and decisions in TDDT [3, 75, 66, 74]. Each important output should, as far as possible, be traceable to the data source, timestamp, model version, parameters, active couplings, uncertainty, and decision version. This traceability is necessary for decision reconstruction and rollback, but it does not guarantee the correctness of the decision [75, 66]. 28
Verification, Validation, and Uncertainty Quantification
28
Trans-Domain Digital Twin: Conceptual Foundations, Architecture, and Research Outlook
Versioning should cover data, domain models, ontology, coupling, constraints, the objective function, and training knowledge. Each version should have an identifier, time, reason for change, validity range, and lifecycle status. The proposed lifecycle includes Draft, Verified, Validated, Approved, Deployed, Monitored, and Retired; the names of the stages may differ, but experimental and operational versions should be distinguished from one another [66, 67]. Figure 20 illustrates the proposed lifecycle of a domain model or coupling from initial development to operational monitoring, updating, or retirement.
Draft
Verified
Validated
Approved
Design and assurance
Deployed
Monitored
Updated or Retired
Operation and governance
Figure 20: Proposed lifecycle of a domain model or coupling in TDDT. A candidate component progresses from draft through verification, validation, approval, deployment, and monitoring, after which it may be updated or retired according to performance, uncertainty, validity-range, and governance evidence. A new model or coupling should be released only after evaluation using independent data, uncertainty, constraints, latency, and comparison with the active version [24, 54, 66, 67]. The operational version should be monitored for drift, residuals, calibration, and context changes, and in the event of performance degradation, constraint violation, or inconsistency, mechanisms should be available for confidence reduction, shadow mode, fallback, or rollback to the latest valid version [54, 66, 67, 68]. Each decision should be recorded together with the versions of the models, couplings, shared state, objective function, constraints, uncertainty, and the safety gateway result. The retention, access, archiving, and deletion policies for these records should comply with confidentiality and legal requirements [75, 77, 78]. The presence of provenance and versioning alone does not demonstrate validity, safety, or accountability and should be evaluated in terms of correctness, security, and reconstructability.
13
Threats to Validity and Scope of Claims
In this article, TDDT is a proposed conceptual formulation and is not yet considered a generally established term or standard. Its boundary with Composite/Federated Digital Twin and Digital Twin System-of-Systems may overlap in some implementations; therefore, the distinction presented here is based on the criteria proposed in this article, including a shared state, operational coupling, temporal coordination, trans-domain decision-making, and traceable feedback [5, 6, 12, 17, 21, 22]. Mapping the requirements to the architectural layers demonstrates conceptual consistency, but does not prove the causal validity, stability, or adequacy of the couplings. The direction and magnitude of effect and error transfer may depend on data, models, context, and delay and should be validated separately for each application [54, 66, 67, 68]. The applications presented in the article are illustrative examples and do not constitute empirical evidence for generalizing TDDT to all domains. Moreover, the article does not include a general benchmark, a complete implementation, or an end-to-end field comparison; therefore, no superiority in terms of accuracy, safety, cost, latency, or robustness can be concluded [3, 66, 67, 68, 72]. The capabilities of single-episode training, CRP, SARG, MRG, KStore, hidden loop current, and online adaptation are also proposed mechanisms, and their general effectiveness requires independent evaluation. To mitigate these threats, each twin and coupling should be validated separately, and the complete system should be evaluated using baselines, ablation, sensitivity analysis, stress testing, VVUQ, and field data. Simulation results should not be generalized to operational validity without independent evidence [66, 67, 68, 72].
14
Some Potential Application Domains of TDDT as a Conceptual Framework
The cases presented in this section are examples of complex systems in which multiple heterogeneous domains are operationally interdependent, and a change in one domain can alter the state, error, risk, constraint, objective, or decision 29
Trans-Domain Digital Twin: Conceptual Foundations, Architecture, and Research Outlook
of another domain. The purpose of this section is to demonstrate how TDDT can support trans-domain decision-making across different applications through a shared state, data/model/error/objective/control coupling, temporal loops, and online adaptation. 14.1
Biology–Climate–Energy-Aware Control in Cattle Fattening
In enclosed cattle-fattening barns, the indoor climate, animal growth, feed intake, metabolic heat production, thermal comfort, and energy consumption mutually affect one another; therefore, local climate control without considering the biological state of the animals can lead to inconsistent and costly decisions [69, 70, 71]. Within the TDDT framework, the climate, biology/growth, energy, and control twins are placed within a shared state so that indicators such as body weight, ADG, feed intake, heat production, and growth limitations are transformed into constraints or guidance for climate-related decisions. The fast loop evaluates ventilation, heating, inlet, and fan commands using MPC, while the slow loop feeds the cumulative effects of growth, energy, and health back into the decision objectives and constraints [69], and the Meso loop also relies on the mutual effects of gases produced inside the barn, air quality, ventilation, energy consumption, and the feed-intake behavior of the animals [71]. 14.2
Path Planning in Autonomous Vehicles
In autonomous vehicles, path planning must transform environmental perception, obstacles, road boundaries, vehicle dynamics, energy consumption, safety, and the prediction of traffic-agent behavior into an executable path [79, 80, 81]. This problem is inherently trans-domain. The selected path simultaneously affects control constraints, stability, braking, acceleration, comfort, collision risk, and interaction with vehicles or pedestrians. In TDDT, the perception/scene, map, vehicle-dynamics, agent-prediction, energy, and control twins are coupled within a shared state so that the path, control, and risk are evaluated simultaneously, and the final decision is selected based on multi-domain consequences rather than local optimization. 14.3
Cancer and Personalized Treatment
In personalized cancer treatment, tumor growth, the microenvironment, angiogenesis, treatment response, toxicity, drug resistance, medical imaging, and the patient’s condition are interdependent across multiple scales and heterogeneous domains; global cancer statistics also demonstrate the importance of this issue in terms of disease burden and the need for precise therapeutic decision-making [82]. Various models are applied across these domains to predict tumor growth and treatment response [83, 84, 85]. In TDDT, these domains are incorporated into a shared state so that objectives such as controlling tumor growth, reducing toxicity, selecting the treatment dose/schedule, and online refinement of the patient-specific model are evaluated in a coupled manner. 14.4
QEC Error Correction in Quantum Processing
In QEC, noise, decoherence, gate errors, readout errors, code selection, decoder, connectivity topology, pulse control, and hardware resources simultaneously affect the logical error rate and computational cost [86, 87, 88, 89, 90]. Models of open quantum systems, noisy channels, Lindblad/master equations, stabilizer/surface codes, and resource-estimation models each describe part of this system [86, 87, 88, 89, 90]. In TDDT, the noise, hardware, control, syndrome-readout, code, decoder, compilation/scheduling, and uncertainty domains are incorporated into a shared state so that reducing the logical error rate, reducing latency, selecting the code distance, and online adjustment of control parameters are pursued simultaneously. 14.5
Tritium Self-Sufficiency and Breeding Blanket in Nuclear Fusion
In fusion power plants, tritium self-sufficiency depends on simultaneous coupling among plasma, neutronics, blanket, heat transfer, materials, tritium chemistry, safety, the fuel cycle, and energy economics; therefore, changes in neutron flux, temperature, material degradation, or tritium recovery can alter operational constraints and design decisions [91, 92, 93]. In TDDT, the plasma, blanket, materials, thermal, fuel, safety, and economic twins are incorporated into a shared state so that indicators such as TBR, material degradation, thermal load, safety risk, and fuel-cycle cost are used in a coupled manner within the decision loop and online adaptation. 14.6
Optimization of Retropropulsion, Plume, and Reentry Aerodynamics
In reusable spacecraft, retropropulsion and atmospheric re-entry involve strong coupling among propulsion, plume, aerodynamics, aerothermodynamics, the return trajectory, GNC, mass/fuel, structure, and thermal health; existing 30
Trans-Domain Digital Twin: Conceptual Foundations, Architecture, and Research Outlook
models often depend on fluid-dynamics equations, turbulence models, compressible flow, and heat transfer, but computational cost and uncertainty in boundary conditions limit real-time decision-making [94, 95]. In TDDT, these domains are coupled within a shared state so that, in the fast loop, thrust, trajectory, and angle of attack are adjusted to reduce heat flux, fuel consumption, and landing dispersion, while in the slow loop, the cumulative effects of heating, structural loads, and reuse damage are fed back into the decision objectives and constraints [95, 96]. 14.7
Stability of the Microbial Community in Clean-Energy Bioreactors
The stability of microbial communities in clean-energy bioreactors depends on temperature, pH, organic loading, retention time, feed composition, VFA, free ammonia, mass transfer, and species competition, and small operational changes can reduce CH4 , H2 , or electrical current production [97, 98, 99]. Models such as ADM1/AM2, chemostat/Monod, DAE, Monod–Butler–Volmer, mass balance, biofilm, and polarization models are used to describe growth, inhibition, microbial competition, and the linkage of biokinetics with electrochemistry [98, 99, 100, 101, 102]. In TDDT, the microbial-community, feed, solution-chemistry, gas/electrochemistry, temperature/mass-transfer, energy, and control domains are coupled so that stability, the energy-production rate, reduced inhibition, and reduced failure risk are optimized simultaneously [103]. 14.8
Breeding–Induced Mutagenesis
In breeding based on induced mutagenesis, the dose and type of mutagen, genotype/population, phenotype, growth environment, breeding selection, and performance evaluation operate in a multistage and interdependent manner [104, 105, 106]. In TDDT, mutagenesis is incorporated into the shared state as a change in the genetic composition of the population, and its effects on traits such as yield, resistance, quality, adaptability, and stability are predicted alongside environmental conditions and the breeding objective [104, 105, 106]. This framework can support the selection of promising genotypes, the reduction of costly trials, and the targeted refinement of the selection pathway through genotype–phenotype–environment–decision coupling. 14.9
GNSS-Online-Independent Navigation in UAV Systems
In UAV navigation without online dependence on GNSS, position and trajectory estimation depends on the coupling of multiple domains, such as inertia, altitude, heading, wind, airspeed, energy, actuators, flight dynamics, map, obstacles, and safety constraints; an error in any domain can be transferred covertly to other domains and subsequently return to the trajectory estimate[107, 108, 109]. In TDDT, these domains are incorporated into a shared state and fast/meso/slow temporal loops so that the relative trajectory, collision risk, energy consumption, wind effects, maneuvering limitations, and map matching are evaluated in a coupled manner. Such high-risk and sensor-limited applications demonstrate that using multiple domains and independent estimation pathways can make the detection of hidden loop flow and the online correction of navigation errors more reliable.
15
Advantages, Challenges, and Limitations
15.1
Advantages: Integrated Decision-Making, Trans-Domain Prediction, and Risk Reduction
In conventional digital twins, the primary objective is often monitoring, simulation, prediction, optimization, control, and decision support for a specific asset, process, or system [3, 110, 18, 111]. However, in TDDT, multiple domain twins, such as climate, biology, energy, economy, infrastructure, health, risk, or control, are placed within a progressive temporal coupling state, and the output of each domain can modify the constraint, input, error, or objective of another domain, thereby enabling integrated decisionmaking [73, 21]. In complex systems, an error, crisis, or environmental change usually begins in one domain, but its consequences can be transferred to other domains. In general, digital twins can reduce the cost and risk of direct testing on the real system by creating a virtual environment for simulation, monitoring, prediction, optimization, and control, while enabling scenario testing and the prediction of future behavior [110, 111]. TDDT extends this capability to the multi-domain level. Consequently, TDDT can be used for risk reduction, preventive decision-making, “what-if” scenario analysis, stress testing, and enhancing the resilience of complex systems [73, 21, 112, 113, 3, 110, 18, 111]. 15.2
Challenges of Data, Interoperability, and Standardization
The most difficult challenge in TDDT is the management of heterogeneous and multi-source data. Digital twins depend on sensor data, event data, models, simulations, historical data, operational data, and sometimes human data 31
Trans-Domain Digital Twin: Conceptual Foundations, Architecture, and Research Outlook
for their continuous updating. In TDDT architectures, these data enter the system from different domains and with different temporal rates, units of measurement, accuracy, quality, and semantics. Issues such as data integration, data quality, data discovery, data search, storage, processing, and interoperability remain among the main challenges in DT implementation [75]. In TDDT, this challenge becomes more severe, as each data item must be interpretable not only within its own domain but also within the shared trans-domain state. The second challenge is interoperability and standardization. “Data ownership,” “integration among virtual entities,” “levels of fidelity,” “technical implementation,” and “application throughout the lifecycle” are among the major gaps in the DT literature [3]. Domain twins may be developed using different modeling languages, temporal scales, data structures, APIs, ontology, and levels of fidelity. Therefore, TDDT requires adherence to common standards for data definition, identification, semantics, timing, uncertainty, model exchange, V&V, and lifecycle management [3, 75, 66, 73, 74, 76]. Without such standards, TDDT becomes a collection of separate twins that are connected only superficially but cannot operationally produce a valid and verifiable joint decision [66, 73]. 15.3
Challenges of Modeling, Validation, and Uncertainty
Each domain twin must be based on a physical, mechanistic, data-driven, statistical, agent-based, machine-learning, or hybrid model. In TDDT, the issue is not merely the validation of a single model; rather, the validity of the coupled models, the direction of influence among domains, error propagation, and output consistency must also be examined. The DT literature indicates that the levels of fidelity, credibility, validation, and verification are key issues in digital twins [3, 66]. Moreover, in safety-critical twins, particularly in precision medicine, VVUQ, namely verification, validation, and uncertainty quantification, is fundamentally important for establishing trust in predictions and decisions [66, 67]. Uncertainty in TDDT is multilayered. Part of the uncertainty arises from sensors, incomplete data, delay, noise, and data quality; part originates from model parameters, physical approximations, model structure, training data, and simulation error; and another part emerges from coupling among domains and human decision-making. Therefore, in addition to predicting output values, TDDT must also report the confidence level, uncertainty interval, decision sensitivity, and probability of error propagation among domains. If these uncertainties are not made transparent, TDDT may produce a decision that appears precise but is not scientifically or operationally reliable [66, 67, 68, 72]. 15.4
Ethical, Security, Data-Ownership, and Trustworthiness Challenges
The fifth challenge of TDDT is trustworthiness, security, privacy, and data ownership. Digital twins typically depend on continuous, sensitive, operational, and sometimes personal or confidential data. In TDDT, this issue becomes more complex because data are exchanged among multiple domains, multiple stakeholders, and multiple systems. Jones et al. identify data ownership as one of the key gaps in the realization of DTs [3]. Security and privacy studies also indicate that DTs face challenges such as confidentiality, integrity, authentication in IoT/IIoT communications, cyberattacks, access control, data leakage, communication security, and trust in the model [77, 78]. From an ethical perspective, TDDT can generate decisions that affect humans, the environment, the economy, health, or infrastructure; therefore, transparency, explainability, accountability, auditability, human control, and decision fairness must be incorporated into it. In the healthcare domain, ethical studies of DTs indicate that the lack of empirical validation, ambiguity regarding the actual value of DTs, bias, privacy, data ownership, and governance challenges can widen the gap between technological promises and real-world implementation [114, 115]. This warning is also valid for TDDT because a trans-domain decision may create unintended effects in other domains. Therefore, TDDT must be designed, validated, and monitored not only from technical perspectives but also from ethical, security, legal, and social perspectives [78, 114, 115].
16
Future Research Agenda for TDDT
The following agenda comprises a set of proposed directions inferred from the gaps and limitations of this article and does not represent an established scientific consensus. The priority of each direction depends on the application, risk, data, computational resources, and maturity of the domain twins [3, 12, 17, 18, 22]. First, the definition, classification boundary, and compliance conditions of TDDT should be examined in independent studies, and the stability of couplings, temporal loops, and error transfer should be tested [5, 6, 12, 17, 21, 22]. At the same time, a reference architecture, vocabulary, API, provenance mechanisms, and coupling contracts should be developed, and conceptual mappings to standards should be transformed into conformance tests [17, 26, 27, 73, 75, 74, 76]. 32
Trans-Domain Digital Twin: Conceptual Foundations, Architecture, and Research Outlook
Second, open and multi-domain benchmarks should be established to evaluate model validity, the shared state, coupling, decision-making, and end-to-end performance. This evaluation should include baselines, ablation, stress testing, and VVUQ [54, 66, 67, 68, 72]. The effectiveness of single-episode training, CRP, SARG, MRG, KStore, hidden loop current, and online adaptation should also be examined independently; at present, their benefits remain research hypotheses [11, 24, 54, 68]. Third, real-time execution should be investigated through approaches such as FFD, ROM, and lightweight surrogates, without disregarding reductions in accuracy and changes in uncertainty [56–60]. Safety, fallback, human override, security, data ownership, explainability, and decision accountability should also be incorporated from the beginning of the design process [66, 77, 78, 114, 115]. Finally, the practical validation of TDDT should proceed progressively from simulation to laboratory environments and then to field pilots; the results of each stage are generalizable only within the conditions under which they were tested [3, 66, 67].
17
Conclusion and Answers to the Research Questions
Q1. This article demonstrated that TDDT extends beyond single-domain, multi-domain, and Cross-Domain DTs because, rather than relying on comparison or reuse across domains, it is based on operational coupling and mutual influence among domains. Q2. We explained that, within the classification of digital twins, TDDT is not an independent functional level but rather an architectural subtype of a Composite/Federated Digital Twin System-of-Systems for complex and multiscale systems. Q3. The conceptual architecture of TDDT should connect data, model, state, error, objective, decision, and control through a shared trans-domain state and a coupling layer among heterogeneous domain twins. Q4. We explained that TDDT, through fast, meso-scale, and slow loops, together with offline learning, online tuning, and feedback from the real environment, can dynamically and adaptively support trans-domain decision-making. In conclusion, TDDT is an architectural response to the limitations of individual, multi-domain, and CDDT in complex systems. By establishing a trans-domain fused model, a shared state, operational coupling, and the TDOC orchestration core, this approach transfers decision-making from the level of separate domains to the level of the entire system. Single-episode offline training, together with CRP, SARG, MRG, and high-importance datasets, provides the prior knowledge required to reduce the risk and cost of online learning; meanwhile, the offline error function, uncertainty estimation, feedback from the real environment, and the detection of hidden error flows provide the basis for online adaptation. The main functions of TDDT are prediction, scenario generation, risk reduction, decision refinement, and trans-domain control based on real-world feedback. However, its practical realization depends on the standardization of terminology and interfaces, field validation, uncertainty management, data security, computational-cost control, and the development of lightweight and reliable models.
References [1] Edward H. Glaessgen and D. S. Stargel. The digital twin paradigm for future nasa and u.s. air force vehicles. In 53rd AIAA/ASME/ASCE/AHS/ASC Structures, Structural Dynamics and Materials Conference, Honolulu, HI, USA, 2012. AIAA. AIAA Paper 2012-1818, Special Session on the Digital Twin. [2] Werner Kritzinger, Matthias Karner, Georg Traar, Jan Henjes, and Wilfried Sihn. Digital twin in manufacturing: A categorical literature review and classification. IFAC-PapersOnLine, 51(11):1016–1022, 2018. [3] David Jones, Chris Snider, Aydin Nassehi, Jason Yon, and Ben Hicks. Characterising the digital twin: A systematic literature review. CIRP Journal of Manufacturing Science and Technology, 29(Part A):36–52, 2020. [4] Adam Thelen, Xiaoge Zhang, Olga Fink, Yan Lu, Sayan Ghosh, Byeng D. Youn, Michael D. Todd, Sankaran Mahadevan, Chao Hu, and Zhen Hu. A comprehensive review of digital twin—part 1: Modeling and twinning enabling technologies. Structural and Multidisciplinary Optimization, 65(12):354, 2022. [5] Wolfgang Heindl and Christian Stary. Structured development of digital twins—a cross-domain analysis towards a unified approach. Processes, 10(8):1490, 2022. [6] Manuela Dalibor, Nico Jansen, Bernhard Rumpe, David Schmalzing, Louis Wachtmeister, Manuel Wimmer, and Andreas Wortmann. A cross-domain systematic mapping study on software engineering for digital twins. Journal of Systems and Software, 193:111361, 2022. [7] Cor Verdouw, Bedir Tekinerdogan, Adrie Beulens, and Sjaak Wolfert. Digital twins in smart farming. Agricultural Systems, 189:103046, 2021. 33
Trans-Domain Digital Twin: Conceptual Foundations, Architecture, and Research Outlook
[8] Christos Pylianidis, Sjoukje Osinga, and Ioannis N. Athanasiadis. Introducing digital twins to agriculture. Computers and Electronics in Agriculture, 184:105942, 2021. [9] Marc Escribà-Gelonch, Shu Liang, Pieter van Schalkwyk, Ian Fisk, Nguyen Van Duc Long, and Volker Hessel. Digital twins in agriculture: Orchestration and applications. Journal of Agricultural and Food Chemistry, 72(19):10737–10752, 2024. [10] Anton van Beek, Vispi Karkaria, and Wei Chen. Digital twins for the designs of systems: A perspective. Structural and Multidisciplinary Optimization, 66(3):49, 2023. [11] Tim Bolender, Gereon Bürvenich, Manuela Dalibor, Bernhard Rumpe, and Andreas Wortmann. Self-adaptive manufacturing with digital twins. arXiv preprint arXiv:2103.11941, 2021. [12] Judith Michael, Jérôme Pfeiffer, Bernhard Rumpe, and Andreas Wortmann. Integration challenges for digital twin systems-of-systems. In Proceedings of the 10th IEEE/ACM International Workshop on Software Engineering for Systems-of-Systems and Software Ecosystems, SESoS’22, pages 9–12, Pittsburgh, PA, USA, 2022. Association for Computing Machinery. [13] Honghai Wu, Pengwei Ji, Huahong Ma, and Ling Xing. A comprehensive review of digital twin from the perspective of total process: Data, models, networks and applications. Sensors, 23(19):8306, 2023. [14] Silvia Mazzetto. A review of urban digital twins integration, challenges, and future directions in smart city development. Sustainability, 16(19):8337, 2024. [15] Y. Jiang, M. Li, W. Wu, X. Wu, X. Zhang, X. Huang, R. Y. Zhong, and G. G. Q. Huang. Multi-domain ubiquitous digital twin model for information management of complex infrastructure systems. Advanced Engineering Informatics, 56:101951, 2023. [16] Gordon Blair. Digital twins of the natural environment. Patterns, 2(10):100359, 2021. [17] Istvan David, Guodong Shao, Claudio Gomes, Dawn Tilbury, and Bassam Zarkout. Interoperability of digital twins: Challenges, success factors, and future research directions. In Tiziana Margaria and Bernhard Steffen, editors, Leveraging Applications of Formal Methods, Verification and Validation. Specification and Verification, volume 15223 of Lecture Notes in Computer Science, pages 27–46. Springer, Cham, Switzerland, 2025. [18] Aidan Fuller, Zhong Fan, Charles Day, and Chris Barlow. Digital twin: Enabling technologies, challenges and open research. IEEE Access, 8:108952–108971, 2020. [19] Alex Gonzalez-Caceres, Franziska Hunger, Jens Forssén, Sanjay Somanath, Andreas Mark, Vasilis Naserentin, Joakim Bohlin, Anders Logg, Beata Wästberg, Dominika Komisarczyk, Fredrik Edelvik, and Alexander Hollberg. Towards digital twinning for multi-domain simulation workflows in urban design: A case study in gothenburg. Journal of Building Performance Simulation, 18(3):311–332, 2025. [20] Mansoorali Amiri. Vers des jumeaux numériques intelligents en agriculture en environnement contrôlé : contributions conjointes en détection de fruits par vision et en simulation trans-domaines. Mémoire de maîtrise, Université de Montréal, Montréal, Canada, 2025. [21] C. R. Vergara, Georgios Theodoropoulos, Rami Bahsoon, Wilmer Yanez, and Nikos Tziritas. Federated digital twins as an enabling technology for collaborative decision-making. In Proceedings of the 38th ACM SIGSIM Conference on Principles of Advanced Discrete Simulation, SIGSIM-PADS ’24, pages 67–68, Atlanta, GA, USA, 2024. Association for Computing Machinery. [22] Mennatullah T. Khedr and John S. Fitzgerald. The composition of digital twins for systems-of-systems: A systematic literature review. arXiv preprint arXiv:2506.20435, 2025. [23] Hassan Maatouk and Xavier Bay. Gaussian process emulators for computer experiments with inequality constraints. Mathematical Geosciences, 49(5):557–582, 2017. [24] Marc C. Kennedy and Anthony O’Hagan. Bayesian calibration of computer models. Journal of the Royal Statistical Society: Series B (Statistical Methodology), 63(3):425–464, 2001. [25] Shiyu Yang, Man Pun Wan, Wanyu Chen, Bing Feng Ng, and Deqing Zhai. An adaptive robust model predictive control for indoor climate optimization and uncertainties handling in buildings. Building and Environment, 163:106326, 2019. [26] Modelica Association Project FMI. Functional Mock-up Interface Specification, Version 3.0.2. Modelica Association Project FMI, 2024. [27] IEEE. IEEE 1516-2025: IEEE Standard for Modeling and Simulation (M&S) High Level Architecture (HLA)— Framework and Rules. Institute of Electrical and Electronics Engineers, 2025. [28] Ibrahim Yahaya Wuni, Michael Grieves, Muhammad Junaid Yamin, and Saidu Abdulai Koroma. Conceptualising the digital twin: An analysis of 358 definitions. Digital Twin, 3(1):2600763, 2026. 34
Trans-Domain Digital Twin: Conceptual Foundations, Architecture, and Research Outlook
[29] Igiri Onaji, Divya Tiwari, Payam Soulatiantork, Boyang Song, and Ashutosh Tiwari. Digital twin in manufacturing: Conceptual framework and case studies. International Journal of Computer Integrated Manufacturing, 35(8):831–858, 2022. [30] Fei Tao, Jiangfeng Cheng, Qinglin Qi, Meng Zhang, He Zhang, and Fangyuan Sui. Digital twin-driven product design, manufacturing and service with big data. The International Journal of Advanced Manufacturing Technology, 94:3563–3576, 2018. [31] Jakob Trauer, Sebastian Schweigert-Recksiek, Christian Engel, Karoline Spreitzer, and Markus Zimmermann. What is a digital twin?—definitions and insights from an industrial case study in technical product development. In Proceedings of the Design Society: DESIGN Conference, volume 1, pages 757–766, 2020. [32] Adil Rasheed, Omer San, and Trond Kvamsdal. Digital twin: Values, challenges and enablers. arXiv preprint arXiv:1910.01719, 2019. [33] Adil Rasheed, Omer San, and Trond Kvamsdal. Digital twin: Values, challenges and enablers from a modeling perspective. IEEE Access, 8:21980–22012, 2020. [34] V. Blanes-Vidal, E. Guijarro, S. Balasch, and A. G. Torres. Application of computational fluid dynamics to the prediction of airflow in a mechanically ventilated commercial poultry building. Biosystems Engineering, 100(1):105–116, 2008. [35] Wangda Zuo and Qingyan Chen. Fast and informative flow simulations in a building by using fast fluid dynamics model on graphics processing unit. Building and Environment, 45(3):747–757, 2010. [36] Dietmar W. Hutmacher and Harmeet Singh. Computational fluid dynamics for improved bioreactor design and 3d culture. Trends in Biotechnology, 26(4):166–172, 2008. [37] Jeffrey P. Slotnick, Abdollah Khodadoust, Juan J. Alonso, David L. Darmofal, William D. Gropp, Elizabeth A. Lurie, and Dimitri J. Mavriplis. A perspective on the state of aerospace computational fluid dynamics technology. Annual Review of Fluid Mechanics, 55:431–457, 2023. [38] Natalya F. Noy and Deborah L. McGuinness. Ontology development 101: A guide to creating your first ontology. Technical Report KSL-01-05, Stanford Knowledge Systems Laboratory, Stanford, CA, USA, 2001. [39] Michael Grüninger and Mark S. Fox. Methodology for the design and evaluation of ontologies. In Proceedings of the IJCAI-95 Workshop on Basic Ontological Issues in Knowledge Sharing, Montreal, QC, Canada, 1995. [40] Mariano Fernández-López, Asunción Gómez-Pérez, and Natalia Juristo. Methontology: From ontological art towards ontological engineering. In Proceedings of the AAAI Spring Symposium on Ontological Engineering, AAAI Spring Symposium Series, Stanford, CA, USA, 1997. [41] Mike Uschold and Martin King. Towards a methodology for building ontologies. In Proceedings of the IJCAI-95 Workshop on Basic Ontological Issues in Knowledge Sharing, Montreal, QC, Canada, 1995. [42] Jérôme Euzenat and Pavel Shvaiko. Ontology Matching. Springer, Berlin, Heidelberg, 2 edition, 2013. [43] Nicolas Matentzoglu, James P. Balhoff, Susan M. Bello, Chris Bizon, Matthew Brush, Tiffany J. Callahan, Christopher G. Chute, William D. Duncan, Chris T. Evelo, Davera Gabriel, John Graybeal, Alasdair Gray, Benjamin M. Gyori, Melissa Haendel, Henriette Harmse, Nomi L. Harris, Ian Harrow, Harshad Hegde, Amelia L. Hoyt, et al. A simple standard for sharing ontological mappings (SSSOM). Database, 2022:baac035, 2022. [44] Antreas Kantaros, Theodore Ganetsos, Evangelos Pallis, and Michail Papoutsidakis. From mathematical modeling and simulation to digital twins: Bridging theory and digital realities in industry and emerging technologies. Applied Sciences, 15(16):9213, 2025. [45] Maziar Raissi, Paris Perdikaris, and George Em Karniadakis. Physics-informed neural networks: A deep learning framework for solving forward and inverse problems involving nonlinear partial differential equations. Journal of Computational Physics, 378:686–707, 2019. [46] Kyriaki Orphanou, Andri Stassopoulou, and Elpida Keravnou. DBN-Extended: A dynamic bayesian network model extended with temporal abstractions for coronary heart disease prognosis. IEEE Journal of Biomedical and Health Informatics, 20(3):944–952, 2016. [47] Terence J. O’Kane, Dylan Harries, and Mark A. Collier. Dynamic bayesian networks for evaluation of granger causal relationships in climate reanalyses. Journal of Advances in Modeling Earth Systems, 13(3):e2020MS002442, 2021. [48] Ian Horrocks, Peter F. Patel-Schneider, Harold Boley, Said Tabet, Benjamin Grosof, and Mike Dean. SWRL: A semantic web rule language combining OWL and RuleML. W3C Member Submission, may 2004. [49] Eric Bonabeau. Agent-based modeling: Methods and techniques for simulating human systems. Proceedings of the National Academy of Sciences, 99(suppl_3):7280–7287, 2002. 35
Trans-Domain Digital Twin: Conceptual Foundations, Architecture, and Research Outlook
[50] S. Suetsugu, F. Hori, M. Shibata, S. Kitagawa, K. Ishida, T. Asaba, S. Nakazawa, Q. Li, H.-H. Wen, T. Shibauchi, H. Kontani, and Y. Matsuda. Microscopic signatures of an imaginary charge density wave in a kagome metal. Nature Physics, 2026. [51] David E. Goldberg. Genetic Algorithms in Search, Optimization, and Machine Learning. Addison-Wesley, Reading, MA, USA, 1989. [52] Eduardo F. Camacho and Carlos Bordons. Model Predictive Control. Advanced Textbooks in Control and Signal Processing. Springer London, London, UK, 2 edition, 2007. [53] Hakjong Shin, Sang-yeon Lee, Jun-gyu Kim, Dae-Heon Park, Seng-Kyoun Jo, and Younghoon Kwak. Applicability evaluation of a temperature humidity index-controlled ventilation system in livestock using a building energy simulation model. Case Studies in Thermal Engineering, 57:104335, 2024. [54] Adam Thelen, Xiaoge Zhang, Olga Fink, Yan Lu, Sayan Ghosh, Byeng D. Youn, Michael D. Todd, Sankaran Mahadevan, Chao Hu, and Zhen Hu. A comprehensive review of digital twin—part 2: Roles of uncertainty quantification and optimization, a battery digital twin, and perspectives. Structural and Multidisciplinary Optimization, 65(11):305, 2022. [55] Hossein Mohammadi, Peter Challenor, and Marc Goodfellow. Emulating complex dynamical simulators with random fourier features. SIAM/ASA Journal on Uncertainty Quantification, 12(3):788–811, 2024. [56] Michalis K. Titsias. Variational learning of inducing variables in sparse gaussian processes. In Proceedings of the 12th International Conference on Artificial Intelligence and Statistics, volume 5 of Proceedings of Machine Learning Research, pages 567–574. PMLR, 2009. [57] Dionysis Manousakas, Zuheng Xu, Cecilia Mascolo, and Trevor Campbell. Bayesian pseudocoresets. In Advances in Neural Information Processing Systems, volume 33, pages 14950–14960, 2020. [58] Dominik Polke, Elmar Ahle, and Dirk Söffker. Adaptive learning with gaussian process regression: A comprehensive review of methods and applications. Machine Learning and Knowledge Extraction, 8(4):101, 2026. [59] Elizaveta Semenova. Case for a unified surrogate modelling framework in the age of ai. arXiv preprint arXiv:2502.06753, 2025. [60] Wolfgang Birk, Roland Hostettler, Maryam Razi, Khalid Atta, and Rasmus Tammia. Automatic generation and updating of process industrial digital twins for estimation and control—a review. Frontiers in Control Engineering, 3:954858, 2022. [61] Ankur Mour, C. Robert Kenley, Navindran Davendralingam, and Daniel DeLaurentis. Agent-based modeling for systems of systems. In Proceedings of the 23rd Annual INCOSE International Symposium. International Council on Systems Engineering, 2013. [62] Mark W. Maier. Architecting principles for systems-of-systems. Systems Engineering, 1(4):267–284, 1998. [63] Daniel DeLaurentis. Understanding transportation as a system-of-systems design problem. In 43rd AIAA Aerospace Sciences Meeting and Exhibit, page 123, 2005. [64] Enxhi Ferko, Alessio Bucaioni, and Moris Behnam. Architecting digital twins. IEEE Access, 10:50335–50350, 2022. [65] Paul T. de Vrieze, Rushan Arshad, and Lai Xu. Federated composite manufacturing process simulation using digital twins. International Journal of Simulation and Process Modelling, 21(3):179–191, 2024. [66] Guodong Shao, Moneer Helu, Yan Lu, and Thomas White. Credibility consideration for digital twins in manufacturing. Manufacturing Letters, 35:873–877, 2023. [67] Kaan Sel, Andrea Hawkins-Daarud, Anirban Chaudhuri, Deen Osman, Ahmad Bahai, David Paydarfar, Karen Willcox, Caroline Chung, and Roozbeh Jafari. Survey and perspective on verification, validation, and uncertainty quantification of digital twins for precision medicine. npj Digital Medicine, 8(1):156, 2025. [68] Julien Deantoni et al. Quantifying and combining uncertainty for improving the behavior of digital twin systems. arXiv preprint arXiv:2402.10535, 2024. [69] Saeed Taheri, Pouyan Hosseini, and Aida Razban. Model predictive control of heating, ventilation, and air conditioning systems: A state-of-the-art review. Journal of Building Engineering, 60:105067, 2022. [70] A. van der Linden, E. M. de Olde, P. F. Mostert, I. J. M. de Boer, and M. K. van Ittersum. LiGAPS-Beef, a mechanistic model to explore potential and feed-limited beef production 2: Model evaluation and sensitivity analysis. Animal, 13(4):845–855, 2019. [71] R. K. Tabase, G. Naess, and Y. Larring. Ammonia and methane emissions from small herd cattle buildings in a cold climate. Science of the Total Environment, 903:166046, 2023. 36
Trans-Domain Digital Twin: Conceptual Foundations, Architecture, and Research Outlook
[72] National Institute of Standards and Technology. Digital twins for advanced manufacturing. NIST Program/Project Web Page, 2024. [73] Anto Budiardjo and Doug Migliori. Digital twin system interoperability framework. Technical report, Digital Twin Consortium, 2021. [74] International Organization for Standardization. ISO 23247-2:2021: Automation Systems and Integration— Digital Twin Framework for Manufacturing—Part 2: Reference Architecture. International Organization for Standardization, 2021. [75] Jaqueline B. Correia, Mara Abel, and Karin Becker. Data management in digital twins: A systematic literature review. Knowledge and Information Systems, 65(8):3165–3196, 2023. [76] Emine Karabulut et al. arXiv:2308.15168, 2023.
Ontologies in digital twins: A systematic literature review.
arXiv preprint
[77] Mohamad El-Hajj et al. Systematic literature review: Digital twins’ role in enhancing security for industry 4.0 systems. Security and Privacy, page e396, 2024. [78] Marija Kuštelega, Renata Mekovec, and Ahmed Shareef. Privacy and security challenges of the digital twin. Journal of Universal Computer Science, 2024. [79] Taokai Xia and Hui Chen. A survey of autonomous vehicle behaviors: Trajectory planning algorithms, sensed collision risks, and user expectations. Sensors, 24(15):4808, 2024. [80] Shuyou Yu, Michael Hirche, Yutao Huang, Hong Chen, and Frank Allgöwer. Model predictive control for autonomous ground vehicles: A review. Autonomous Intelligent Systems, 1(1):4, 2021. [81] Miao Xu, Zhi Liu, Bingyi Wang, and Shengyan Li. A survey of autonomous driving trajectory prediction: Methodologies, challenges, and future prospects. Machines, 13(9):818, 2025. [82] Freddie Bray, Mathieu Laversanne, Hyuna Sung, Jacques Ferlay, Rebecca L. Siegel, Isabelle Soerjomataram, and Ahmedin Jemal. Global cancer statistics 2022: GLOBOCAN estimates of incidence and mortality worldwide for 36 cancers in 185 countries. CA: A Cancer Journal for Clinicians, 74(3):229–263, 2024. [83] Russell C. Rockne, Andrea Hawkins-Daarud, Kristin R. Swanson, James P. Sluka, James A. Glazier, Paul Macklin, David A. Hormuth, Angela M. Jarrett, Ernesto A. B. F. Lima, J. Tinsley Oden, Thomas E. Yankeelov, et al. The 2019 mathematical oncology roadmap. Physical Biology, 16(4):041005, 2019. [84] Angela M. Jarrett, Ernesto A. B. F. Lima, David A. Hormuth, Michael T. McKenna, Xinzeng Feng, David A. Ekrut, Artur C. M. Resende, Amy Brock, and Thomas E. Yankeelov. Mathematical models of tumor cell proliferation: A review of the literature. Expert Review of Anticancer Therapy, 18(12):1271–1286, 2018. [85] David A. Hormuth, Angela M. Jarrett, Ernesto A. B. F. Lima, Michael T. McKenna, Xiaosong Fu, and Thomas E. Yankeelov. Forecasting tumor and vasculature response dynamics to radiation therapy via image based mathematical modeling. Radiation Oncology, 15:4, 2020. [86] Heinz-Peter Breuer, Elsi-Mari Laine, Jyrki Piilo, and Bassano Vacchini. Colloquium: Non-markovian dynamics in open quantum systems. Reviews of Modern Physics, 88(2):021002, 2016. [87] Frederik Nathan and Mark S. Rudner. Universal lindblad equation for open quantum systems. Physical Review B, 102(11):115109, 2020. [88] Austin G. Fowler, Matteo Mariantoni, John M. Martinis, and Andrew N. Cleland. Surface codes: Towards practical large-scale quantum computation. Physical Review A, 86(3):032324, 2012. [89] Rajeev Acharya et al. Quantum error correction below the surface code threshold. Nature, 638:920–926, 2025. [90] Daniel Litinski. A game of surface codes: Large-scale quantum computing with lattice surgery. Quantum, 3:128, 2019. [91] Mohamed Abdou, Neil B. Morley, Sergey Smolentsev, Alice Ying, Siegfried Malang, Arthur Rowcliffe, and Mike Ulrickson. Blanket/first wall challenges and required R&D on the pathway to DEMO. Fusion Engineering and Design, 100:2–43, 2015. [92] Chase N. Taylor, Thomas F. Fuerst, Robert J. Pawelko, and Masashi Shimada. The tritium extraction experiment (TEX): A forced convection fusion blanket PbLi loop. Fusion Engineering and Design, 192:113737, 2023. [93] Ryuta Kasada, Saerom Kwon, Satoshi Konishi, Yoshiteru Sakamoto, Toshihiko Yamanishi, and Kenji Tobita. A system dynamics model for stock and flow of tritium in fusion power plant. Fusion Engineering and Design, 98–99:1804–1807, 2015. 37
Trans-Domain Digital Twin: Conceptual Foundations, Architecture, and Research Outlook
[94] Tamas Bykerk, Sebastian Karl, Mariasole Laureti, Moritz Ertl, and Tobias Ecker. Retro-propulsion in rocket systems: Recent advancements and challenges for the prediction of aerodynamic characteristics and thermal loads. Progress in Aerospace Sciences, 151:101044, 2024. [95] Kai Dresia, Simon Jentzsch, Günther Waxenegger-Wilfing, Robson Hahn, Jan Deeken, Michael Oschwald, and Fabio Mota. Multidisciplinary design optimization of reusable launch vehicles for different propellants and objectives. Journal of Spacecraft and Rockets, 58(4):977–991, 2021. [96] Jacopo Guadagnini, Michèle Lavagna, and Paulo Rosa. Model predictive control for reusable space launcher guidance improvement. Acta Astronautica, 193:767–778, 2022. [97] Shiva Harirchi, Steven Wainaina, Taner Sar, Seyed Ali Nojoumi, Mohammad Parchami, Mehran Parchami, Sunita Varjani, Samir Kumar Khanal, Jonathan W. C. Wong, Mukesh Kumar Awasthi, and Mohammad J. Taherzadeh. Microbiological insights into anaerobic digestion for biogas, hydrogen or volatile fatty acids (VFAs): A review. Bioengineered, 13(3):6521–6557, 2022. [98] Damien J. Batstone, Jürg Keller, Irini Angelidaki, Sergey V. Kalyuzhnyi, Spyros G. Pavlostathis, Alberto Rozzi, Willy T. M. Sanders, Hans Siegrist, and Vasily A. Vavilin. The IWA anaerobic digestion model no. 1 (ADM1). Water Science and Technology, 45(10):65–73, 2002. [99] Olivier Bernard, Zahia Hadj-Sadok, Denis Dochain, Antoine Genovesi, and Jean-Philippe Steyer. Dynamical model development and parameter identification for an anaerobic wastewater treatment process. Biotechnology and Bioengineering, 75(4):424–438, 2001. [100] Harry J. Dudley, Zhiyong Jason Ren, and David M. Bortz. Competitive exclusion in a DAE model for microbial electrolysis cells. Mathematical Biosciences and Engineering, 17(6):6637–6656, 2020. [101] Rakesh Kumar, Lal Singh, and A. W. Zularisam. Microbial fuel cells: A comprehensive review for beginners. 3 Biotech, 12:9, 2022. [102] Zhen Li et al. Model development of bioelectrochemical systems: A review. Water Research, 229:119456, 2023. [103] Hubertus V. M. Hamelers, Annemiek Ter Heijne, Nicole Stein, René A. Rozendal, and Cees J. N. Buisman. Butler– volmer–monod model for describing bio-anode polarization curves. Bioresource Technology, 102(1):381–387, 2011. [104] Yusuff Oladosu, Mohd Yusop Rafii, Norhani Abdullah, Ghazali Hussin, Abdul Ramli, Harun A. Rahim, Golam Miah, and Magaji G. Usman. Principle and application of plant mutagenesis in crop improvement: A review. Biotechnology & Biotechnological Equipment, 30(1):1–16, 2016. [105] Inger B. Holme, Per L. Gregersen, and Henrik Brinch-Pedersen. Induced genetic variation in crop plants by random or targeted mutagenesis: Convergence and differences. Frontiers in Plant Science, 10:1468, 2019. [106] Lei Ma, Fang Kong, Kai Sun, Tian Wang, and Tian Guo. From classical radiation to modern radiation: Past, present, and future of radiation mutation breeding. Frontiers in Public Health, 9:768071, 2021. [107] Nasser Gyagenda, Jasper V. Hatilima, Hubert Roth, and Vadim Zhmud. A review of GNSS-independent UAV navigation techniques. Robotics and Autonomous Systems, 152:104069, 2022. [108] Daniel Duberg and Patric Jensfelt. UFOMap: An efficient probabilistic 3D mapping framework that embraces the unknown. IEEE Robotics and Automation Letters, 5(4):6411–6418, 2020. [109] Helen Oleynikova, Zachary Taylor, Marius Fehr, Juan Nieto, and Roland Siegwart. Voxblox: Incremental 3D euclidean signed distance fields for on-board MAV planning. In 2017 IEEE/RSJ International Conference on Intelligent Robots and Systems (IROS), pages 1366–1373. IEEE, 2017. [110] Jun-Feng Yao, Yong Yang, Xiao-Chang Wang, and Xiao-Ping Zhang. Systematic review of digital twin technology and applications. Visual Computing for Industry, Biomedicine, and Art, 6(1):10, 2023. [111] Diego M. Botín-Sanabria, Adriana-Simona Mihaita, Rodrigo E. Peimbert-García, Miguel A. Ramírez-Moreno, Ricardo A. Ramírez-Mendoza, and Jorge de J. Lozoya-Santos. Digital twin technology challenges and applications: A comprehensive review. Remote Sensing, 14(6):1335, 2022. [112] Dmitry Ivanov. Intelligent digital twin (iDT) for supply chain stress-testing, resilience and viability. International Journal of Production Economics, 263:108938, 2023. [113] Eva Brucherseifer, Heiko Winter, Andreas Mentges, Martina Mühlhäuser, and Marco Hellmann. Digital twin conceptual framework for improving critical infrastructure resilience. Automatisierungstechnik, 69(12):1062– 1080, 2021. [114] Christopher David Burr, Shuang Qian, Peter Winter, Tim Chico, Camila Rangel Smith, David Wagg, and Steven Alexander Niederer. Realising the digital twin: A thematic review and analysis of the ethical, legal, and social issues for digital twins in healthcare. AI & Society, 41(5):5243–5267, 2026. 38
Trans-Domain Digital Twin: Conceptual Foundations, Architecture, and Research Outlook
[115] Pei-Hua Huang, Ki-Hun Kim, and Maartje Schermer. Ethical issues of digital twins for personalized health care service: Preliminary mapping study. Journal of Medical Internet Research, 24(1):e33081, 2022.
39