arXiv:2609.17258v1 [cs.SE] 15 Sep 2026
An Exemplar of a Digital Twin in Mechanical Engineering: Understanding Model Hybridization Mahussi Datongnon
Hubert LeJeune
Yoann Jus
Centre Inria d’Université Côte d’Azur Sophia-Antipolis, France [email protected]
CETIM Nantes, France [email protected]
CETIM Nantes, France [email protected]
Benoit Combemale
Julien Deantoni
Université de Rennes/Inria/Irisa, team DiverSE Rennes, France [email protected]
Université Côte d’Azur/I3S/Inria, team Kairos Sophia-Antipolis, France [email protected]
Abstract Digital Twins (DTs) are widely adopted across a variety of application domains [13]. In industrial sectors, particularly in mechanical engineering, they accelerate product development, reduce risks, enable early issue prediction, and lower sustainment costs [9]. In practice, DTs increasingly integrate physics-based (deductive) and data-driven (inductive) models into hybrid models [18] combining the complementary strengths of both modeling paradigms. In this paper, we refer to this integration paradigm as hybridization. Despite this trend, the engineering of hybrid DTs [10] that is, remains insufficiently documented. Hybridization is often introduced in an ad hoc manner, and its implementation is only partially made explicit, which limits reproducibility and transferability. This paper reports on the development of an existing fluidic loop digital twin at Centre Technique des Industries Mécanique (CETIM). The DT is described using the characterization framework of [11], providing a structured view across its lifecycle dimensions. To make hybridization explicit, the case is further analyzed through a complementary characterization structured along two dimensions: motivation and realization. The resulting description provides a traceable account of hybridization decisions and supports the documentation and transfer of hybrid DT engineering practices.
are only partially documented. As a result, essential engineering rational and decisions such as model integration, validation, and interaction remain implicit, leading to limited transferability across projects and application domains. This paper addresses this gap through an industrial case study conducted at CETIM, focusing on the development of an existing fluidic loop DT. It presents a reusable engineering exemplar based on the development of the fluidic loop DT, a structured characterization of the DT using a systematic reporting framework [11] [11], and a complementary hybridization perspective organized along two dimensions (motivation and realization). In addition, it highlights transferable lessons learned, supported by supplementary material that can be retrieved in [5–7]. The remainder of the paper is organized as follows. Section II presents the existing fluidic loop case study. Section II.1 details the digital twin characterization following [11]. Section II.2 introduces the hybridization perspective followed by a discussion in Section III.
II
Fluidic loop case study
Keywords Digital Twin, Hybridization, Modeling, Physics-Based Modeling, Data-Driven Modeling
I
Introduction
A DT can be defined as a complex software system that intentionally represents an original system, capable of reflecting changes in that system, interacting with it, and providing operational value [17]. Digital Twins (DTs) have emerged as key components of industrial systems, enabling monitoring, simulation, analysis, and decision support. DT increasingly combine physics-based (deductive) models with data-driven (inductive) approaches, leading to hybrid systems that leverage complementary modeling capabilities. Despite this evolution, the engineering of hybrid DTs remains insufficiently formalized. In practice, hybridization is often introduced in an ad hoc manner, and both its motivation and implementation
Figure 1: Fluidic loop.
Mahussi Datongnon, Hubert LeJeune, Yoann Jus, Benoit Combemale, and Julien Deantoni
This section presents an industrial case study based on a fluidic loop and its associated DT. The physical system is illustrated in Figure 1. The DT is designed to provide monitoring and decisionsupport capabilities. The physical system consists of a closed hydraulic loop equipped with a centrifugal pump, a heat exchanger, and several control elements and actuators. Its function is to deliver the flow rate, pressure, and/or temperature requested by the operator.
II.1
DT characterization
The DT of the fluidic loop is characterized using a systematic reporting framework [11]. A complete description of the DT according to this framework is available in [8]. The content presented here provides a concise synthesis relevant to the present study. The framework proposed by [11] consolidates and harmonizes existing DT characterization approaches proposed by [3, 11, 16], resulting in a unified set of Merged Characteristics (MCi) [11]. These characteristics provide a systematic basis for describing both the architecture and the functionalities of the DT on four dimensions. II.1.1
Requirements, Conceptualization, and Design.
System under study and physical components. : The system under study is the fluidic loop itself (MC1), composed of physicals actuators (MC2) and sensing components (MC3). The actuators include the pump speed, the regulation valve and the cooling unit, while the sensing layer captures variables such as inlet/outlet pressures, pump speed, temperature and flow rate. Physical - virtual interactions. : Sensor data are collected and transmitted to the digital environment and stored in a database, forming the physical-to-virtual interface (MC4). Conversely, the virtual-to-physical interaction (MC5) enables the DT to influence the physical system through actuator commands, such as adjusting valve opening or managing cooling strategies. Digital Twin services. The DT provides several operational services (MC6), including cavitation detection, virtual sensing where flow rate is estimated in case of sensor failure, energy consumption analysis through the simulation of alternative cooling strategies, and divergence detection, which identifies discrepancies between the physical and virtual systems to trigger recalibration of DT models. II.1.2
simulate system variables (e.g., pressure, flow rate, temperature) based on component parameters and control inputs. • Data-driven models: Two inductive models complement the simulation. A parameter identifier model (decision tree), identifying which parameters of the physical model are responsible for observed discrepancies. A fault estimation model (LS-SVR), estimating the corrected values of these parameters. • Data structure: The DT relies on a database that stores sensor measurements and simulation data. The machine learning models are trained using synthetic datasets generated from controlled simulations of the 1D model. The datasets are obtained by sampling control vectors and model parameters and recording the corresponding simulated process variables.
Realization.
The realization of the DT for this fluidic loop relies on the integration of heterogeneous models, data pipelines, and computational enablers, orchestrated to support the different operational services. This section details the DT realization according to models and data, enabling technologies, system orchestration, lifecycle evolution, and fidelity considerations. Digital Twin Models and Data (MC10). : The DT is composed of both deductive (physics-based) and inductive (data-driven) models, forming a hybrid modeling architecture. • Physics-based models: A 1D thermo-hydraulic simulation model (Simcenter Flomaster) is used to represent the fluidic loop. These models
Tooling and Enablers (MC11). : The DT implementation includes a Beckhoff Programmable Logic Controller (PLC) for automation and control, along with an industrial PC for local computation. For interoperability and simulation, the system uses the FMPy library [2] to execute Functional Mock-up Unit (FMU) for managing simulation assets. The application layer consists of a web interface enabling visualization and user interaction. These enablers ensure data acquisition, model execution, orchestration, and interaction within the DT. Digital Twin Constellation (MC12). : The DT constellation follows a distributed, service-oriented architecture where sensors transmit measurements to a PLC (data acquisition and control). Data are then stored in a database and processed by DT services combining FMU-based simulations, data-driven models. Data-driven models complement the physics-based model by analyzing discrepancies and dynamically adjusting parameters at runtime. Twinning Process and Digital Twin Evolution (MC13). : The DT follows a progressive evolution: starting from a calibrated thermohydraulic 1D model, it is connected to the physical system for synchronization, then extended with core services (simulation, visualization, diagnostics). Hybridization is introduced through datadriven models enabling divergence detection and parameter correction, leading to a closed-loop adaptation where model parameters are updated. Fidelity and Validity Considerations (MC14). : The DT reproduces the behavior of the fluidic system with a fidelity that depends on both the physical model and hybridization mechanisms. The thermo-hydraulic 1D model captures the global system dynamics (pressure, flow rate, temperature) with satisfactory accuracy under nominal conditions and is initially calibrated using experimental data. Fidelity is maintained over time through dynamic adaptation, combining divergence detection between simulation and measurements with data-driven models to adjust selected parameter. II.1.3
Deployment.
Digital Twin Technical Connection (MC15). : The communication architecture relies on industrial protocols. Sensors and actuators interact with a Beckhoff PLC industrial I/O and internal buses. OPC UA is used for standardized data exchange.
An Exemplar of a Digital Twin in Mechanical Engineering: Understanding Model Hybridization
Digital Twin Hosting and Deployment (MC16). : The DT is deployed on a local industrial infrastructure combining computation, control, and visualization components. At the edge level, an industrial PC hosts DT components for low-latency processing. The data layer ensures storage of historical data and datasets locally. The application layer provides a web-based interface for supervision, visualization, and interaction with the DT. II.1.4 Operation. The operation phase of the DT focuses on value delivery through interaction with the physical system, combining data processing, service execution, and decision support. Insights and Decision-Making (MC17). : The DT provides operational insights through several functionalities: visualization of system variables (pressure, flow rate, temperature) with comparison between measured and simulated values; detection mechanisms including cavitation alerts and divergence identification; and diagnostic capabilities to identify parameters responsible for deviations using data-driven models. The DT enables predictive analysis through what-if scenario simulations and evaluates alternative operating strategies (e.g., cooling profiles). Performance optimization is achieved via energy consumption indicators and scenario comparisons to identify the most efficient configurations. Horizontal Integration (MC18). : The DT is integrated within both industrial and information systems. At the industrial level, it interfaces with the Beckhoff PLC for control and data acquisition, using standard protocols such as OPC UA. At the IT level, data are stored and managed locally, enabling reuse by other applications (e.g., analytics, reporting) within the industrial environment. Data Ownership and Privacy (MC19). CETIM owns both the physical test bench (located in Nantes, at CETIM premises) and the associated data. The conditions for data sharing and dissemination, as well as the definition of data formats, are currently under study. Standardization (MC20). : The DT relies on established standards to ensure interoperability and modularity. The Functional Mock-up Interface (FMI) standard [14] is used to execution the 1D model exported as a FMU (via FMPy library [2]). OPC-UA under IEC 62541 [1], enables standardized communication between the PLC and digital components, ensuring vendor independence. Toward Explicit Characterization of Hybridization in DTs. The characterization framework [11] provides a generic and structured description of DTs that is independent of a specific application domain. By organizing DTs along MCi, it offers a common basis to describe architectures, models, data flows, services, and system interactions. However, within this framework, the relationships between heterogeneous models, in particular between deductive (physics-based) and inductive (data-driven) components, remain largely implicit. As a result, their interactions, roles, and integration strategies are often engineered in an ad hoc manner, making hybridization decisions difficult to trace and limiting knowledge transfer across DT implementations. To address this limitation, the following section introduces a complementary characterization, currently under development, specifically dedicated for guiding and structuring the description of hybridization within the fluidic loop.
II.2
Hybridization perspective
To complement the DT characterization, the Hybridization Characteristics (HC) are defined in correspondence with the framework [11]. While this framework provides a structured description of a DT across its lifecycle dimensions —requirements, conceptualization and design, realization, deployment, and operation— it does not explicitly address the rationale and implementation of hybridization. Instead, the integration of deductive and inductive models is typically distributed across several DT characteristics and remains largely implicit. The HC are introduced to make these aspects explicit. They provide a dedicated perspective for describing hybridization, capturing both the reasons for introducing it and the way it is implemented within a DT. To this end, the HC are organized along two complementary dimensions: Motivation and Realization. The Motivation dimension focuses on the need for hybridization and is primarily related to the requirements, conceptualization, and design characteristics (MC1–MC6). The Realization dimension focuses on the implementation and operationalization of hybridization and is mainly associated with the realization and operation characteristics (MC10–MC14, MC7, and MC17). A more detailed presentation of the HC is available in [4] II.2.1 Motivation dimension. The motivation dimension captures the need for hybridization, independent of its implementation, by structuring the problem context, identifying the limitations of existing DT assets, and specifying the expected, new or reinforced, capabilities of the hybridized system. HC1 - Overview / Context. (Link to MC1, MC6) : The DT relies on a 1D thermo-hydraulic simulation model supporting services such as flow simulation, cavitation detection, and energy analysis. This model is the core deductive component of the DT. HC2 - Problem Statement. (Link to MC6, MC14) : The simulation model is calibrated once at creation, with fixed parameters during operation. As the physical system evolves (e.g., degradation, changing conditions), discrepancies emerge between simulated and measured behaviors, leading to reduced service reliability (MC6) and decreasing fidelity (MC14). This situation raises three coupled challenges: (i) parameter identification, i.e., determining which model parameters are responsible for observed discrepancies; (ii) parameter estimation, i.e., inferring updated values for these parameters under varying operating conditions; and (iii) parameter validation, i.e., detecting that any proposed update preserves consistency with the physical system and does not degrade DT fidelity. Overall, the problem is to maintain alignment between the DT and the physical system under evolving conditions without repeated manual recalibration. The hybridization witin this DT consists of three complementary hybridization, each addressing one of the challenges identified in HC2 (Problem Statement): parameter identification, parameter estimation, and parameter validation. These hybridization mechanisms are described in detail in [4–7]. For the sake of readability, the characterization presented below focuses on the first hybridization level, namely the parameter identification problem.
Mahussi Datongnon, Hubert LeJeune, Yoann Jus, Benoit Combemale, and Julien Deantoni
HC3 - Existing Twin Assets and Gaps. (Link to MC10, MC14) : The DT relies on a 1D physics-based simulation model initially calibrated against the real system at creation time, with static parameters during operation. From a parameter identifier perspective, no mechanism exists to dynamically identify which parameters are responsible for discrepancies observed during operation. Overall, the DT lacks integrated capabilities for consistent parameter identifier, estimation, and validation, limiting its adaptability and robustness under evolving conditions. HC4 - Intended Deliverable Capability (IDC). (Link to MC6, MC10, MC12) : For parameter identification: the IDC is to determine which parameter is responsible for a discrepancy observed between the physical system and its DT counterpart. HC6 - Conceptual Requirements. (Link to MC10, MC13, MC14) The model must identify the parameter responsible for a discrepancy within the limits of observability defined by the available measurements and operating conditions; identification shall ensure that parameter contributions are distinguishable, enabling attribution of discrepancies to a reduced set of candidate parameters. HC7 - Deliverable Qualities. (Link to MC11, MC12, MC17) Quality expectations are defined per function. For parameter identification and estimation, outputs must ensure low latency and stable estimates, remaining compatible with DT real-time services without disrupting simulations. II.2.2 Realization Dimension. The realization dimension describes how hybridization capabilities are implemented and executed within a DT. It captures both the design-time and runtime realization of hybridization deliverables, including their orchestration, architecture, and data flows, providing reusable implementation patterns for integrating deductive and inductive models.
III
Results & Discussion
The proposed Hybridization Characteristics (HC) provide a structured way to document both the motivation and realization of hybrid Digital Twins, making explicit design decisions that are often implicit in industrial developments. Applied to the fluidic loop case study, the framework enabled the systematic identification and description of each hybridization capability involved in the diagnostic workflow, including parameter identification, parameter estimation, and parameter validation [4–7]. This explicit representation improves traceability between engineering needs and their implementations while facilitating knowledge transfer across use cases. Beyond their descriptive role, the realization characteristics reveal recurring implementation patterns that can be generalized across hybrid Digital Twins. For instance, similarly to [19], both the parameter identifier and the parameter estimator follow the same orchestration pattern: a deductive model is first used to generate a dataset, from which an inductive model is subsequently trained. The recurrence of such workflows suggests that realization characteristics can evolve from documentation artifacts into reusable orchestration templates. This observation opens the perspective of standardizing the orchestration of deductive and inductive models. In the co-simulation domain, the Functional Mock-up Interface (FMI) [14] provides a tool-independent standard for exchanging simulation models, while System Structure and Parameterization (SSP) [15] defines how complete systems composed of one or more component models, including FMUs, and their parameterization can be represented and transferred between simulation tools. Building on this separation between model exchange and system-level composition, the realization dimension could similarly provide a standardized means of describing how deductive and inductive models are created, integrated, and interact across both development and runtime phases, thereby facilitating the reuse, interoperability, and engineering of hybrid Digital Twins.
Conclusion
(a) Creation
(b) Usage
Figure 2: Parameter identifier lifecycle Parameter Identification. Figure 2 illustrates the realization of the parameter identification capability. During the creation phase (Fig. 2a), a Decision Tree parameter identifier is trained from a dataset generated by the 1D simulation model. During operation (Fig. 2b), the trained model identifies the faulty parameter, while a complementary hybrid model estimates its value [18]. Following parameter validation, both parameter identifier and estimator models are updated to support subsequent diagnosis (Fig. 2b) iterations. Further implementation details are provided in [12].
This paper presented an engineering exemplar of a hybrid Digital Twin developed for a fluidic loop system at CETIM. By extending an existing Digital Twin characterization framework with Hybridization Characteristics HC, it provides a structured and traceable description of the motivations and realization of hybridization, explicitly linking engineering needs to implemented solutions. Beyond documentation, the case study revealed recurring realization patterns that suggest HC could evolve toward reusable orchestration patterns for deductive and inductive models. This perspective opens the way to more systematic engineering and future standardization of hybrid Digital Twins.
An Exemplar of a Digital Twin in Mechanical Engineering: Understanding Model Hybridization
References [1] 2025. OPC unified architecture - Part 19: Dictionary Reference. Technical Report IEC 62541-19:2025. International Electrotechnical Commission (IEC). https: //webstore.iec.ch/en/publication/81518 [2] CATIA-Systems. [n. d.]. FMPy: A free Python library to simulate Functional Mock-up Units (FMUs). https://github.com/CATIA-Systems/FMPy [3] Manuela Dalibor, Nico Jansen, Bernhard Rumpe, David Schmalzing, Louis Wachtmeister, Manuel Wimmer, and Andreas Wortmann. 2022. A Cross-Domain Systematic Mapping Study on Software Engineering for Digital Twins. Journal of Systems and Software 193 (2022), 111361. doi:10.1016/j.jss.2022.111361 [4] Mahussi Datongnon. 2026. Hybridization Characteristics - Motivation overview. doi:10.5281/zenodo.20757943 [5] Mahussi Datongnon. 2026. Hybridization Characteristics - Realization - cetim fluidic loop paramater estimator. doi:10.5281/zenodo.21835068 [6] Mahussi Datongnon. 2026. Hybridization Characteristics - Realization - cetim fluidic loop parameter identifier. doi:10.5281/zenodo.21835099 [7] Mahussi Datongnon. 2026. Hybridization Characteristics - Realization - cetim fluidic loop parameter validation. doi:10.5281/zenodo.21835055 [8] EDTLab. 2025. UC05 – Fluid Loop (CETIM). EDTLab. https://edtlab.fr/en/usecases/uc05-boucle-fluidique-cetim-r0-1 Use case demonstrating a fluid-loop digital twin developed with CETIM. [9] Alberto Ferrari and Karen Willcox. 2024. Digital Twins in Mechanical and Aerospace Engineering. 4, 3 (2024), 178–183. doi:10.1038/s43588-024-00613-8 [10] Alfredo Garro and Alessandro Sorrenti. 2026. Designing an ISO 23247-Compliant Hybrid Digital Twin Architecture for Industry. 193 (2026), 108039. doi:10.1016/j. infsof.2026.108039 [11] Santiago Gil, Bentley J Oakes, Cláudio Gomes, Mirgita Frasheri, and Peter G Larsen. 2025. Toward a Systematic Reporting Framework for Digital Twins: A
Cooperative Robotics Case Study. SIMULATION 101, 3 (March 2025), 313–339. doi:10.1177/00375497241261406 [12] Osimone Imhogiemhe, Yoann Jus, Hubert Lejeune, and Saïd Moussaoui. [n. d.]. THERMAL-HYDRAULIC PROCESS SUPERVISION AND MONITORING THROUGH A DATA-DRIVEN DIGITAL TWIN. ([n. d.]). [13] David Jones, Chris Snider, Aydin Nassehi, Jason Yon, and Ben Hicks. 2020. Characterising the Digital Twin: A Systematic Literature Review. 29 (2020), 36–52. doi:10.1016/j.cirpj.2020.02.002 [14] Modelica Association. 2024. Functional Mock-up Interface for Model Exchange and Co-Simulation. https://fmi-standard.org/ [15] Modelica Association. 2024. System Structure and Parameterization (SSP). https: //ssp-standard.org/ [16] Bentley Oakes, Ali Parsai, Simon Van Mierlo, Serge Demeyer, Joachim Denil, Paul De Meulenaere, and Hans Vangheluwe. 2021. Improving Digital Twin Experience Reports:. In Proceedings of the 9th International Conference on ModelDriven Engineering and Software Development (Online Streaming, — Select a Country —, 2021). SCITEPRESS - Science and Technology Publications, 179–190. doi:10.5220/0010236101790190 [17] Pascale Vicat-Blanc, Benoit Combemale, Guy de Spiegeleer, Arnaud Blouin, Thierry Duval, Hind Bril El Haouzi, Jean-Michel Bruel, Julien Deantoni, Jannik Laval, and Jean-Marc Jézéquel. 2026. La Fabrique des Jumeaux Numériques: verrous scientifiques, technologiques et perspectives du programme EDT. La Revue de l’électricité et de l’électronique 1, 1 (March 2026), 98. [18] Jinjiang Wang, Yilin Li, Robert X. Gao, and Fengli Zhang. 2022. Hybrid PhysicsBased and Data-Driven Models for Smart Manufacturing: Modelling, Simulation, and Explainability. 63 (2022), 381–391. doi:10.1016/j.jmsy.2022.04.004 [19] Ruiyang Zhang, Yang Liu, and Hao Sun. 2020. Physics-Guided Convolutional Neural Network (PhyCNN) for Data-Driven Seismic Response Modeling. 215 (2020), 110704. doi:10.1016/j.engstruct.2020.110704