# Leveraging model-based systems and software engineering for digital twin engineering: Methods and digital thread opportunities

Clarissa Gregory, Souad Rabah, Vincent Chapurlat, Fedor Burčiar, Monika Herchlová

<figure><img src="image_1.png" /></figure>

## ► To cite this version:

Clarissa Gregory, Souad Rabah, Vincent Chapurlat, Fedor Burčiar, Monika Herchlová. Leveraging model-based systems and software engineering for digital twin engineering: Methods and digital thread opportunities. Journal of Industrial Information Integration, 2026, 50, pp.101023. 10.1016/j.jii.2025.101023. hal-05407463

HAL Id: hal-05407463

https://imt-mines-ales.hal.science/hal-05407463v1

Submitted on 9 Dec 2025

HAL is a multi-disciplinary open access archive for the deposit and dissemination of scientific research documents, whether they are published or not. The documents may come from teaching and research institutions in France or abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est destinée au dépôt et à la diffusion de documents scientifiques de niveau recherche, publiés ou non, émanant des établissements d'enseignement et de recherche français ou étrangers, des laboratoires publics ou privés.

<figure><img src="image_2.png" /></figure>
Full Length Article

# Leveraging model-based systems and software engineering for digital twin engineering: Methods and digital thread opportunities

Clarissa Gregory<sup>a, *</sup>, Souad Rabah<sup>a, *</sup>, Vincent Chapurlat<sup>a</sup>, Fedor Burčiar<sup>b</sup>,
Monika Herchlova<sup>b, ●</sup>

ARTICLE INFO

Keywords:

Digital twin system

Systems engineering

Model-based systems and software engineering
(MBSSE)

Digital thread

Federated interoperability

A B S T R A C T

The Digital Twin (DT) is a reciprocally connected and synchronized representation of a physical asset so-called Physical Twin. DT is a central component of a Digital Twin System (DT System), that interconnects the DT and the Physical Twin, through different components, and executes the necessary functions such as exchanging, processing or storing data. The engineering of the DT System is a long and complex process which is poorly formalised by systematic methodological approaches despite the variety of techniques and technologies used by practitioners. Fittingly, Systems Engineering (SE) offers principles, processes, methodological tools and frameworks for the engineering and lifecycle management of complex systems. More precisely, Model-Based Systems and Software Engineering (MBSSE) places modelling activities at the centre of engineering practices to facilitate exchanges and iterations between stakeholders around the system of interest through its whole lifecycle. Stakeholders’ activities during system’s lifecycle produce digital items, perceived as Data, Information or Knowledge (DIK), which may be reused for DT System engineering. First, this paper discusses SE and MBSSE application for DT System engineering to identify the foundations of a DT System MBSSE. Second, a discussion about opportunities and research questions are presented to gather and manage items produced along lifecycle in a concept designated the Digital Thread. Indeed, Digital thread formalisation and exploitation lead various interests for DT System engineering.

# 1. Introduction

Industry 4.0 is characterised by the integration of digital and internet technologies with traditional industrial practices. In this context, digital tools and technologies are increasingly essential throughout the entire system lifecycle. They enable advanced digital modelling for both engineering and operations of systems, while harnessing data to support control and process optimisation. Among other, Digital Twin (DT) has become a key technology of Industry 4.0 [1,2]. It aims to connect, synchronize and leverage both data and models from a Physical Twin called hereafter target entity.

DTs have become unavoidable to support complex systems, as they can be used to meet some needs of control and supervision, parameterisation, testing and optimisation, or even as a support for operators' training. However, both Physical Twin and DTs are complex systems, gathering a wide variety of concerns in terms of performance, safety, environment or maintainability. Both require appropriate

methodologies for their engineering, operations, maintenance and dismantling remaining in phase with Industry 4.0 objectives.

Fittingly, System Engineering (SE) promotes methodologies, processes and systemic concepts to support and drive engineering projects of such systems to make the most fitted technical solution emerge. In addition, Model Based Systems and Software Engineering (MBSSE) promotes and argues the importance of modelling and the use of models instead of focusing only on a document-based engineering practice.

SE methodology has already been used in the engineering of DT [3, 4], demonstrating the feasibility and the relevance of such approach for DT engineering, but remains limited to specific use cases. The standard [5] introduces the concept of Digital Twin System (DT System).

The DT System encompasses the DT, which serves as the core digital representation of the target entity. The DT is designed to support various interactions with other components within the DT System. These components are responsible for managing Human Machine Interfaces, establishing and processing data connections, and enabling interactions

<footnote><sup>a</sup> Laboratoire des Sciences des Risques, IMT Mines Alès, France</footnote>

<footnote><sup>b</sup> Institute of Applied Informatics, Automation and Mechatronics, STU MTF Trnava, Slovakia</footnote>

<footnote>* Corresponding authors at: 6 avenue de Clavières, 30100 Alès France.</footnote>

<footnote>E-mail addresses: Clarissa.gregory@mines-ales.fr (C. Gregory), souad.rabah@mines-ales.fr (S. Rabah).</footnote>
with external systems in the environment. From a system perspective, the structure and functionalities defined for the DT System place it within the scope of SE [5]. This standard completes and extends the previous standard [6] which focuses specifically on the DT of manufacturing systems.

The purpose of this paper is threefold. First, it discusses the benefits of the application of SE and more precisely of MBSSE principles for DT System engineering. Second, these benefits are used to derive methodological guidelines in a tool agnostic manner. Third, the paper addresses the management of data related to the target entity to support the engineering and operations phases of the DT System. Indeed, throughout these phases, stakeholders generate a considerable volume of so-called *Items* [7], which must be systematically organised, stored, traced, and maintained in a consistent and trustworthy way in an authoritative repository. This structured entity approach to data management is formalised in scientific literature by the concept of *Digital Thread* (DTh) [8]. The final part of the paper explores the opportunities the DTh brings to DT System engineering and management, particularly in terms of reusing available data, as well as the barriers currently limiting the implementation of the DTh. Along the discussion, a use case will be presented as an illustration of the proposed methodology.

The structure of the paper will be the following. Section 2 introduces briefly the use case that will be used in the rest of the paper. Section 3 presents the state of the art of SE, MBSSE, DT System and the current standards and states of practice. It will then discuss the application of MBSSE to DT Systems Engineering and illustrate the proposition on the use case. The last part introduces the concept of Digital Thread (DTh), its relationships to the DT System engineering and operations and its current limitations, leading to new research questions to explore.

## 2. Use-Case

The proposed use-case focuses on an industrial packaging and processing line for food and beverage. This use-case, named Festo System, is provided by the Faculty of Material Science and Technology in Trnava (STU-MTF), from the Slovak University of Technology in Bratislava. This use case is based on the Agro, Food & Beverages Factory - Festo Didactic i.e. a production system for conditioning and packaging two different types of material in bottles currently installed in the Institute of Applied Informatics, Automation and Mechatronics (UIAM). This system is the target entity of the DT System to be engineered.

The Festo System (Fig. 1) has been extensively studied in [9], this research work focused on proactive simulation for manufacturing system control and Digital Twins.

The purpose of the Festo System is to recycle and recondition bottles filled with either liquid or granulate and to prepare orders according to customers' instructions. To achieve this goal, it realises several missions: processing of incoming used bottles by taking the content out of the bottles, sort them according to their type, prepare the content and bottles to be reused and finally prepare and package according to orders. The objectives that can be set for this system can be the percentage of preparation of correct orders considering [9] 1,5 % of incorrect orders. Objectives of such a system can be related to performances, such as the number of orders prepared in a given time or related to maintenance by a setting a mean time to failure and a mean time to repair. Ref [9] introduced the Festo DT. The analysis of this DT, along with the reverse engineering process that led to the development of the Festo DT System under the sense of MBSSE will serve to illustrate the methodological elements about DT Systems engineering presented in the following sections.

## 3. Digital twin system engineering: state of the art, practice and issues

### 3.1. State of the art of digital twin system engineering

#### 3.1.1. Systems engineering

SE provides a complete framework (principles, rules, and processes) for complex systems engineering. This allows various stakeholders working together towards the realization of technically successful solutions. Considering the complexity of the engineering context, an adapted methodology is required, supported by a “system-used-to-do” capable to handle both complex systems engineering and the multitude of associated requirements. Ref [11,12] promotes a prescriptive framework and emphasises the processes outlined in ISO/IEC/IEEE 1528:2023 [13] for structuring and guiding the design, development, maintenance and end-of-life of complex systems, from both technical and management points of view. MBSSE [14] inherits these principles and processes by promoting modelling and the use of models in each of these processes with recognized benefits [15]. The aim of modelling is to describe a system, phenomenon or element according to views (e.g. functional, behavioural, requirements or organic) by respecting the

<figure><img src="image_3.png" /><figcaption>Fig. 1. Festo system [10].</figcaption></figure>
conventions of a modelling language or Domain Specific Modelling Language [16,17] e.g. SysML [18]. However, a model responds to a modelling purpose and objectives specific to the stakeholder who build the model, e.g. analysing performance, formalising a set of requirements that must be SMART (Specific, Measurable, Achievable, Relevant, Time-Bound) or an operational scenario. Each model therefore expresses a point of view, a level of detail, and must serve the analysis [14] and reasoning, explaining or prescribing solutions, or argue a choice [19].

### 3.1.2. Digital twin system

The concept of DT was proposed by M. Grieves in 2004 and formalised later in the 2010's [20,21]. In this section, the terminology used by the original authors is retained, without enforcing the distinction between DT and DT System, as this differentiation is not consistently applied across all studies. In 2014 [20], presents the DT in three components: the entity of interest, its virtual representation and the data connection between the two entities. This first approach of the definition has been further developed by [4], the 5-D DT, by introducing the *service* and *data storage* elements as a part component of the DT. Since then, numerous DT architecture proposals have emerged as highlighted in [22]. For instance [23], considers the DT for industrial systems as a combination of a software and data processing systems. In their interview study, gathering insight from DT practitioners [24] underlines the variety of frameworks and solutions used by practitioners, being either bespoke or commercial solutions.

Systematic literature review studies have also shown the diversity of DT definitions available that appeared over the years. Ref [25] gathered and classified thirty definitions of DT. Ref [26] focused on the role of DT and the benefits it brings to industrial operations in cyber-physical systems. Ref [27] completes the previous literature review by differentiating DT from other related technologies and proposed a state of the art of the current practices and implementation highlighting the gaps and remaining challenges. Similarly to the previous work from Negri and Semeraro, they underline the variety of DT definitions.

Beyond the diversity of definitions, DTs are interesting thanks to their versatility, supporting a broad spectrum of applications and purposes. The French AIF (Alliance for Future Industry) identifies and classifies DT use cases relying on seven dimensions characterising the DT [28]. Among the applications of DT in literature, maintenance of systems in operational conditions ([29,30]; C [31,32]), assisting optimisation, command of systems [4,33] behavioural analysis [34] and fault diagnosis [35] are four examples of DT use case widely studied. Ref [27] notices that DT are useful for digital testing of a system, such as testing under extreme conditions that cannot be reproduced in a laboratory, real time monitoring of scenarios to identify emergent behaviours and optimisation of lifecycle with numerous parameters. Several DTs could be requested for a same system but for distinct purposes and objectives [36]. Ref [37] standard provides a template for DT use case and compiles a list of DT applications covering all phase of the target entity lifecycle. Furthermore, DT Systems also support the representation of processes [38] and service systems [39].

The relevance of DT for industrial practitioners is supported by the recent development of standards, proposing a consensus around the concept of DT. Ref [6] is a standard in four parts defining and proposing a framework for DT of manufacturing systems. It provides a definition of the concepts of DT, as well as the concept of Observable Manufacturing Elements (OME), physical assets modelled by the DT, which are at the core of the proposed framework. This standard also proposed requirements and a functional architecture for DT. Ref [5] standard introduces general concepts and terminology for DT. It distinguishes, on the contrary of most previous studies, between the DT which is a Digital Model, a representation of the target entity, and the DT System which is made up of the digital representation and all the components making up the DT System, including the interfaces with the target entity, the users and the interfaces with other information systems. This standard also introduces some definitions to system elements such as the DT System

lifecycle and the stakeholders involved. These definitions [5] will be adopted in the following. Thera are twofold:

The Digital Twin: "digital representation of a target entity with data connections that enable convergence between the physical and digital states at an appropriate rate of synchronization".

The Digital Twin system: "system providing functionalities for the DT composed of inter-operating target entities, digital entities, data connections, and models, data and interfaces involved in the data connection process" [5].

### 3.1.3. Current practices and benefits of systems engineering for digital twin systems

This section explores methodological approaches and technologies used for DT systems Engineering i.e. design, implementation and operational maintenance. First, it introduces two main aspects of DT System engineering conform to [5] then it presents methodologies and technologies based on a literature review.

The first aspect is the [5] digital representation called simply DT and defined by models. The second is the technical system that connects the DT with target entity by exchanging data. Ref [40] distinguish the physical object, the digital object and the connection in between. The Digital Object becomes a DT only when the connection with the physical object is reciprocal and automated. Therefore, two elements are to be engineered to produce a DT: the digital representation and the elements enabling the data connection that, implemented in the form of a system [5]. This definition does not propose technological solutions for DT implementation but highlight there are several dimensions to DT engineering, the model and the connection to the target entity. This is consistent with the definition of a DT System provided in standard [5]. In the remainder of this paper, the term DT System refers to any combination involving a physical or target entity, while DT refers exclusively to its digital representation.

This dual dimension of DT System is addressed in many studies that propose models and conceptual solutions as well as technical solutions for implementations to link the model and the target entity. Indeed, [23] considers both aspects for DT System design by proposing conceptual model, the software platform and the management of data storage and access. Ref [41] proposes a modelling method for DT of production units and how to integrate them in the DT of a production line, they particularly focus on the component of DT System of production line in terms of properties, states, simulation, logical and communication model. They also propose solution for real-time data base management and decision making.

Refs [24] and [38] also notices from that the integration of models made by different tools and the numerous integration technologies make it difficult to implement and deploy solutions for DT System. From a methodological point of view frameworks are leveraged or developed to accompany the engineering of technical solutions for DT System implementation. Model Driven Engineering (MDE) also provides solutions and methods for DT engineering especially to build models tailored to use, made based on a set of heterogeneous data and to manage and maintain a model that shall evolve along the target entity [36]. The Digital Twin Consortium (DTC) of the Object Management Group (OMG) also contributes to the dissemination of DT System engineering framework. Ref [42] surveyed the different tools and frameworks available supporting DT System engineering such RAMI 4.0, asset administration shells or solutions designed by software providing companies such as Microsoft or Amazon Web Service. Therefore, varied alternatives are explored for DT System engineering, leading researchers to build bespoke solutions for specific problems based on a variety of tools. They also provide tools for DT engineering, with for instance the Digital Twin Capability Periodic Table meant to guide stakeholders to define they expect from the DT System being designed [43] which is now equipped with AI agents (Himanshu [44]). Meanwhile they also propose
methods to manage the engineering project (the system-used-to-do) and the acculturation to digital technologies in the organisation with the DT System Business Maturity Model [45].

Ref [35] developed a DT System in two parts, one is a digital representation of the system, and the other is made of the data system and the algorithm, such as signal warping, used for real time analysis. Ref [33] aside from developing the software part of the DT System managing operation in engineering-to-order operations manufacturing, prescribed the necessary hardware materials to deploy the solutions on the shop-floor. Ref [30] develop an ontology-based decision framework for DT system engineering. Ref [46], in the DT System architecture they developed for space launch vehicle, consider the interface with physical entity by the inclusion of sensors, actuators and interfaces with other systems.

Technologies involved in DT System engineering are varied. Among the techniques in use, there are the finite elements method [47], augmented reality [48] simulation tools such as AnyLogic [24], WitnessHorizon [10] or Modelica [35]. In the case of civil engineering, there are investigation to base DT System engineering on Building Information Modeling (BIM) [49]. DT are also supported with techniques based on artificial intelligence (AI) technologies [50,51], for instance through surrogate models [32].

Beyond the different technologies used to build the DT System, the [5] standard highlights its systemic nature. A DT System is composed of five core components, each supported by specific technologies. However, its overall behaviour emerges from the interaction of its components and cannot be reduced to the sum of their individual functions. The complexity inherent to such systems requires specific engineering methods, which are discussed in the next section.

### 3.1.4. Systems engineering for digital twin system

DT Systems are complex systems and operate in complex environments, making their engineering long, expensive, and effort intensive. Since the [5] introduction of DT System concept by [5], SE, MBSE and more precisely MBSSE principles, tools and processes become applicable. As previously explained, these approaches guide systems engineering and therefore can be applied to DT System engineering. Indeed, the literature present various engineering solutions following MBSSE principles, while often referring to DT System simply as DT. As an example, [3] proposes a DT for condition-based maintenance leveraging MBSE processes. This study also highlights cases for DT usages, that support system operations but also guides the engineering of the target entity by introducing specific requirements, for instance related to the realisation of the interface between the target entity and the DT. Ref [52] developed a use case applying MBSE for shopfloor DT System engineering, going through all stages of SE methodology problem definitions, solutions definition until implementation, using the recognised Magic Grid methodology. (X [53]) relies on MBSE for the engineering of industrial robots' DT Systems, detailing a list of DT use cases: simulate design plan, monitor physical robot system behaviour and selection of operation tasks. His approach is specific to DT Systems for industrial robots, developing a tailored ontology to support the engineering. Ref [38] develops a DT System for vitrification of nuclear waste and [32] applied MBSE framework for the architecture of a DT for Remote Maintenance Robot System for nuclear power plants. The goal was to engineer the DT model, combined with a surrogate model, to model flexible elements that are computationally heavy to simulate. Applying SE and MBSE for DT System engineering is challenging due to high costs and reliance on experienced system architects and practitioners.

The interaction between DT System and SE methodologies are not limited to SE and MBSE guiding DT System engineering. The requirements of a system being accompanied by a DT System guides the engineering of its target entity as highlights [3]. Taking this statement to a next level [51] study the concept of intelligent DT, which a DT is used to generate or develop models, guiding the engineering and evolution of a system during its lifecycle. In this study they focus on requirements

models. Ref [54] notice that the DT, taking the hypothesis that the DT copies a specific instance of a system can guide its engineering, for instance enabling virtual testing, which can serve validation purposes.

Therefore, the problem of applying SE to DT System engineering is twofold, depending on the existence of the target entity.

**The Target Entity is currently being engineered** [3,55]. The engineering of the DT System, and the modelling activities producing the digital representation it contains, can then be based on the models generated by the engineering activities of the target entity (functional, behavioural, architectural, simulation, optimisation and discipline engineering). According to [3] DT engineering, along with the engineering of the target entity is a System of Systems engineering proposing a method based on system engineering principles. The DT can even be a support to the design process, by supporting system modelling and enables to test system's properties in simulation [54]. During engineering DT, in the form of a DT Prototype assist the engineering prototyping digitally [56].

**The Target Entity is in operation**, in which case its models may be partially obsolete for various reasons, but operational data such as related to production KPI or maintenance, acquired from the target entity can be available. Reverse engineering approaches [57–59] can be used to fill these gaps by making use of the system's operating data (performance data, failure and shutdown characteristics, geometric characteristics, etc.) [52,53]. show the usefulness of MBSSE for DT System engineering for existing complex industrial and manufacturing systems.

## 3.2. MBSSE for DT system: A methodological approach

The aim of the proposed method is to facilitate DT System engineering, while reducing the time required, improving collaboration and building trust between all the project's stakeholders. The DT System is considered under two complementary views, defining the problem with a black box vision and then adopting a white box vision on the DT System to engineer.

### 3.2.1. MBSSE processes for DT system

Applied to DT System by adopting recent definitions of such concepts of DT and DT System, MBSSE requests to dispose of modelling artifacts and activities:

* **Modelling artefacts** guide and support engineers during various model and data-based activities requested for engineering any system in classical sense but adapted here to DT System engineering. These artefacts currently remain under formalization and validation stage, so they are just introduced and illustrated in the following. They have been established considering [5] and [6] standards, which provide respectively a standardized definition of DT System basic concepts and elements and a standardized functional architecture for DT System. These standards will be supplemented by functions linked to the specific use for which the DT System is being designed. The whole of modelling artefacts is defined independently from a usable modelling language, adopting then a tool-free approach.

* **Activities** are then organized and managed by adopting classical process-oriented approach already cited in [13] as shown in Fig. 2 and being inspired of courses by [14].

The essential activities underlying these processes and the modelling artefacts used are therefore based on a set of predetermined elements, sometimes derived from proven standards, but also from systemic practices and principles. They must be expressed and submitted to the stakeholders involved in a generic form that can be understood and adapted from one stage to the next, to ensure that the realised DT system achieve its mission and consider the uses and needs of these stakeholders as they arise.

1) **Problem statement:** to define the contours of the DT System and
<figure><img src="image_4.png" /><figcaption>Fig. 2. Model-Based Systems and Software Engineering (MBSSE) process cartography [14].</figcaption></figure>

its inputs/outputs:

* **System purpose**, clarifies why this system exists and justifies how the needs of the final user are addressed by this system, instead of leveraging existing or simpler alternatives. The specificity of the DT System purposes is that they address at least one need expressed by one stakeholders of the target entity. Indeed, the purpose of a DT System is to provide a sufficiently faithful and realistic representation of a target entity to support at least one need of one stakeholder of the target entity. As identified in the state of the art, DT System assists target entity stakeholders for a variety of needs such as supporting control or optimization of the command of the target entity, the management of its maintenance, operator training or assisting target entity engineering. Typically target entities need a DT System because of the faithfulness and dynamic evolution of the representation it provides along with target entities changes. Moreover, it exchanges data in real time with the target entities, which allow target entities stakeholders to make choices that may be critical for the target entity based on real time data.

* **System mission(s)**, which are main functions and actions the system must realize when it is in used to achieve its purpose. In the case of DT System, the missions are representing the target entity in a sufficiently faithful and realistic manner, interconnecting the representation with the target entity, acquiring and feeding back data through this connection to assist the determined usages.

* **System objectives** characterise the expected result, essentially in terms of performance and usability. Objectives set criteria that will allow to certify that all the needs of future end-users have been met at the time of its operational qualification and its entry into the production phase. DT System objectives can be about the delay to obtain a response, required time for set it up, precision of the response compared to the state of the target entity, mean time before

failure, mean time to repair. All these objectives are related to the usages the stakeholders have from the DT System which may not be the same depending on the use and the targeted entity.

* **System life cycle** is made up of alternating stages of development and milestones between each stage. These milestones can be differentiated but are often associated with the proposed reviews to assess the progress of results throughout the processes of the organisational framework. Fig. 3 [5] provides elements for DT System lifecycle according to [5]. The lifecycle proposed in this standard considers the specificities of DT Systems and its relationship with the target entity. The standard presents both lifecycles next to one another on Fig. 3. In compliance with the state of the art in the previous section, DT System lifecycle is parallel with the lifecycle of its target entity. Its development can start right from the start during the "Design and development" of the target entity, enabling interaction and support of engineering at every stage, and producing a DT System operational right at the beginning of target entity operation. Since the DT System represents the target entity in a faithful way, it must evolve along it. The iteration arrow on DT System lifecycle indicates that DT System may have to go through a reengineering process during its lifecycle to keep up with the target entity that may evolve and change. Such an approach has been implemented by [32]. The interaction between the DT System and its target entity can last until the end of life of the target entity, which is recycled. The DT System is then retired, it will have to go through its own retiring procedure, in charge of recycling the components and its data.

* **Stakeholders**, are any person or organisation concerned by, involved in, or impacted by the development project and the implementation of DT System at each stage of its lifecycle. Stakeholders research can then follow the recommendations of [61]. Ref [5] standard introduces a generic list of stakeholders involved with DT Systems in two categories: the DT stakeholders and the ecosystem
<figure><img src="image_5.png" /><figcaption>Fig. 3. DT System lifecycle according to [5].</figcaption></figure>

partners. The stakeholders prescribed by the norm and an interpretation of their role during different phases of the lifecycle is proposed in Table 1.

* **Its operational context(s),** displayed in Fig. 4, describes the other systems that interact with the DT System at each stage of its lifecycle. For example, a DT System used for control purposes constantly interacts with its target entity in operation phase. These interactions are then modelled in the form of services that define the functions that manage the inputs/outputs of the DT System which must be provided to or expected from the DT System to fulfil its missions. Each service is then detailed in the form of the flows it requires (whether material, energy or data) as well as links (e.g. physical links, or communication and exchange protocols) that will have to ensure the transfer of these flows between the DT System and the

<table><caption>**Table 1**

DT System stakeholders' implication (concerned, involved or impacted) according to [5] and their roles in different life cycle phases.</caption><thead><tr><th rowspan="2">DT System Stakeholder</th><th rowspan="2"></th><th colspan="2">Life cycle phases</th></tr><tr><th>Design, development and deployment</th><th>Operations and monitoring</th></tr></thead><tbody><tr><td rowspan="4"><strong>DT System stakeholders</strong></td><td>Developers</td><td>Involved</td><td>Concerned</td></tr><tr><td>Resource providers</td><td>Involved and impacted</td><td>Involved</td></tr><tr><td>Integrators</td><td>Involved</td><td>Concerned</td></tr><tr><td>Users</td><td>Concerned</td><td>Involved and impacted</td></tr><tr><td>Operators</td><td>Concerned</td><td>Involved and impacted</td></tr><tr><td rowspan="4"><strong>Ecosystem partners</strong></td><td>Infrastructure providers</td><td>Involved</td><td>Impacted</td></tr><tr><td>Service providers</td><td>Involved</td><td>Impacted</td></tr><tr><td>Standard development organization</td><td>Concerned</td><td>Concerned</td></tr><tr><td>Government and community</td><td>Concerned and impacted</td><td>Concerned</td></tr></tbody></table>

external systems. Interfaces must remain interoperable with these external systems and ensure either physical or logical connection with them. This analysis of services can also reveal a set of functions (e.g. connecting, disconnecting, or sending requests) that the DT System must concretely implement to provide each service. Five elements have been identified in the DT System operational context.

- **Human actors:** the **user** and the **maintainer**. Their interaction with the DT System is done through the human machine interface. The user leverages the DT System to achieve its main use while the maintainer oversees and takes actions to keep it in operational condition.

- **Target entity:** there is exchange of data that allow the DT System to achieve its mission.

- **Enterprise IT Systems and other IT Systems:** they can typically be Enterprise Resource Planning (ERP), Manufacturing Execution System (MES) or server of the organisation containing with the DT System. They provide necessary data to the DT System to take into account in the analysis the context and external parameters that need to be considered.

- **The power supply system** provides electrical energy to the DT System to ensure its operations at any required time. It should be designed accordingly to provide the required power or by planning component redundancy accordingly to the use.

* **The operational scenarios** describe, briefly or informally, how these services are to be provided or expected, and how they will be linked and synchronised to fulfil the mission. Each scenario therefore describes the expected behaviour of the DT System depending on the state, configuration, and current operating mode of the DT System (e.g. normal operation, degraded operation, shutdown, maintenance) [62]. The set of operational scenarios provided at this stage is important because it must trace or illustrate the overall behaviour required to fulfil the mission in each of the DT System operational modes, preparing for various situations.

Ref [5] already provides a framework with an operational context, a lifecycle and stakeholders. The contribution, currently being formalised is therefore intended to provide generic elements available to the
<figure><img src="image_6.png" /><figcaption>Fig. 4. Generic operational context of a DT System in operations [60].</figcaption></figure>

stakeholders in the engineering project to guide and secure their results.

After the definition of the previous elements, comes the process of needs and requirements elicitation, specifying what the DT System will do in the form of functional requirements under specific assumptions and conditions. DT System capabilities, such as safety, security, interoperability, performances are described under the form of nonfunctional requirements. The aim is to have a repository of SMART [63] functional and non-functional requirements (including performance, security and interoperability requirements). The end of the redaction of a requirement repository is a major project milestone, thus setting the course for the architectural design work that follows.

**2) Solution definition:** the aim at this phase of SE process is to design, develop and validate the DT System in concrete terms, considering the previous phases results, but evolving until convergence and agreement of the stakeholders. Similarly to the problem definition process, the solution definition process happens in two times and aims to engineer DT System architectures.

* **Functional architecture** decomposes the missions of the DT System into functions associated to subsystems of the DT System, and that are based on functional requirements previously elicited. Ref [6] provides a functional architecture of DT in the case of manufacturing systems. However, numerous logical components such as the user entity, the DT entity, the device communication entity and the cross-system entity and there respectively allocated functions can be adapted and reused in any kind of DT and provide and basis for DT System architecting. DT standards do not cover requirements elicitation, but the functional architecture in DT standards [6] guides the functional requirements for manufacturing systems. Therefore, it offers a general, though incomplete, functional view of a DT.

As a first set of results and to guide black box and white box approaches application:

- A generic requirements repository is proposed to guide stakeholders involved in the engineering project, associated with a SMART requirement engineering approach.

- A repository of two types of functions is also proposed: technical functions for the management of the DT System itself, more traditional and promoted by [6], and functions that are necessary and

dedicated to meet the requirements of stakeholders (uses / concerns / constraints).

- These functions are defined and structured in a DT System functional architecture (Table 2), enabling designers to be guided more quickly towards the real added value of the DT System to develop. The model is then considered as a Functional Design Pattern as proposed by [64, 65].

* **Logical architecture** is derived once the functional architecture is established. Logical architecture is derived from functional architecture by grouping functions and allocating them to logical components that can themselves be refined into subcomponents that will be allocated to the physical components. The physical architecture is the final stage of architecture engineering, where the technological choices are done to implement the logical components. In SE process, technological choices for physical components are guided by non-functional requirements that specify them and the capabilities they optimize.

Fig. 5 illustrate the architecture for DT system, derived from previously discussed elements, drawn from both the literature and ISO/IEC 30173:2023 [5] and ISO/IEC 23247:2021 [6] standards. The five logical components of DT System are:

<table><caption>**Table 2**
Main functional decomposition of the DT System, inspired from ISO/IEC 23247:2021.</caption><thead><tr><td>Main DT System functions</td><td>Decomposition in sub-functions</td></tr></thead><tbody><tr><td>To communicate</td><td>To collect data<br>To preprocess data<br>To identify<br>To control<br>To actuate</td></tr><tr><td>To interconnect</td><td>To translate data<br>To ensure accuracy and integrity of data<br>To support security</td></tr><tr><td>To manage</td><td>To operate<br>To provide services</td></tr><tr><td>To interface<br>To store data</td><td></td></tr></tbody></table>
<figure><img src="image_7.png" /><figcaption>5. Main components of DT System [60].</figcaption></figure>

- **Connection sub-system:** the connection elements between the DT System and the Target Entity. This sub-system enables to gather operational data from the Target Entity as well as transmitting instructions.

- **HMI sub-system** is the interface between the users and DT System, thanks to which user can input requests, parameters or have access to results of simulation and analysis performed by the DT System.

- **Data Repository sub-system** gathers data that can be processed in information and knowledge. It also includes a repository for data specific to the DT Systems.

- **Functional entities:** is the functional architecture of the DT System described in Table 1 based on the standard ISO/IEC 23247:2021 [6]. The architecture process is supported by modelling, checking and validating activities that contribute to the development and deployment of the DT System.

The architecture definition process is iterative, incrementally defining the solution. Modelling the necessary components of the DT System during architectures definition process ensures it can perform the required functions in all situations, modes, and operational scenarios. It allows for the consideration of several alternative logical architectures. These concurrent architectures prefigure the different possibilities for implementing the DT System, i.e. the physical architecture alternatives and therefore the DT System product expected by the stakeholders. They also have an impact on the requirements repository by the introduction of new requirements induced by the development choices. Table 2 illustrates the functional architecture of the DT System, independently of any technical solution.

Modelling activities are followed by model verification activities before the transition to the next stage. Then models are evaluated, compared and finally validated with stakeholders at the results of each stage of the engineering process (requirements repository, architecture alternatives). The verification and validation process of models are presented in [14] MBSSE standard. These activities are iterative,

highlighting similarities with an agile engineering approach [66], enabling informed and confident progress.

### 3.2.2. Operating procedures for DT system engineering

Ref [30] propose a decision-making framework for DT engineering, which is based on the purpose of the DT and the achievement of performances to choose among alternatives. This paper proposes a different type of decisions making approach. Especially, the items related to the target entity and their structuration may change depending on the cases of existence of the target identity (Section 3.1.4), which produces different scenario for DT System engineering. Three different situations are identified and presented in the following and summarized in Fig. 6.

* The target entity does not exist: (in blue on Fig. 6) the DT is engineered to be put in operations as soon as the target entity is operational or to support target entity engineering. Then, DT engineering is fed by the engineering of the target entity as a system. The digital representation is made of the federation of system models involved in the target entity engineering. The representation obtained as the Digital Model evolves from an as-designed, as-planned to as-implemented perspective along with the emergence of the target entity during engineering process. This situation for the engineering allows to leverage SE and MBSSE frameworks and the traceability these methods provide right from the start of DT System engineering. In this situation item management, traceability and consistency management can be implemented from the start of the process. It will require to formally choose methods and techniques to manage items.

* The target entity exists, with up-to-date items and engineering materials: (in green on Fig. 6) this DT engineering scenario corresponds to the retrofit of an operational system with DT system, intended to support multiple functions as illustrated in the state of the art of DT uses. In this case, the available items about the system can guide DT System engineering to fit it to the existing infrastructure. Also, the DT System engineering might also require some modifications of the
DTS = Digital Twin
MBSSE = Model Based Systems and Software Engineering
DTh = Digital Thread

<figure><img src="image_8.png" /><figcaption>Fig. 6. DT System engineering operational approach with Digital Thread.</figcaption></figure>

target entity, for instance to add data acquisition interfaces or to interact with the user, therefore DT System engineering guides the target entity reengineering. Regarding the DT, available models can be federated to produce the representation. However, one ought to be careful to verify and validate that available models are consistent with the current state of the target entity which may have evolved, and which may not have been reported in the models available. In this case, items management techniques may have been implemented, allowing the stakeholders to select the items relevant to their needs.

* The target entity exists with missing and obsolete engineering materials: (in red on Fig. 6) in this case, digital items are unavailable or outdated. For instance, it is the case in legacy systems where digital elements are absent [67]. In this case, the engineering of the DT System is a process which will need to be done in interaction with the reengineering of the target entity to interface components between the DT System and the target entity. The digital representation of the system will be obtained following a reverse engineering process of the target entity to recreate the required models. The choice of the models to produce will be guided by the requirements of the DT system, defining what one seeks to achieve with this specific DT system. DT system engineering process will initiate item management, creating the first items that will need to be stored. The set of items generated along this process shall be the object of a reflexion and engineering process about how to store, trace and maintain them over time.

### 3.3. Illustration on the use-case

The methodological elements for DT System engineering previously introduced will be illustrated on the use case presented in Section 2.

The Festo system is a manufacturing system which may benefit from a DT System in various ways, especially for production, order optimisation and training of operators, which are the main purpose developed in [9]. To achieve its purposes Festo DT System must realize several missions. The first mission is to virtually replicate the Festo System with an accurate level of precision, adapted to the use. It will provide a machine-readable description of the Festo system. This model can also

be used to provide visualisation to the human actors of the state of the Festo System, highlight the need for human attention, being a particular simulation results or a problem on the Festo System. The second mission is to simulate the behaviour of the Festo System with an accurate level of precision. The last mission of the Festo DT System is to process simulation results to optimize the realisation of orders and display feedback to human actors to support decision making process.

The engineering of the Festo DT system belongs to the third identified case for DT System engineering. The target entity is in operations, but no items are available about it, therefore requiring a reverse engineering process for DT System engineering. The first step of the engineering is to describe the problem and identify the operational context of the Festo DT System. In fact, the Festo System operates in an environment comprising an operator, a maintainer, a server and a Manufacturing Execution System (MES). The Festo System interacts with systems and humans to ensure its missions i.e. filling and packaging of bottles with granulate or liquid on palettes containing various proportions of the different types of possible bottles. There is a user making orders to the system, the maintainer, the server and the Manufacturing Execution System (MES) and the server managing and storing production data and logs.

The Festo DT System fits in this operational environment presented on Fig. 7. The Festo DT System presented in [9] acquires operational data from the Festo System and the server sends request for production order. The method finally developed already enabled automated data flows between, the Festo DT System, the MES, server and Festo System. Based on these data, the Festo DT System calculates the most optimised production scenarios thanks to the simulation model made with Witness Horizon from Lanner Group. The optimised production orders are sent to the Festo System through the MES, that send the production orders to the Festo System. This feedback loop from the MES to the Festo system is represented by the dotted line in Fig. 7. This service does not strictly belong to the operational context of the Festo DT System, but it realises the feedback loop from the DT System that acquires data, process them and then sent back control data to the target entity.

To carry out the MBSSE approach presented in Section 3.2.1 and 3.2.2 and to study the Festo DT System from these perspectives, the Arcadia method (implemented in Capella) is used [68]. First, a generic
<figure><img src="image_9.png" /><figcaption>Fig. 7. Festo DT System operational context.</figcaption></figure>

DT system is modelled, then the physical architecture of Festo DT Sys-
tem is mapped onto it.

The first step of SE is to describe the problem:

* The operational analysis (see Fig. 8) that describes the operational context, the interaction between systems and stakeholders before the apparition of the Festo DT System.

* The system analysis (see Fig. 9) describes the DT System in a black box fashion, and the interaction with the human actors and systems from the operational context. The Fig. 8 illustrates the operational

analysis and the system analysis in the case of a DT System, in the
case of the target entity and the DT System being both operational.

Once the DT System to engineer is described, it is possible to switch
to a white-box perspective by detailing the inside of the DT System with
the architecture definition processes. Capella implements this process in
two phases: the Logical architecture definitions and physical architec-
ture definition. The focus here is on functional and Logical architecture.
Ref [6] provides elements about the functional architecture without
specifying the flows between functions nor the interfaces between
components. Therefore, the next part is to describe the functional and

<figure><img src="image_10.png" /><figcaption>Fig. 8. Operational analysis description before DT System.</figcaption></figure>
<figure><img src="image_11.png" /><figcaption>Fig. 9. System analysis of DT System and interaction with systems from the operational context.</figcaption></figure>

logical architecture of the DT system with respect to the standard as shown in Fig. 10. The [6] standard describes main logical elements: the user entity realising interfacing with DT System users, the Digital Twin entity processing data and running simulation and interfacing, the device communication entity exchanging data with the target entity and cross systems entity translating data, as introduced in Fig. 11 all those main entity are decomposed to sub-systems.

All the sub-systems are allocated to a function that defines their mission, that is decomposed into different functions. For instance, the mission of the operation and management sub-system is to operate and manage the digital twin, which is decomposed into four functions “to synchronise the DT with the target entity”(the observable manufacturing elements), “to present information that the human machine interface can process, “to represent the information form the target entity to represent physical characteristics” and “to maintain the DT in specified operational conditions”. It is the same for every subsystem of the Digital Twin entity. The decomposition of the other subsystems and their allocated functions is not detailed in the standards but must be the object of iteration in the engineering process to be decomposed accordingly for DT Systems engineering.

The [6] standard could be extended to include a dedicated subsystem storing and managing data specific to the DT Systems. The maintenance sub system is responsible for keeping the DT System operational, identifying and reporting errors but not necessarily for storing these data. It goes same for many other types of data such as log in history of users or initialisation logs. The HMI is also decomposed in at least two sub-systems which are an acquisition sub-system and a display sub-system for the human user for visualization and interaction with the DT System.

After the descriptions of the functional and logical architectures,

comes the description of the physical architectures, describing the physical components that will implement the elements previously describes. The illustrative example is an existing DT System that is studied from the MBSSE point of view, therefore the components making up the functional architecture are already chosen but they can be mapped to the theoretical architecture. The mapping is given in Table 3.

## 3.4. Discussion

This article pursued two main objectives. First, it aimed to demonstrate how SE [13], formalised through MBSSE [14], provides a valuable methodological foundation for DT System engineering. Second, it applied the main processes of MBSSE in a tool agnostic manner to present the specificities of the DT System and illustrate how the elements described by standards [5,6] can be integrate in MBSSE approach. The last part was an illustration of these steps for the Festo DT System with the lens of the proposed DT System engineering approach.

However, the previous discussion considered DT Systems solely as a system, i.e. a set of interacting components, performing a top-level functions [13]. However, this approach does not provide methodological elements to effectively leverage the data from the target entity in the engineering and the operations phases of the Digital Twin.

Indeed, during the systems engineering phases, various digital artefacts such as operational data, models, and patterns are generated to support the engineering process. Ref [7] proposed the concept of *item*, which is defined as ‘any semantic entity which (i) has a tangible form of which a digital and shareable trace remains, and (ii) is made available to, used by or generated by activities and/or stakeholders for the purposes of engineering a complex system’. Items can be perceived as Data, Information or Knowledge (DIK) depending on their level of contextualisation
<figure><img src="image_12.png" /><figcaption>Fig. 10. Main functions of a DT System (ISO23247:2021).</figcaption></figure>

<figure><img src="image_13.png" /><figcaption>Fig. 11. Main elements of DT System logical and functional architecture based on (ISO 23247:2021).</figcaption></figure>

from the point of view of the stakeholders using them. Data is a raw item. Once it is contextualised, it becomes Information and finally, when it is used to support decision making it becomes a Knowledge. So, the same item may be considered as Data or Information or a piece of Knowledge depending on the Stakeholders viewpoint, objectives, skills or involvement in various activities. Ref [14] proposes a complementary interpretation to DIK adding the Wisdom (W) that relies on modelling. Information are data contextualized through modelling activities, which become knowledge once the models are verified and validated to ensure a level of confidence. These models become wisdom when they support system simulation, which can be confidently used to assume and argue

decisions.

All the items, whatever their origins (i.e. from current engineering project, past projects or system operations) must be managed and shared between all the stakeholders. The MBSSE engineering processes generates models guiding and federating stakeholders around the project. These models are used for various purposes: simulation, architecting, evolution or planning for design phase or previsions to pilot a system in operation. At every stage of systems lifecycle lot of data are generated, such as configuration, experimental or operations data, which can be leveraged for performance analysis or maintenance. Digital Twin System standards and academic literature underline the importance of data
<table><caption>**Table 3**
Mapping of Festo DT System physical component to logical architecture.</caption><thead><tr><th>System</th><th>Sub-system</th><th>Sub-sub-system</th><th>Allocated function</th><th>Physical component of Festo DT System</th></tr></thead><tbody><tr><td rowspan="5">Digital Twin</td><td rowspan="5">Digital Twin entity</td><td>Operation and management sub-system</td><td>Operate and manage</td><td>Simulation developed with Witness Horizon</td></tr><tr><td>Application and service sub-system</td><td>Provide applications and services</td><td>Simulation developed with Witness Horizon</td></tr><tr><td>Resources and interchange sub-system</td><td>Realise connection for data acquisition</td><td>MATLAB application for order management</td></tr><tr><td>Digital Twin data storage sub-system</td><td>Stores data related to the DT System</td><td>MES data base</td></tr><tr><td>Data collection sub-system</td><td>Collect data from target entity</td><td>Sensor on DT System Programmable Linear Controller</td></tr><tr><td rowspan="2">Device communication entity</td><td rowspan="2">Device control sub-system</td><td>Send control data to target entity</td><td>Generator of the command file for the MES</td></tr><tr><td>Acquiring data from humans</td><td>Computer keyboard Computer mouse Software for user interface</td></tr><tr><td rowspan="3">HMI</td><td rowspan="3">Data acquisition sub-system</td><td>Display data to humans</td><td>Computer screen</td></tr><tr><td>Translate data</td><td>Method for data integration</td></tr><tr><td>Support security</td><td>N/A</td></tr><tr><td rowspan="3">Cross-system entity</td><td>Data display sub-system</td><td>Assure data</td><td>N/A</td></tr><tr><td>Data translation sub-system</td><td></td><td></td></tr><tr><td>Data security sub-system</td><td></td><td></td></tr><tr><td></td><td>Data assurance sub-system</td><td></td><td></td></tr></tbody></table>

exchange and processing while considering a specific component for data storage and services [4,10,23].

Even for DT System engineering the reuse of items is helpful to build a faithful representation of the target entity that the stakeholders can reuse confidently [36]. Therefore, there is a real need for items reliable management solution, in the sense of traceability, consistency, organisation towards reuse, maintenance, trustworthiness and sharing between stakeholders. The literature designated the Digital thread (DTh) as framework that organise items [8]. So, what is the Digital Thread concept, and what opportunities does it offer for Digital Twin System engineering?

# 4. Opportunities of the digital thread in DT system engineering

This section aims to provide contextual vision and define the DTh, discuss the interaction with the DT and characterise the need of interoperability requirements for the implementation and exploitation of the DTh.

## 4.1. The digital thread

The DTh concept has emerged to ensure the consistency, traceability, sharing and leveraging of models and other types of DIK throughout the system life ([8,47,69,70,]). A systematic literature review [71] has been carried out, outlining DTh definition. The review highlights three key aspects in the definition. First, the DTh is a collection of items during the whole system lifecycle [22,72-79]. It can also be restricted to a part of system lifecycle such the system design [80,81] or manufacturing [82,

[83]. Second, the DTh is a connection between entities that are often separated such as levels of system decomposition [81,84], processes ([85]; S [86]) or systems lifecycle [56,76,87-89].

The DTh, first, enables the mapping the system DIK. By collecting items across lifecycle, it allows to leverage them at any moment, for instance, to evaluate the current state of the system with the targeted objectives or to explain failures. When the target entity is finally operational, the DTh gather models and items related to operations, maintenance or from possible reengineering phases. For instance, in the context of additive manufacturing, the DTh is used to explain manufactured parts quality by following the historic of manufacturing operations [82,90,91]. Secondly, by gathering items, the DTh facilitate collaboration between stakeholder by bridging silos between disciplines and their role in system lifecycle, even when they use different modelling language or engineering practices ([77,92]; S [86,90]; Q [70]).

However, the linkage of DIK across system lifecycle to be shared between stakeholders increases the requirements on data quality, ensuring reliability and trustworthiness of data for their reuse [76,82,92,93].

Thus, the DTh gathers, manages (coherence, version, interoperability, etc.) and makes accessible items produced all along system life cycle. Therefore, it may will define the system at every step of the engineering (as designed, as planned, as implemented, as used and maintained or as retired). For instance, DTh store and share the so-called Digital Mock-up [94] and items. All these elements, from systems models with different maturity levels to various types of items converge towards the DT System. Due to the realism and level of detail required for a DT, building, checking and validating these models is a long and costly process requiring a tremendous modelling and analysis effort. One idea is then to use the Digital Mock-Up (partially or entirely) to reduce effort by reusing models that already produced during the system engineering.

## 4.2. Digital thread for DT systems

The DT System is a complex system which engineering can be improved thanks to the DTh [95]. Moreover, the benefits of DTh for DT System, are increasingly recognised in the literature. According to [87,89] the DTh provides an environment for DT System. During the operation phase, the DTh, as a repository of DIK for the target entity, provides a context for DT System operation as notice [93]. The DTh feeds DT System with data gathered about the target entity. It enables traceability process that facilitates the optimisation of process implemented by a DT System, like [70] achieved for aircraft assembly. The DTh can also enrich the representation of the target entity, thanks to data, models, and simulations [74,88]. During engineering phase, the DTh provides data and actuated models which could be used by stakeholders for DT System engineering [96]. The DTh for instance provides elements for prototype DT which can be used for the engineering of the target entity [56]. The DTh follows the system of interest during its whole lifecycle, therefore it can potentially help the evolution of the DT System to progress along the system lifecycle.

The limitations of the previous considerations lie in the formalisation and implementation of the relationship between the DTh and the DT System. For instance, [87] proposed a formulation for DT and DTh in z-Object formalism and Unified Modelling Language (UML) without explicitly exploring and formalising the relationship between these concepts. Similarly, in Section 3, the benefits of SE and MBSSE principles for DT System engineering are discussed, but so far, no studies integrating SE, MBSSE and DTh towards DT Systems engineering and implementing them together have been identified. Nevertheless, such an approach seems relevant considering that MBSSE is based on models for engineering, which are a particular type of DIK stored in the DTh. The models produced along system engineering when applying MBSSE frameworks have already required substantial modelling efforts from the project stakeholders. The models could also be reused to engineer
the DT part of the DT System, which is fundamentally a model. The benefits and barriers against the reuse of models and other items available in the DTh is discussed in the following.

### 4.3. Federated interoperability for digital thread supporting DT systems engineering

The DTh links together items created during system lifecycle. However, [73] notice that, in the specific case of manufacturing data, it is currently difficult to achieve. Indeed, all the stakeholders of engineering process produce items about the system without really having and sharing the same point of view, nor by using the same modelling languages and tools, producing heterogenous materials. This federation or composition has then to face a classical interoperability problematic. Interoperability is the “ability of two or more systems or components to exchange information and to use the information that has been exchanged” [37,97]. Three approaches exist to achieve interoperability then to allow the federation / composition to be effective. First, integrated interoperability approaches consider elements to interoperate are natively designed to be as much as possible “compatible” with one another. Second, unified interoperability approaches promote common formats to be used by stakeholders and design interfaces to achieve a sufficient level of interoperability i.e. to communicate and share more effectively all items, not only models that are considered here. Finally, federated approaches enable to use together, on the fly, any items independently from its format or modelling language without modifying them nor adding elements to ensure collaboration [98].

The interoperability problem in the case of DT is threefold:

* **Interoperation with other systems in the operational environment:** The DT system must be interoperable with other systems in the operational environment, enabling it to gather and process data to assist stakeholders in their usages. This dimension of the DT System interoperability will be achieved with the design of interfaces with other systems considering requested items to be exchanged, then working at different interoperability levels: data, language, tool, process, and organisation. Federated interoperability would enable to connect the DT System in plug-and-play with systems from the operational context. It would considerably facilitate the

evolution of the operational context with a controlled impact on interfaces and requirements repository of the DT System.

* **Interoperability with other DT Systems:** The DT system must be also interoperable with other DT Systems [99]. The models used to build the digital representation must be interoperable together to build a consistent representation of the system. This representation may evolve during operations to maintain the fidelity of the twinning as the target entity evolves. Among the final purpose of the methodology for DT System engineering, is to be able to reuse DIK produced during target entity reengineering to reengineer the DT System, and the digital representation to remain faithful to the target entity [100].

* **Interoperability to engineer the DT as model:** Among the component of the DT System is the Digital Twin (see Fig. 12) [15,19], which is the representation of the target entity, with appropriate faithfulness adapted to a specific use. The DT is then here considered as a particular Digital Model. A DT is indeed a model from a high level of representativity in terms or requested reality because it results from the federation or the composition of heterogeneous models of the same target entity, here considered of both system and discipline models then connected following formal rules to reach the requested level of realism.

Refs [7,101] highlight that the management of items during system lifecycle must consider the 5Vs: Velocity, Variability, Volume, Variety and Veracity. During an engineering project, considerable volumes of data are generated, that are from varied nature and which types vary with time. The implementation of integrated or unified approaches, requiring case by case item management and fitting for interoperability would require considerable amount of time and be prohibitively expensive. Thus, in this context only federated interoperability approaches seem relevant to implement federation of engineering items, for DT engineering. Ref [36,38] also highlights that federated interoperability is the most promising approach for DT engineering to combine items coming from different heterogeneous stakeholders.

<figure><img src="image_14.png" /><figcaption>**Fig. 12.** Digital Twin defined as a Digital Model [19].</figcaption></figure>
## 4.4. Digital thread opportunities for DT systems engineering

### 4.4.1. Digital thread for the engineering process

First, the engineering process is carried out applying MBSSE principles and SE processes. Both SE and MBSSE principles promote concepts, relationships between concepts and modelling artifacts relevant for the engineering. Many items (both models and data) are then produced along the engineering project and are stored in the DTh to remain accessible and coherent to irrigate all activities and guide stakeholders. For instance, the objectives of the system of interest are defined, then refined into requirements themselves stored in a requirements repository and properly translated and allocated in functional and logical architectures. This allocation will induce choices and new requirements, highlighting the iterative and collaborative nature of such processes. To these purposes, expected interactions between the DTh and SE processes are introduced Fig. 13. So, the DTh is to be seen as an authoritative source of items about the system of interest, hereafter the DT System to be engineered. Authoritative means that DTh must provide items conform to these SE and MBSSE principles, usable to create and check, assuming their coherence, accessibility and assuming traceability and confidence i.e. demonstrating a level of truthfulness of items at each moment. By evidence, and among other rules, consistency and traceability rules are themselves established and conform to SE principles. The whole must be implemented by DTh functionalities.

Second, any engineering activity aiming at providing models and data requests modelling languages or Domain Specific Modelling languages DSML). To this purpose, SysML is a UML profile dedicated to SE, introducing a set of relationships between engineering concepts (Object Management Group [[102], 2023]. In the same way, ARCADIA method, developed by Thales and implemented in Capella modelling tool [68] promotes other modelling languages

Third, stakeholders need tools. Among existent engineering tools, they require particularly tools to enable interoperability of items to support collaborative project. For example, Openflexo [103] supports federation of many types of models, database and documents format in a dynamic way, enabling the communication of a wide variety of items. Such a tool could support the approach previously described by being

capable to support a variety of model types, tool and data structures, while enabling dynamic communication between them. Commercial solutions such as Syndeia [104] from Intercax, recognised by academic communities [105], enables to federate models. Ingespace Circle from [106] support the development of tailored multi agent approach enabling federated interoperability.

However, the applicability of DTh along SE and MBSSE processes is limited because of the absence of methodologies and tooling that natively integrates both DTh and SE. The second limitation is the lack of interoperability described in the previous section.

### 4.4.2. Illustrated in the use case

No models nor other types of DIK where available about the Festo System. So, The Festo DT System has been engineered thanks to reverse engineering methodologies of the Festo System. It allowed to identify the main logical components, to measure manually the time necessary for each operation and to leverage data from the server and the MES to create a model representing with sufficient realism the Festo System and a system enabling to assist production scheduling. The engineering of the Festo DT System belongs to the third identified case for DT engineering, when the system is in operation but not DIK are available or reusable to support the engineering (Fig. 14).

The Festo System is a commercial system produced for training purposes. An instance of the production line was set up at STU-MTF UIAM, which correspond in the vocabular of SE to the integration and transition process [13]. The Festo DT System is a system distinct from the Festo System, however, its engineering must be tailored to it in two ways. First, to produce a digital representation of the Festo System which requires reverse engineering to gather the required DIK to engineer the model. Data about behaviour and operation times was needed in the presented Festo DT System. Second, to determine how data can be acquired from the Festo System and if any modifications would be needed, such as adding sensors, or data connection systems. In the case of the Festo DT System, no changes are made on the system, but bespoke data integration techniques were developed to connect the Festo System to the Festo DT System.

All these processes generate the gathering of DIK about the Festo

<figure><img src="image_15.png" /><figcaption>Fig. 13. The role of the Digital Thread in the SE process.</figcaption></figure>
<figure><img src="image_16.png" /><figcaption>Fig. 14. Festo System and Festo DT System lifecycle.</figcaption></figure>

System, that initiate the apparition of its DTh. This DTh is a source of DIK for Festo DT system engineering. It is fed by the engineering of the DT system which required the engineering of data integration techniques that were introduced by [9]. This step is considered in our methodology as the Festo reverse engineering (Fig. 14), which may include changes on the system which causes reengineering. The system may or may not be operational at this step. Once the Festo DT System is operational, the Festo system enters a new phase of its operational life, during which it is assisted by a DT System.

Table 4 introduces elements gathered into the DTh of the Festo System since the beginning of the Festo DT System engineering, as an examples of the content of the DTh of the Festo System. The source of all items is traced, and for each item there is an associated level of confidence and a level of usefulness for the specific use of engineering of Festo DT engineering. It is the first attempt in studying which DIK stored in the DTh are the most trustworthy to be reused for DT engineering.

## 5. Conclusions

This paper introduces methodological approaches for DT Systems engineering, based on different standards. On the one hand this methodology considers standards defining DT Systems [6] and [5], specifying some characteristics of the system to engineer. On the other hand, standards regarding SE [13] and MBSSE [14] provide methodological principles for complex systems engineering.

The [5] standard introduces the concept of DT System, i.e. considering the DT surrounded by components realising the interaction with the target entity and other systems from the operational context. Together they accomplish DT System purpose, faithfully representing the target entity in a synchronised way thanks to data exchanges. MBSSE approach provides solutions to make the most fitted technical solutions emerge, taking into consideration the specificity of the engineering context and manages the DT System though its whole life cycle.

The engineering and operations of the target entity and its DT System produce and exploit important volumes of items that need to be managed, thanks to the DTh. Items, perceived by stakeholders as DIK, need to be traced, maintained and stored into an authoritative repository along system lifecycle, which is achieved thanks to the DTh. The specificity of a DT System is that it faithfully models a target entity and adjust to its evolutions. Therefore, an understanding of the target entity, through the items available about it may support the engineering of the DT System. Three cases are identified, based on the existence of the target entity and availability of items related to the target entity in

the DTh. These different cases determine different engineering steps for DT System engineering.

The DTh withholds many opportunities for DT System engineering and operations, as they enable a management of data feeding DT System engineering and operations. Items could be federated to produce a faithful representation of the target entity, corresponding to bespoke stakeholders engineering concerns. The next steps will be to develop the method to leverage the DTh for DT System engineering. Such an approach will require to formalise the needs in items for each step of the DT System engineering method. Currently, the usability of the DTh is limited due to interoperability barriers that prevent straightforward items reutilisation [71,73] and their federation for DT Systems engineering. There is a lack of methodology integrating the DTh, MBSSE approaches and DT System engineering. Overcoming these barriers will not only facilitate the engineering of a DT System but will also provide a representation of a given system by gathering items from different points of view, increasing its realism in confidence as it is based on items that come from an authoritative source of truth. Such a representation may assist stakeholders in design choices and carry out early Verification and Validation of the system thanks to models.

The next step for future work will be to reuse items from the DTh to produce the DT at the core of the DT System. This may start with federation of models, seen as a particular type of item, to build a representation of the target entity, gathering different required points of view and levels of details to produce a faithful and useful representation in regards of DT System purpose. Model federation, allowing on the fly interaction between model, techniques will also enable the evolution of the set of federated models to make the DT.

## CRediT authorship contribution statement

**Clarissa Gregory:** Writing – review & editing, Writing – original draft, Methodology, Conceptualization. **Souad Rabah:** Writing – review & editing, Writing – original draft, Supervision, Methodology, Conceptualization. **Vincent Chapurlat:** Writing – review & editing, Writing – original draft, Validation, Supervision, Project administration, Methodology, Conceptualization. **Fedor Burciar:** Writing – review & editing, Writing – original draft, Supervision, Methodology, Conceptualization. **Monika Herchlová:** Writing – review & editing, Writing – original draft, Supervision, Methodology, Conceptualization.
<table><caption>**Table 4**
Items available in the Festo Digital Thread [9].</caption><thead><tr><th>Items</th><th>Origin</th><th>Level of confidence</th><th>Usefulness for Festo DT System engineering</th></tr></thead><tbody><tr><td>Division of the system in logical production units and their functions</td><td>System observation</td><td>High</td><td>High</td></tr><tr><td>Product types</td><td>System observation</td><td>High</td><td>High</td></tr><tr><td>General proceeding of Festo System</td><td>System observation</td><td>Medium, need a systematic approach to identify every operational scenario and modes</td><td>High</td></tr><tr><td>Data available through the MES</td><td>MES specifications and use</td><td>High</td><td>High</td></tr><tr><td>Data retrieved through reversed engineering (functioning times of workstation)</td><td>System observation</td><td>Low, high measures uncertainties, may evolve</td><td>High</td></tr><tr><td>Festo simulation model (Witness Horizon)</td><td>[9]</td><td>High, verified and validated during research process</td><td>High, it is the Digital representation of the Festo DT System</td></tr><tr><td>BPMN model from operations and data processing</td><td>[9]</td><td>High, verified and validated during research process</td><td>High, give access to the service exchanged between Festo DT System with its operational context</td></tr><tr><td>Festo System architecture model in Capella</td><td>For this use case</td><td>Low, not properly verified and validated by exterior stakeholders</td><td>Medium gives a formalized insight on Festo System structure, may be changed by DT System engineering process</td></tr><tr><td>Festo requirement model in Papyrus SysML</td><td>For this use case</td><td>Low, not properly verified and validated by exterior stakeholders</td><td>Medium gives a formalised insight on Festo System structure, which may be changed by DT System engineering process</td></tr></tbody></table>

**Declaration of competing interest**

The authors declare that they have no known competing financial interests or personal relationships that could have appeared to influence the work reported in this paper.

**Acknowledgements**

This work was supported by a French government grant managed by the Agence Nationale de la Recherche as part of the France 2030 program, reference ANR-22-EXEN-0003 (PEPR eNSEMBLE/PILOT).

Part of this work has been done in collaboration with the Slovak University of Technology in Bratislava (STUBA) in the Faculty of Faculty of Material Science and Technology in Trnava (STU-MTF) which provide the use case presented in this study. The collaboration took place during a doctoral mobility finance by a grant offered by the EULiST program in which belong the Institut Mines Telecom (IMT) and STUBA.

**Data availability**

No data was used for the research described in the article.

**References**

[1] S. Singh, M. Weeber, K.P. Birke, Advancing digital twin implementation: a toolbox for modelling and simulation, Procedia CIRP. 99 (2021) 567-572, https://doi.org/10.1016/j.procir.2021.03.078.

[2] C. Zhuang, J. Liu, H. Xiong, Digital twin-based smart production management and control framework for the complex product assembly shop-floor, Int. J. Adv. Manuf. Technol. 96 (1-4) (2018) 1149-1163, https://doi.org/10.1007/s00170-018-1617-6.

[3] J. Bickford, D.L. Van Bossuyt, P. Beery, A. Pollman, Operationalizing digital twins through model-based systems engineering methods, Systems Engineering 23 (6) (2020) 724-750, https://doi.org/10.1002/sys.21559.

[4] F. Tao, M. Zhang, Digital Twin shop-floor: a new shop-floor paradigm towards smart manufacturing, IEEE Access. 5 (2017) 20418-20427, https://doi.org/10.1109/ACCESS.2017.2756069.

[5] ISO/IEC 30173:2023, ISO/IEC 301733:2023 - Digital twin - Concepts and Terminology, International Organisation for Standardization, 2023.

[6] ISO 23247: 2021, ISO 23247:2021 Automation Systems and Integration - Digital Twin Framework For Manufacturing, International Organization for Standardization, 2021.

[7] M. El Alaoui, Définition d'un mode d'analyse et d'une méthodologie outillée de modélisation de la gestion des données/informations/connaissances. https://thes.es.hal.science/tel-04979556v1, 2025. In French.

[8] AIAA Digital Engineering Integration Committee. (2023). Digital thread: definition, value, and reference model.

[9] Burciar, Proactive Simulation For the Control of Manufacturing Systems, DeepL, Trans., 2024.

[10] F. Burciar, P. Važan, B. Juhásová, M. Juhás, Methodical approach to proactivity using a digital twin of production process, Electronics (Switzerland) 12 (15) (2023), https://doi.org/10.3390/electronics12153335.

[11] INCOSE, INCOSE Systems Engineering Handbook 4e 2015 07 (International Council on Systems Engineering (INCOSE), Ed.), John Wiley, San Diego California, 2015.

[12] INCOSE, System Engineering Handbook, 5th edition, INCOSE, Ed., 2023.

[13] ISO/IEC/IEEE 15288:2023, ISO/IEC/IEEE 15288.2023 Systems and Software Engineering - System lifecycle Processes, International Organization for Standardization, 2023.

[14] ISO/IEC/IEEE 24641:2023, ISO/IEC/IEEE 24641 Systems and Softwares engineering - Methods and Tools For Model-Based Systems and Softwares Engineering, International Organization for Standardization, 2023.

[15] E. Fosse, Model-based systems engineering (MBSE) 101, in: INCOSE MBSE Workshop 2013, 2012.

[16] B. Combemale, J. Deantoni, R. France, Globalizing modeling languages. Computer, IEEE, 2014, pp. 10-13. https://inria.hal.science/hal-01074602.

[17] B. Nastov, Contribution to an equipped approach for the design of executable, verifiable and interoperable Domain Specific Modelling languages for Model based Systems engineering [IMT Mines Alès]. https://theses.hal.science/tel-01809000, 2018.

[18] OMG, An OMG Systems modeling publication OMG Systems modeling Language (SysML) part 1: language specification. https://www.omg.org/spec/SysML/20230201/, 2023.

[19] Chapurlat, V., Nastov, B., & Bourdon, J. (2022). A conceptual, methodological and technical contribution for modeling and V&V in MBSE context. ISSE 2022 - 2022 8th IEEE International Symposium on Systems Engineering, Conference proceedings. https://doi.org/10.1109/ISSE54508.2022.10005444.

[20] M. Grieves, Digital twin: manufacturing excellence through virtual factory replication, White Paper 1 (2014) (2014) 1-7.

[21] M. Grieves, J. Vickers, Digital twin: mitigating unpredictable, undesirable emergent behavior in complex systems. Transdisciplinary Perspectives on Complex Systems: New Findings and Approaches, Springer International Publishing, 2016, pp. 85-113, https://doi.org/10.1007/978-3-319-38756-7_4.

[22] R. van Dinter, B. Tekinerdogan, C. Catal, Reference architecture for digital twin-based predictive maintenance systems, Comput. Ind. Eng. (2023) 177, https://doi.org/10.1016/j.cie.2023.109099.

[23] N. Li, G. Xie, X. Zhang, H. Shi, X. Nie, Y. Wang, J. Wang, J. Wang, Six-dimensional digital twin modeling and software platform design for complex industrial systems, J. Intell. Manuf. (2025), https://doi.org/10.1007/s10845-025-02567-8.

[24] Muctadir, H.M., Manrique Negrin, D.A., Gunasekaran, R., Cleophas, L., van den Brand, M., & Haverkort, B.R. (2024). Current trends in digital twin development, maintenance, and operation: an interview study. Software and systems modeling. https://doi.org/10.1007/s10270-024-01167-z.

[25] C. Semeraro, M. Lezoche, H. Panetto, M. Dassisti, Digital twin paradigm: a systematic literature review, Comput. Ind. (2021) 130, https://doi.org/10.1016/j.compind.2021.103469.

[26] E. Negri, L. Fumagalli, M. Macchi, A review of the roles of Digital Twin in CPS-based production systems, Procedia Manuf. 11 (2017) 939-948, https://doi.org/10.1016/j.promfg.2017.07.198.

[27] A. Sharma, E. Kosasih, J. Zhang, A. Brintrup, A. Calinescu, Digital Twins: state of the art theory and practice, challenges, and open research questions, J. Ind. Inf. Integr. Vol. 30 (2022), https://doi.org/10.1016/j.jii.2022.100383. Elsevier B.V.
[28] E. Abisset-Chavanne, T. Coupaye, F.R. Golra, D. Lamy, A. Piel, O. Scart, P. Vicat-Blanc, A Digital Twin use cases classification and definition framework based on industrial feedback, Comput. Ind. (2024) 161, https://doi.org/10.1016/j.comind.2024.104113.

[29] P. Aivaliotis, K. Georgoulias, G. Chryssolouris, The use of Digital Twin for predictive maintenance in manufacturing, Int. J. Comput. Integr. Manuf. 32 (11) (2019) 1067-1080, https://doi.org/10.1080/0951192X.2019.1686173.

[30] H.M. Carlin, P.A. Goodall, R.I.M. Young, A.A. West, An interactive framework to support decision-making for Digital Twin design, J. Ind. Inf. Integr. (2024) 41, https://doi.org/10.1016/j.jii.2024.100630.

[31] C. Chen, H. Fu, Y. Zheng, F. Tao, Y. Liu, The advance of digital twin for predictive maintenance: the role and function of machine learning, J. Manuf. Syst. 71 (2023) 581-594, https://doi.org/10.1016/j.jsmy.2023.10.010.

[32] Z. Yao, H. Wu, Y. Song, Y. Cheng, H. Pan, M. Wu, M. Li, G. Qin, Q. Wang, X. Zhang, Surrogate model-based cognitive digital twin for smart remote maintenance of fusion reactor: modeling and implementation, Nucl. Fusion 64 (12) (2024), https://doi.org/10.1088/1741-4326/6d7b56.

[33] G. Vinci-Carlavan, D. Rossit, A. Toncovich, A digital twin for operations management in manufacturing engineering-to-order environments, J. Ind. Inf. Integr. (2024) 42, https://doi.org/10.1016/j.jii.2024.100679.

[34] J.C. Kirchhof, L. Malcher, B. Rumpe, Understanding and improving model-driven IoT systems through accompanying digital twins, in: GPCE 2021 - Proceedings of the 20th ACM SIGPLAN International Conference on Generative Programming: Concepts and Experiences, Co-Located with SPLASH 2021, 2021, pp. 197-209, https://doi.org/10.1145/3486609.3487210.

[35] J. Yang, B. Cai, X. Kong, X. Shao, B. Wang, Y. Yu, L. Gao, C. yang, Y. Liu, A digital twin-assisted intelligent fault diagnosis method for hydraulic systems, J. Ind. Inf. Integr. (2024) 42, https://doi.org/10.1016/j.jii.2024.100725.

[36] F. Bordeleau, B. Combemalee, R. Eramo, M. Van Den Brand, M. Wimmer, Towards model-driven digital Twin engineering: current opportunities and future challenges. https://inria.hal.science/hal-02946949v1, 2020.

[37] ISO/IEC 30172:2023. (2023). ISO/IEC TR 30172:2023 - internet of things (IoT) - digital twin - use cases.

[38] Galand, G., Rabah, S., Chapurlat, V., Chabal, C., Ledoux, A., Galand, G., Rabah, S., Chapurlat, V., Chabal, C., & Ledoux, A. (2024). Design, development and maintenance of a digital twin of vitrification process: a methodological contribution. 1891-1896. https://doi.org/10.1109/CDIT62066.2024.107082071.

[39] S. Rabah, G. Zacharewicz, V. Chapurlat, Digital Twin for Services (DT4S): conceptual strategy, IFAC-PapersOnLine 55 (10) (2022) 3256-3261, https://doi.org/10.1016/j.ifacol.2022.10.136.

[40] W. Kritzinger, M. Karner, G. Traar, J. Henjes, W. Sihn, Digital Twin in manufacturing: a categorical literature review and classification, IFAC-PapersOnLine 51 (11) (2018) 1016-1022, https://doi.org/10.1016/j.ifacol.2018.08.474.

[41] Su, S., Jiang, L., Wang, W., Wang, W., Chu, C., & Wang, J. (2024). A digital twin modeling method of production lines based on flexible manufacturing. Flexib. Serv. Manuf. J. https://doi.org/10.1007/s10696-024-09571-9.

[42] Mckee, D. (2023). Platform Stack Architectural Framework: an introductory guide A Digital Twin Consortium White Paper.

[43] Digital Twin Consortium. (2024). Digital twins capabilities periodic table.

[44] Himanshu Skukla, AI agent capabilities periodic table generator. https://github.com/digitaltwinconsortium/capabilities-toolkit/blob/main/ai-agent-cpt/examples/ai_agent_jupyternotebook/AIA%20CPT%20Generator%20v1.ipynb, 2025.

[45] Kawas Dana, & Connolly Tim. (2024). Digital Twin business maturity model a Digital Twin Consortium whitepaper.

[46] R. Wei, R. Yang, S. Liu, C. Fan, R. Zhou, Z. Wu, H. Wang, Y. Cai, Z. Jiang, Towards an extensible model-based digital twin framework for space launch vehicles, J. Ind. Inf. Integr. (2024) 41, https://doi.org/10.1016/j.jii.2024.100641.

[47] Podskarbi, M., & Knezevic, D.J. (2020). OTC-30553-MS Digital Twin for operations-present applications and future digital thread.

[48] S. Rabah, A. Assila, E. Khouri, F. Maier, F. Ababsa, V. Bourny, P. Maier, F. Mérienne, Towards improving the future of manufacturing through digital twin and augmented reality technologies, Procedia Manuf. 17 (2018) 460-467, https://doi.org/10.1016/j.promfg.2018.10.070.

[49] W. Wang, H. Guo, X. Li, S. Tang, Y. Li, L. Xie, Z. Lv, BIM system integration based VR modeling in digital twins in industry 5.0, J. Ind. Inf. Integr. (2022) 28, https://doi.org/10.1016/j.jii.2022.100351.

[50] Kreuzer, T., Papapetrou, P., & Zdravkovic, J. (2024). Artificial intelligence in digital twins—A systematic literature review. Data and Knowledge engineering, 151. https://doi.org/10.1016/j.datasci.2024.102304.

[51] S. Maleki, N. Jazdi, B. Ashtari, Intelligent digital twin in health sector: realization of a software-service for requirements- and model-based-systems-engineering, IFAC-PapersOnLine 55 (19) (2022) 79-84, https://doi.org/10.1016/j.ifacol.2022.09.187.

[52] J. Liu, J. Liu, C. Zhuang, Z. Liu, T. Miao, Construction method of shop-floor digital twin based on MBSE, J. Manuf. Syst. 60 (2021) 93-118, https://doi.org/10.1016/j.jsmy.2021.05.004.

[53] X. Zhang, B. Wu, X. Zhang, J. Duan, C. Wan, Y. Hu, An effective MBSE approach for constructing industrial robot digital twin system, Robot. Comput. Integr. Manuf. (2023) 80, https://doi.org/10.1016/j.rimc.2022.102455.

[54] A.M. Madni, C.C. Madni, S.D. Lucero, Leveraging digital twin technology in model-based systems engineering, Systems. (Basel) 7 (1) (2019), https://doi.org/10.3390/systems7010007.

[55] S. Braun, M. Dalibor, N. Jansen, M. Jarke, I. Koren, C. Quix, B. Rumpe, M. Wimmer, A. Wortmann, Engineering digital twins and digital shadows as key enablers for industry 4.0. Digital Transformation: Core Technologies and Emerging Topics from a Computer Science Perspective, Springer, Berlin Heidelberg, 2023, pp. 3-31, https://doi.org/10.1007/978-3-662-65004-2_1.

[56] C. Lehner, A. Padovano, C. Zehnetner, G. Hackenberg, Digital twin and digital thread within the product lifecycle management, Procedia Comput. Sci. 232 (2024) 2875-2886, https://doi.org/10.1016/j.procs.2024.02.104.

[57] M. Sommer, J. Stjepandić, S. Strobawa, M. von soden, Automatic generation of digital twin based on scanning and object recognition, Adv. Transdiscipl. Eng. 10 (2019) 645-654, https://doi.org/10.3233/ATDE190174.

[58] M. Ayani, M. Ganebäck, A.H.C Ng, Digital Twin: applying emulation for machine reconditioning, Procedia CIRP. 72 (2018) 243-248, https://doi.org/10.1016/j.procir.2018.03.139.

[59] Y. Qie, S. Bickel, S. Wartzack, B. Schleich, N. Anwer, A function-oriented surface reconstruction framework for reverse engineering, CIRP Ann. 70 (1) (2021) 135-138, https://doi.org/10.1016/j.cirp.2021.04.016.

[60] C. Gregory, R. Mbolamananamala, S. Rabah, V. Chapurlat, Model Based Systems Engineering applied to Digital Twin engineering: why and how to? IFAC-PapersOnLine 58 (19) (2024) 157-162, https://doi.org/10.1016/j.ifacol.2024.09.126.

[61] Gomez Sotelo Karla Itzel, Yi Xin, Baron Claude, Esteban Philippe, Have you identified all stakeholders?, in: 12th International Conference on Modelling, Optimization and Simulation (MOSIM 2018) (in French), 2018, pp. 117-124.

[62] Chapurlat, V., & Daclin, N. (2013). Proposition of a guide for investigating, modeling and analyzing system operating modes: oMAG.

[63] INCOSE. (2023). Guide to Writing Requirements. INCOSE, San Diego, California. http://www.incose.org.

[64] Adcock, R., Jackson, S., Singer, J., & Hybertson, D. (2024). Patterns of systems thinking. https://sebokwiki.org/wiki/Patterns_of_Systems_Thinking.

[65] F. Pfister, V. Chapurlat, M. Huchard, C. Nebut, J.L. Wippler, A proposed meta-model for formalizing systems engineering knowledge, based on functional architectural patterns, Syst. Eng. 15 (3) (2012) 321-332, https://doi.org/10.1002/sys.21204.

[66] D. Karagiannis, Conceptual modelling methods: the AMME Agile Engineering approach. Domain-Specific Conceptual Modeling: Concepts, Methods and ADOxx Tools, Springer International Publishing, 2022, pp. 3-21, https://doi.org/10.1007/978-3-030-93547-4_1.

[67] S. Deshpande, S. Padalkar, S. Anand, IloT based framework for Data communication and prediction using augmented reality for legacy machine artifacts, Manuf. Lett. 35 (S) (2023) 1043-1051, https://doi.org/10.1016/j.mfglet.2023.08.058.

[68] J.-L. Voirin, ARCADIA LANGUAGE REFERENCE: META MODEL Arcadia language Concepts in details. Chrome-extension, //efaidnbmnnnibcajpcajpcglefindmkaj/, https://mbse-capella.org/resources/arcadia-reference/Arcadia%20Language%20-%20MetaModel.pdf, 2023.

[69] F. Blampain, M. Bricogne, B. Eynard, C. Bricogne, S. Pinon, Digital thread and building lifecycle management for industrialisation of construction operations: a State-of-the-art review, in: International Joint Conference on Mechanics, Design Engineering and Advanced Man- Manufacturing - JCM 2022, 2022, pp. 884-894, https://doi.org/10.1007/978-3-031-15928-2_771.

[70] Q. Zhang, S. Zheng, C. Yu, Q. Wang, Y. Ke, Digital thread-based modeling of digital twin framework for the aircraft assembly system, J. Manuf. Syst. 65 (2022) 406-420, https://doi.org/10.1016/j.jsmy.2022.10.004.

[71] C. Gregory, S. Rabah, V. Chapurlat, Exploring the Digital Thread: A Comprehensive State of the Art Review, In Press, 2025.

[72] T. Feldhausen, K. Saleeby, T. Kurfess, Spinning the digital thread with hybrid manufacturing, Manuf. Lett. 29 (2021) 15-18, https://doi.org/10.1016/j.mfglet.2021.05.003.

[73] T.D. Hedberg, M.E. Sharp, T.M.M. Maw, M.M. Helu, M.M. Rahman, S. Jadhav, J. J. Whicker, A. Barnard Feeney, Defining requirements for integrating information between design, manufacturing, and inspection, Int. J. Prod. Res. 60 (11) (2022) 3339-3359, https://doi.org/10.1080/00207543.2021.1920057.

[74] Z. Huang, M. Fey, C. Liu, E. Beysel, X. Xu, C. Brecher, Hybrid learning-based digital twin for manufacturing process: modeling framework and implementation, Robot. Comput. Integr. Manuf. 82 (2023), https://doi.org/10.1016/j.rimc.2023.102545.

[75] L. Jiang, S. Su, X. Pei, C. Chu, Y. Yuan, K. Wang, Product-part level digital twin modeling method for digital thread framework, Comput. Ind. Eng. (2023) 179, https://doi.org/10.1016/j.cie.2023.109168.

[76] E.M. Kraft, Approach to the development and application of a digital thread/digital twin authoritative truth source, in: 2018 Aviation Technology, Integration, and Operations Conference, 2018, https://doi.org/10.2514/6.2018-4003.

[77] S. Kwon, L.V. Monnier, R. Barbau, W.Z. Bernstein, Enriching standards-based digital thread by fusing as-designed and as-inspected data using knowledge graphs, Adv. Eng. Inf. (2020) 46, https://doi.org/10.1016/j.aei.2020.101102.

[78] L. Monnier, W.Z. Bernstein, S. Foufou, A proposed mapping method for aligning machine execution data to numerical control code, in: IEEE International Conference on Automation Science and Engineering, 2019-August, 2019, pp. 66-72, https://doi.org/10.1109/COASE.2019.8842832.

[79] Y.F. Telnov, V.A. Kazakov, V.M. Trembach, Developing a knowledge-based system for the design of innovative product creation processes for network enterprises, Bus. Inform. 14 (3) (2020) 35-53, https://doi.org/10.17323/2587-814X.2020.3.35.53.

[80] S.K. Mohammed, M.H. Arbo, L. Tingelstad, Using semantic geometric dimensioning and Tolerancing (GD &T) information from STEP AP242 neutral exchange files for robotic applications, Int. J. Inter. Design Manuf (2023), https://doi.org/10.1007/s12008-023-01242-7.
[81] R. Stevens, Weaving a digital thread into concept design, in: 2020 IEEE Aerospace Conference, 2020.

[82] A.M. Crowell, S.A. Cramer, J.P. Lopez, E.K. Rashka, R.C. Reuss, V.K. Wordsworth, G.C. Lewin, Development of a quality assurance tool for additive manufacturing, in: 2018 Systems and Information Engineering Design Symposium, SIEDS 2018, 2018, pp. 76–81, https://doi.org/10.1109/SIEDS.2018.8374763.

[83] D.B. Kim, P. Witherell, R. Lipman, S.C. Feng, Streamlining the additive manufacturing digital spectrum: a systems approach, Addit. Manuf. 5 (2015) 20–30, https://doi.org/10.1016/j.addma.2014.10.004.

[84] A.K. Sleiti, J.S. Kapat, L. Vesely, Digital twin in energy industry: proposed robust digital twin for power plant and other complex capital-intensive large engineering systems, in: Energy Reports, 8, Elsevier Ltd, 2022, pp. 3704–3726, https://doi.org/10.1016/j.egyr.2022.02.305.

[85] Y. Ghanjaoui, M. Fuchs, J. Biedermann, B. Nagel, Model-based design and multidisciplinary optimization of complex system architectures in the aircraft cabin, CEAS, Aeronaut. J. 14 (4) (2023) 895–911, https://doi.org/10.1007/s13272-023-00683-w.

[86] S. Liu, Y. Lu, X. Shen, J. Bao, A digital thread-driven distributed collaboration mechanism between digital twin manufacturing units, J. Manuf. Syst. 68 (2023) 145–159, https://doi.org/10.1016/j.jmsy.2023.02.014.

[87] A. Barbie, W. Hasselbring, From digital twins to digital twin prototypes: concepts, formalization, and applications, IEEe Access. 12 (2024) 75337–75365, https://doi.org/10.1109/ACCESS.2024.3406510.

[88] N. Kasper, M. Pfenning, M. Eigner, The digital thread for system lifecycle management with a native graph database in a polyglot architecture, Proc. Design Soc. 4 (2024) 2079–2088, https://doi.org/10.1017/pds.2024.210.

[89] E. Negri, T.A. Abdel-Aty, Clarifying concepts of Metaverse, Digital Twin, Digital Thread and AAS for CPS-based production systems, IFAC-PapersOnLine 56 (2) (2023) 6351–6357, https://doi.org/10.1016/j.ifacol.2023.10.818.

[90] L. Monnier, W.Z. Bernstein, V.J. Ferrero, S. Foufou, An automated approach for segmenting numerical control data with controller data for machine tools, J. Comput. Inf. Sci. Eng. 24 (4) (2024), https://doi.org/10.1115/1.4064036.

[91] White, C., Forsdyke, J., Harrison, M., Desnerck, P., & Lees, J.M. (2024). Digital threads for sustainable concrete: a prototype traceability system. Structural concrete. https://doi.org/10.1002/suco.202400398.

[92] M. Demartini, F. Galluccio, P. Mattis, I. Abusohyon, R. Lepratti, F. Tonelli, Closed-loop manufacturing for aerospace industry: an integrated PLM-MOM solution to support the wing box assembly process, IFIP. Adv. Inf. Commun. Technol. 567 (2019) 423–430, https://doi.org/10.1007/978-3-030-29996-5 49.

[93] N. Gupta, A. Tiwari, S.T.S. Bukkapatnam, R. Karri, Additive manufacturing cyberphysical system: supply chain cybersecurity and risks, IEEe Access. 8 (2020) 47322–47333, https://doi.org/10.1109/ACCESS.2020.2978815.

[94] Chapurlat, V., & Nastov, B. (2020). Deploying MBSE in SME context: revisiting and equipping digital Mock-Up. ISSE 2020 - 6th IEEE International Symposium on Systems Engineering, proceedings. https://doi.org/10.1109/ISSE49799.2020.92 72230.

[95] S. Wu, G. Wang, J. Lu, Z. Hu, Y. Yan, D. Kiritsis, Design ontology for cognitive thread supporting traceability management in model-based systems engineering, J. Ind. Inf. Integr. (2024) 40, https://doi.org/10.1016/j.jii.2024.100619.

[96] D. Zeamari, C. Gregory, S. Rabah, V. Chapurlat, Digital Twin engineering Guided By MBSSE and Digital Thread, In Press, 2025.

[97] IEEE, IEEE Standard Computer dictionary : a Compilation of IEEE Standard Computer Glossaries, Institute of Electrical and Electronics Engineers, 1991.

[98] M. Labreche, Implémentation d'une interoperabilité fédérée supportée par la transformation automatisée à la volée de modèles de données hétérogènes : application aux problèmes d'appariement des schémas. French, 2023. https://th eses.hal.science/tel-04224022.

[99] A. Giulianelli, S. Burattini, A. Ciortea, A. Ricci, Engineering interoperable ecosystems of digital twins: a web-based approach, in: Proceedings of the ACM/ IEEE 27th International Conference on Model Driven Engineering Languages and Systems, 2024, pp. 476–485, https://doi.org/10.1145/3652620.3688263.

[100] H. Lu, L. Zhang, K. Wang, H. Cheng, An application-time-window based credibility assessment method for equipment digital twins in manufacturing, J. Ind. Inf. Integr. (2024) 41, https://doi.org/10.1016/j.jii.2024.100635.

[101] El Alaoui, M., Rabah, S., Chapurlat, V., Richet, V., & Plana, R. (2022). An original Data, Information and Knowledge management approach for model-based engineering projects.

[102] Object Management Group (OMG), An OMG ® Systems Modeling publication OMG Systems Modeling LanguageTM (SysML ®) part 1: language specification. https://www.omg.org/spec/SysML/20230201/, 2023.

[103] J.-C. Bach, A. Beugnard, J. Champeau, F. Dagnat, S. Guérin, S. Martínez, 10 years of Model Federation with Openflexo: challenges and lessons learned 10 years of Model Federation with Openflexo: challenges and lessons learned, in: Proceedings of ACM Conference (Conference’17), 2024, p. 1, https://doi.org/10.1145/ 3640310.3674084i.

[104] Intercax, Syndeia - the digital thread platform. https://intercax.com/products/ syndeia, 2025.

[105] S. Wu, G. Wang, J. Lu, Y. Yan, Y. Gong, M. Dong, D. Kiritsis, Digital thread in engineering: concept, state of art, and enabling framework, in: Advanced Engineering Informatics, Vol. 65, Elsevier Ltd, 2025, https://doi.org/10.1016/j. aei.2025.103258.

[106] Ingescape I/O. https://ingescape.com/, 2025.