A Categorization of Digital Twin and Model-Based System Engineering Interactions

Abstract

The main goal of this study was to provide a new categorization of the different types of interactions between model-based system engineering (MBSE) and digital twins (DTs). To achieve this goal, an overview of the relationships between these two concepts was obtained based on a representative set of articles. The search identified 444 unique and valid records, of which 16 were selected for analysis based on article screening and eligibility assessments. The selected articles were then analyzed to identify the types of DT-MBSE relations and the area of the case study. As a result, the types of relationships were classified into two main categories: MBSE-based DTs and DTs that use MBSE system models. Finally, we present a case study of the Perception system, a system of systems designed to monitor and generate strategic assets through satellite data collection, further developing the capabilities established by the AlfaCrux satellite mission. Specifically, the case study focused on collecting data from a tower with micrometeorological instrumentation in the Brazilian Amazon Rainforest. The modeling was performed on the Capella software using the Arcadia method. In the case study, the system and the digital twin were designed in parallel based on a five-dimensional DT model.

1. Introduction

In today’s rapidly evolving technological landscape, the concept of the digital twin (DT) has emerged as one of the key technologies of Industry 4.0. The DT can be defined as a digital representation of a physical entity or process capable of simulating its behavior and rules. Digital twins can impact different parts of the product life cycle, from design to product maintenance [1].

The popularity of DTs has grown since their creation; however, there is still no agreement or universally accepted concept [2,3]. Michael Grieves is credited with creating the concept of a digital twin in 2003, introducing it as a virtual representation of a physical object. Grieves’ DT was a three-dimensional model that included physical and virtual products, as well as the connection of data between them. However, at that time, technology was not advanced enough to fully support the development of these virtual counterparts, as later noted by the author in 2014 [4]. In 2012, Glaessgen and Stargel proposed another influential definition of a digital twin, describing it as an integrated multiphysics, multiscale, probabilistic, ultrafidelity simulation that replicates the behaviors and states of its physical counterpart [5].

Through a literature review, Kritzinger et al. [6] categorized DTs based on the level of integration between physical and digital entities, establishing definitions for terms often used interchangeably until then. The proposed categories include digital models, digital shadows, and digital twins. In the digital model category, data transfer between physical and digital entities is entirely manual. Consequently, a state change in one does not automatically impact the other. In a digital shadow, there is unidirectional communication from the physical entity to the digital one, meaning that changes in the physical entity are automatically reflected in the digital entity; however, the reverse is not true. Lastly, in a digital twin, there is bidirectional data exchange between entities, allowing direct mutual influence.

Tao et al. [7] presented an expanded version of Grieves’ three-dimensional DT model in 2018. Their five-dimensional model, illustrated in Figure 1, includes the physical entity (PE), the virtual entity (VE), the digital twin database (DTD), the service system (SS), and the connections between the parts (CN). The PE represents the actual product or service under monitoring. The VE is a high-fidelity digital model of the physical entity, capable of mirroring its geometry, physical properties, behaviors, and rules. The SS encompasses the services provided by the physical and virtual entities to the stakeholders, shown at top of the image. Digital twins rely heavily on data storage and processing, requiring all exchanged data—such as historical data, metadata, and derived data—to be stored in accessible repositories, represented by the DTD in the image [1]. The connections enable seamless communication between all components of the model, facilitating sensor data transfer from the PE to the VE, the transmission of feedback data from the VE to the PE, and the delivery of commands from the SS to both the VE and PE [7].

Minerva et al. [8] suggested a unified definition of a DT by highlighting a series of core properties that allows the digital object to accurately reflect and operate like the physical object within certain defined operational contexts. As a result, a DT system can effectively capture and represent the current state of the physical object, serving as a fundamental realization of the DT concept. The properties are as follows.

• Mirroring: all data and information that characterize the physical object are present in the digital counterpart.
• Virtualization: the capability to virtualize complete systems using software and run them on general-purpose hardware.
• Entanglement: the communication relationship between a physical object and its digital counterpart.
• Representativeness: how accurately the digital object reflects the physical object that it represents.
• Contextualization: only the attributes of the physical object that influence its behavior and performance in a given context are included in the digital object.

Hribernik et al. [9] argued for the evolution of DTs to be considered active entities in their environments; to achieve this, the DTs must have autonomy, context awareness, and adaptivity. A DT should be capable of reacting and adapting to sudden changes in the environment by processing contextual information in real time and of making proactive decisions without external control. The authors provided a roadmap of the research challenges that must be overcome to achieve such digital twins, covering the following areas: context awareness, autonomy, adaptability, general issues, interoperability, modeling, human interaction, and real-time capabilities. Regarding the modeling-related research gaps, the authors argued for the incorporation of context models at the level of system behavior, the connection and collaboration of DTs sharing their contexts, and structured organization in DT networks.

Bellavista et al. [10] also addressed the need for DTs to be adaptive, autonomous, and context-aware. In their work, they provided comprehensive guidelines for the design, implementation, and management of these digital twins. The authors suggested employing a collection of software and architectural patterns to ensure that the implementation of DTs is scalable and reliable. These patterns encompass solutions for single-node services using a single container, single-node services using multiple containers, and services distributed across multiple nodes.

Ricci et al. [11] introduced the concept of the Web of Digital Twins (WoDT), an open, distributed, and dynamic ecosystem of connected DTs. This ecosystem not only virtualizes entire processes, organizations, or infrastructures as cohesive units, but also enables seamless cross-domain interaction and interoperability through a distributed knowledge graph. The WoDT supports the dynamic creation, linking, and disposal of DTs, allowing digital representations of physical assets to be observed and interacted with in real time across various contexts. Tripathi et al. [12] conducted a systematic literature review on DT ecosystems, highlighting the importance and advantages of stakeholder collaboration, which contributes to more efficient and coherent DT ecosystems.

With the growing popularity of DTs and the resulting economic opportunities, software companies such as Microsoft, Amazon, and the Eclipse Foundation have introduced their own DT platforms: Microsoft Azure, Amazon Web Services, and the Eclipse ecosystem, respectively. These platforms provide developers with tools to implement and manage DTs, regardless of the specific context or application [13].

Intuitively, DTs can be classified as complex systems. The development of such systems is facilitated by the implementation of model-based system engineering (MBSE), an approach to system engineering that has gained visibility by providing an alternative to text-based specifications [14]. MBSE is defined by the International Council on Systems Engineering (INCOSE) as “the formalized application of modeling to support system requirements, design, analysis, verification, and validation, beginning in the conceptual design phase and continuing throughout development and later life cycle phases” [15] (p. 5). MBSE helps to better define the requirements of the system, reduces ambiguity, and allows the formal verification and validation of the modeled system [16]. MBSE facilitates collaboration among various stakeholders by promoting a shared understanding of the system, thus addressing technical challenges related to stakeholder commitment in the development of DT ecosystems [12,17].

MBSE can be specified by its adopted method, language, and tools. The first one defines activities and techniques involved in the development, such as Arcadia. The MBSE language is characterized by its syntax and semantics. The most well-known MBSE languages are the Unified Modeling Language (UML) and Systems Modeling Language (SysML). The tool is the software used for modeling; some examples include Cameo, Papyrus, and Capella. Each organization chooses to use the configuration that best caters to its needs [16].

MBSE emphasizes the use of models as central artifacts, allowing engineers, designers, and analysts to capture and analyze complex system behaviors, interactions, and dependencies. It can be inferred that the MBSE models developed to describe the system are a digital representation of it. In some works, the MBSE model is considered the authoritative source of truth for the system [18]. In the MBSE system verification and validation step, it is common to simulate the model to check for design errors, evaluate the early viability of the system, and demonstrate the outputs and outcomes of the use cases [14].

The intrinsic similarities and synergies between digital twins and MBSE have led to increasing interest in their integration. For instance, Lopez and Akundi [19] advocated for an MBSE-enabled DT to enhance system interconnectivity and streamline the optimization process, while also briefly reviewing the relevant literature on the subject. Jinzhi et al. [20] explored the application of MBSE to facilitate model integration in a DT context throughout the system life cycle for an application framework and conceptual architecture, implemented on an auto-braking system. Madni et al. [21] introduced a DT-enabled MBSE research testbed designed to prototype and evaluate aerospace systems. They argued that an MBSE testbed expands on the conventional hardware-in-the-loop testbeds by including abstract models that may or may not interact with the hardware-in-the-loop, therefore supporting integration with DTs. Gregory et al. [22] proposed an MBSE-based DT engineering framework for production manufacturing systems. They distinguished the development of the digital twin according to two scenarios: one for when the physical entity is being designed and another for when it is in operation. These examples illustrate various interactions between DTs and MBSE. However, a systematic focus on these interactions is noticeably absent in the literature. Consequently, this article aims to address the following research questions:

• How can DT and MBSE interact?
• Can these interactions be categorized?

In the context of system of systems engineering (SoSE), integrating DTs with MBSE presents a promising method for the management of complex, interconnected systems. SoSE involves large-scale systems composed of multiple autonomous but interrelated subsystems, each with its own goals and processes. Understanding the different interactions between MBSE and DTs is essential in enhancing system capabilities, managing interdependencies, and ensuring the dynamic collaboration of subsystems.

In this study, a methodology for the selection of a representative set of articles on the research topic is proposed and utilized to curate a database of articles for analysis. This analysis categorizes the types of DT-MBSE interactions. Finally, a case study of the Perception system, which is a satellite data collection system, illustrates one of the categories.

2. Materials and Methods

To conduct the literature review, we combined the PRISMA 2020 [23] framework for the reporting of the review process and the eight-step guide on conducting a systematic review of the literature proposed by Okoli [24]. The steps are as follows: (i) identify the purpose; (ii) draft a protocol; (iii) apply practical screening; (iv) search the literature; (v) extract data; (vi) appraise the quality; (vii) synthesize the studies; and (viii) write the review. The methodology is illustrated in Figure 2, where the outputs of each step are presented. These steps are discussed in the following subsections. The last step represents the contribution of this paper.

2.1. Identify the Purpose

In this step, the purpose of the paper should be explicitly identified. As discussed above, the DT and MBSE concepts have some overlapping characteristics; however, to the best of our knowledge, no effort has been made in the literature to map how they can be used together. Therefore, a review of the literature is beneficial for the scientific community. However, it is important to state that this work does not aim to be an exhaustive review of the subject but rather to initiate a discussion on it, focusing on the most relevant studies that discuss both DTs and MBSE while categorizing the types of relationships between the two concepts.

2.2. Draft Protocol

The second step of the guide is to define the protocol to be used in the review. In this step, the research questions stated in the Introduction, the keywords of the article, the search databases, and the selection criteria were specified [23]. In addition, the PRISMA 2020 framework was selected to report the results in this step.

2.3. Apply Practical Screening

The main objective of this step is to explicitly present the criteria used to select or exclude papers in the review [23]. The criteria used in this study were as follows:

• The article must be written in English;
• The article must have at least 10 citations according to an indexed database;
• The article must be available as a full text.

2.4. Search the Literature

This step focuses on searching the literature for articles related to the topic [23]. Therefore, databases must be defined and the search formula must be written. For this review, two bibliographic databases were identified: SCOPUS and Web of Science. The selection of these databases was due to their status as the two most comprehensive repositories of publication metadata [25]. The choice to use two databases rather than a single one was made to mitigate the potential for topic-related blind spots within the databases. Considering that the topic of this review was the relationship between digital twins and model-based system engineering, both terms had to be present in the search formula. In our context, MBSE is a common means of referring to model-based system engineering and was also included in the search formula. Finally, MBSE is a model-based approach, and it can be referred to as such. Taking these terms into account, the following search formula was constructed and used to search for article titles, abstracts, and keywords:

(“digital twin*” AND (MBSE OR (“model-based” AND ((system engineering) OR approach)))).

The database search was conducted on 17 September 2023, with no restrictions on the publication date or document type. The search found 724 records, of which 469 were from SCOPUS and 255 from Web of Science. The data were imported into Microsoft Excel and analyzed. After removing 230 duplicate entries, 35 records lacking author information, and 15 non-English records, 444 records remained for screening. The records were assessed based on two key metrics: the year of publication and citation frequency. Figure 3 and Figure 4 illustrate these analyses. Figure 3 shows the growing interest in the topic over the years, with the publications increasing from 21 in 2018 to 110 in 2023. Notably, the observed decline in publications from 2022 to 2023 resulted from limiting the search to records published before September 2023. Figure 4 shows that 318 records (71.6%) had fewer than 5 citations, but 19 (4.3%) records were cited over 40 times, and one of them was cited 517 times. It also highlights that the number of records levels off beyond 10 citations.

We screened the records using their titles, looking for mentions of digital twin- or MBSE-related terms. This screening resulted in the removal of 110 records from the study. The next screen focused on the records’ abstracts. We read each abstract, seeking indications that the article would discuss some form of interaction between DTs and MBSE. This screening resulted in the exclusion of 262 records. The next step involved the retrieval of articles/papers, including those accessible via open access and those available through the University of Brasília. Among the remaining 72 records, only 6 records were not available for download and had to be eliminated from the study. To ensure high quality, and based on the results from Figure 4, articles with fewer than 10 citations were excluded, resulting in the removal of 45 articles. Finally, 21 articles were considered for this review. It is worth mentioning that this selection process excluded newer research that could have been relevant but had not yet been referenced sufficiently by others; however, this work was not intended to be a comprehensive review of the topic, as stated previously.

We analyzed the entirety of the remaining articles to determine their relevance to the research topic. During this evaluation, we found that five articles did not discuss any form of interaction between DTs and MBSE. Consequently, these articles were removed from the database, leaving a total of 16 articles for review. The list of selected articles is shown in

Table 1. Selected articles for analysis and review.

Authors	Title	Year	Cited by	Document Type	Reference
Madni A.M., Madni C.C., Lucero S.D.	Leveraging digital twin technology in model-based systems engineering	2019	422	Article	[18]
Bao J., Guo D., Li J., Zhang J.	The modelling and operations for the digital twin in the context of manufacturing	2019	178	Article	[26]
Schluse M., Atorf L., Rossmann J.	Experimentable digital twins for model-based systems engineering and simulation-based development	2017	60	Conference Paper	[27]
Bachelor G., Brusa E., Ferretto D., Mitschke A.	Model-Based Design of Complex Aeronautical Systems through Digital Twin and Thread Concepts	2020	44	Article	[28]
Heber D., Groll M.	Towards a digital twin: How the blockchain can foster E/E-traceability in consideration of model-based systems engineering	2017	31	Conference Paper	[29]
Wang H., Li H., Wen X., Luo G.	Unified modeling for digital twin of a knowledge-based system design	2021	33	Article	[30]
Arrichiello V., Gualeni P.	Systems engineering and digital twin: a vision for the future of cruise ships design, production and operations	2020	29	Article	[31]
Bickford J., Van Bossuyt D.L., Beery P., Pollman A.	Operationalizing digital twins through model-based systems engineering methods	2020	26	Article	[32]
Delbrügger T., Rossmann J.	Representing adaptation options in experimentable digital twins of production systems	2019	25	Article	[33]
Dickopf, T; Apostolov, H; Muller, P; Gobel, JC; Forte, S	A Holistic System Lifecycle Engineering Approach—Closing the Loop between System Architecture and Digital Twins	2019	23	Conference Paper	[34]
Liu J., Liu J., Zhuang C., Liu Z., Miao T.	Construction method of shop-floor digital twin based on MBSE	2021	23	Article	[35]
Laukotka F., Hanna M., Krause D.	Digital twins of product families in aviation based on an MBSE-assisted approach	2021	13	Conference Paper	[36]
Meierhofer J., Schweiger L., Lu J., Züst S., West S., Stoll O., Kiritsis D.	Digital twin-enabled decision support services in industrial ecosystems	2021	12	Article	[37]
Rasor R., Göllner D., Bernijazov R., Kaiser L., Dumitrescu R.	Towards collaborative life cycle specification of digital twins in manufacturing value chains	2021	12	Conference Paper	[17]
Munoz P., Troya J., Vallecillo A.	Using UML and OCL Models to Realize High-Level Digital Twins	2021	11	Conference Paper	[38]
Di Maio M., Kapos G.-D., Klusmann N., Atorf L., Dahmen U., Schluse M., Rossmann J.	Closed-loop systems engineering (CLOSE): integrating experimentable digital twins with the model-driven engineering process	2018	11	Conference Paper	[39]

, ordered by the number of citations.

2.5. Extract Data

In this step, the main objective is to collect information from the selected articles systematically. We used Microsoft Excel to accomplish this task. For each article, the following qualitative fields were filled:

• Type of relationship between DT and MBSE;
• Presence of case study;
• Area of application of case study.

2.6. Appraise Quality

The papers that were selected were closely examined regarding their quality. All articles met the quality standards established by Fink [40] in presenting the methodology, results, and conclusions; therefore, they were accepted. For a visual representation of the complete review process, refer to Figure 5, which shows the PRISMA 2020 flow diagram.

2.7. Synthesize Studies

The seventh step involves aggregating, comparing, and organizing the information to produce a comprehensive synthesis of the records [24]. In this step, there is a shift in focus from an author-centric perspective to a concept-centric perspective [41]. From this step, the categories of DT-MBSE interactions were derived.

3. Results

In this section, the descriptive analysis of the reviewed studies is presented, including the type of interaction between the DT and MBSE, the presence of a case study, the area of application of the case study, and the categorization of the interaction between the DT and MBSE.

3.1. Interaction Between DT and MBSE

The focus of this section is to analyze the types of interactions among DTs and MBSE presented in the selected articles and to describe them.

Madni et al. [18] argued that DT technology should be part of the MBSE methodology and suggested that it will become a key feature in the future. The MBSE model can be seen as the authoritative source of truth for the system during its design phase; however, the DT can extend this reach throughout the life cycle of the system. This can be achieved because a DT is a virtual representation of a specific instance of a physical asset. Additionally, DTs can take advantage of MBSE constructs, languages, and techniques to enhance the virtual representation of the system, as well as to evaluate the system’s behavior on virtual testbeds.

Bao et al. [26] classified DTs in the manufacturing context on the shop floor into three categories: product, process, and operation DTs. The first type is related to the product that was manufactured. The second is intended to support the production process. The third is responsible for simulating and analyzing the interactions between the components of production. Although the authors did not explicitly refer to MBSE, the models used were equivalent or similar to those of this methodology, including behavior models using Petri net-based models and collaborative information models using SysML.

Schluse et al. [27] proposed the concept of an experimentable digital twin (EDT), which is a DT for the simulation of different scenarios of the system in virtual testbeds. The system modeled using MBSE methods and tools is used as a basis for these simulations. The EDT can be linked directly to SysML blocks, requirements, and the test cases developed.

Bachelor et al. [28] discussed their experience and the difficulties encountered while constructing a DT project. They suggested a standard data format for communication between software programs in the DT environment. Their DT was designed using SysML in IBM Rational Rhapsody, with blocks made up of Simulink, Dymola, Modelica, and Rhapsody models. SysML was employed in allocating requirements, formally defining the system’s logical behavior, and aiding integration.

Heber and Groll [29] suggested that product data management (PDM) can be linked to both MBSE and DTs. According to the authors, MBSE models can provide data from the initial design stage, while DTs can give a snapshot of the system at any point after the production phase. The authors proposed that blockchain technology be combined with MBSE models and DTs, allowing for traceability of changes throughout the system’s life cycle securely and transparently. In this context, MBSE and DTs do not interact directly with each other.

In contrast to other studies, Wang et al. [30] proposed a DT for the design process itself. This DT was employed for complexity assessment, effort estimation, and the forecasting of change propagation during the design stage. The authors used SysML and profiles to construct the DT.

Arrichiello and Gualeni [31] suggested that the DT and digital thread can be used to enhance system engineering by integrating MBSE models and engineering models during the initial design stages, as well as keeping these models up to date throughout the system’s life cycle. Furthermore, they discussed the benefits of adopting the DT for each development phase.

Bickford et al. [32] proposed a methodology to develop a DT in parallel to the MBSE system model. This approach can lower the cost of DT development compared to its development after the system is deployed. MBSE defines the standards and ontology of the system, which can improve the DT. In addition, its models can evolve and become part of the DT itself.

Delbrügger and Rossmann [33] combined a DT and MBSE with variability modeling using the concept of the EDT, as proposed by [27]. To simulate and support decision-making, the DT uses the system itself and its variants, modeled by SysML. The authors implemented loose coupling in their DT modeling to enable the simulation of variants.

Dickopt et al. [34] proposed an extension of the v-model for system development, which includes a model-in-the-loop, a twin-in-the-loop, and a system-in-the-loop. This is performed to develop smart products in a system of systems environment, where the SysML model created in the model-in-the-loop step is used to simulate the actual system, thus allowing the twin-in-the-loop to validate the DT during the development phase. Subsequently, the system-in-the-loop provides real-world data back to the development process, closing the loop.

Liu et al. [35] suggested an MBSE approach for the implementation of shop-floor DTs. They divided the implementation process into three domains: the problem, solution, and implementation domains. Each domain is characterized by its requirements, behavior, structure, and parameters. In their work, the authors adopted SysML as the modeling language, MagicGrid as the modeling method, and Camero Systems Modeler as the modeling tool.

Laukotka et al. [36] used MBSE to create master models for a family of products and their variants. These MBSE master models contain meta-information for the product, which is necessary to direct the production of the physical entity, as well as the DT.

Meierhofer et al. [37] proposed the use of MBSE and mixed semantic modeling to create the architecture of a digital process twin. They suggested that this DT of a process can be composed of various individual equipment DTs, which provide data to aid in decision-making. The authors opted to use MetaGraph 2.0 as the architecture modeling tool and KARMA as the modeling language.

Rasor et al. [17] presented a model-based approach to collaboratively specify DTs in their model-based digital twin design framework. The DTs can be broken down into systems of systems, systems, and subsystems, and, for each one, a DT is developed. The authors proposed the adoption of use cases generated by different stakeholders to achieve the collaboration needed to fully specify the DT. To facilitate this task, the authors suggested using their tool, the Digital Twin Specification Grid. This grid divides the DT into five layers: function, information, processing logic, data, and infrastructure.

Munoz et al. [38] employed MBSE to construct a high-level DT and validate it in the early stages of development. The authors introduced a framework for the development of DT systems in a modular and loosely coupled architecture. This high-level DT is a lightweight model that can represent the overall behavior, physics, and structure of the physical counterpart. To model the DT, the authors utilized the UML enriched with Object Constraint Language (OCL) constraints. The modeling tool that they chose was USE, and they opted for the SOIL language to run the DT.

Di Maio et al. [39] proposed the Closed-Loop Engineering (CLOSE) methodology for the integration of EDTs and model-driven engineering processes. The methodology involves using MBSE to model the control logic of the system, which describes the overall behavior of the system. This information is then used by the DT to execute and simulate the system.

3.2. Case Study

Including a case study in research articles is a common practice to aid readers in comprehending the results. Not only does it facilitate understanding, but it also showcases the research’s level of advancement. Hence, evaluating a case study is a vital aspect.

We analyzed the 16 articles and discovered that only one of them did not feature a case study of DTs and MBSE. Among the remaining 15 articles, seven were related to manufacturing, four to aerospace, three to robotics, and one to construction equipment, as seen in Figure 6. The article excluded did present examples for their types of DTs, but they did not provide an example of the interaction of the DTs and MBSE [18].

Considering the publications that included case studies related to manufacturing, Bao et al. [26] presented the development of their three types of DT—product, process, and operation—for a structural part machining cell. For the first type, DTs were developed for structural parts, machine tools, and tooling. These DTs provided 3D models, engineering bills of materials, manufacturing features, and attribute information for the computer-aided process planning (CAPP) system. The process DT is defined by the CAPP and provides the process bill of materials to the computer-aided manufacturing (CAM) system. These DTs are connected to the real machine cell and are updated with the collected data. The operational DTs perform analyses and optimizations of the operation in real time. The authors implemented these DTs for five structural parts. From the results presented, the DT implementation reduced the total running time, downtime, and number of inspection batches, while improving the logistic accuracy. However, it is not clear whether the results were obtained on a real production plant or whether they were simulated.

Heber and Groll [29] illustrated their blockchain PDM’s traceability by providing an example of the development and production of a mirror system of an electric vehicle. Unlike the other articles, the focus was not on the DT itself but on tracking the changes in the metadata derived from the DT. They explained how the blocks were created during the development process and how the DT provided information about specific instances of the mirror system.

Arrichiello and Gualeni [31] focused on DTs for the design and production of cruise ships. They described the potential applications of DTs in this area and their benefits; however, they did not provide any evidence of the development of a DT in this context.

Delbrügger and Rossmann [33] applied their proposed EDT to model various variants of a real production system composed of injection molding (IM) cells. Each cell EDT consisted of an IM machine EDT, a short conveyor EDT, and a handling robot EDT. The modeled variants were created by altering one or more characteristics in the factory EDT, such as the number of cells, the type of handling robot, and the height of the conveyor belt. The behavior of the variants was simulated on a virtual testbed. The factory EDT developed plans for the production and transportation of the different variants according to its capabilities. Finally, tests were conducted to validate the variant combinations, including their production capabilities based on exemplary production orders and physical viability based on physical collisions between machines and the building.

Liu and Liu [35] gave a detailed description of the development of their shop-floor DT, which encompassed the three domains that they identified. To create a 3D interface for the DT, the authors employed a 3D rendering engine (Unity3D). This enabled them to link the DT to the actual shop floor and observe it almost in real time, with a maximum latency of 3.52 s. However, the simulation aspect of the DT was performed offline.

In their study, Meierhofer et al. [37] presented the development of a digital process twin architecture and illustrated its application using a hypothetical manufacturing company. The authors used data collected from 100 actual machines to create the digital equipment twins. The main goal of the case study was to assist in the decision-making regarding machine repair and maintenance on a shop floor. However, the authors did not provide specific details about the implementation of the digital process twin but rather focused on presenting high-level results. It is important to note that these results were obtained through simulation, since the shop floor did not exist.

Rasor et al. [17] provided an example use case using their Digital Twin Specification Grid. They detailed the motion monitoring of a robotic arm in a production environment. In this context, they proposed a DT for the motor, for the robot arm, and for the production. To model the grid, they adapted the diagrams.net software tool according to the method specification. As its focus was to help stakeholders to collectively specify the DT, the grid provided a high-abstraction view of the model, which omitted technical specifications. Finally, the authors also validated their method, tool, and language in a workshop with eight participants.

In the domain of aerospace, Schluse et al. [27] used a Mars landing scenario to further explain their EDT proposal. The authors modeled the system using SysML diagrams; however, the ones presented were simplified in order to focus on the overall methodology. The researchers developed three distinct EDTs using MBSE, each designed for a specific purpose: one for the lander, one for the rover, and one for the Mars environment. They discussed how to simulate this network of EDTs and the benefits of adopting a virtual testbed (VTB) as the integrated simulation environment. The authors further noted that EDTs have been applied in various other fields, such as on-orbit servicing, forest machine localization, driver assistance systems, and industrial automation.

Bachelor et al. [28] provided details about the ice protection system DT described in their article. The system was modeled using IBM Rational Rhapsody, utilizing high-level SysML internal block diagrams. The system consisted of multiple blocks, each representing a different model, with the color of each block reflecting the type of content that it contained. These content types included Simulink, Dassault Systemes Dymola, and Modelica models; Rhapsody state machines; and combinations of models. Furthermore, each high-level block was further described using another internal block diagram. Although the specific models employed in each block were not disclosed by the authors, the diagrams presented were sufficient to gain a thorough understanding of the proposal. They simulated the system in Dymola to compare two different configurations to solve the icing problem; one was electrical and the other pneumatic. They observed the evolution of the ice thickness and the power consumption in each configuration.

Wang et al. [30] implemented their DT concept in a design process for a virtual CubeSat mission. The authors broke down the overall system function into smaller functions that could be assigned to individual designers using the SysML block definition diagram. Interfaces between these functions were represented using SysML internal block diagrams. Subsequently, the functions were allocated to specific designers, although the specific diagram used for this allocation was not provided by the authors. The authors then simulated the modeled system, taking into account the assumptions that they defined. This allowed them to estimate the complexity and workload of the project and analyze the effects of any changes made.

In their study, Laukotka et al. [36] introduced the concept of a product family DT based on MBSE. They provided an illustrative example of an airplane DT to demonstrate this concept. They showed how a DT could be used to keep track of the physical changes of the plane. The collection of real data from a plane can be achieved through the utilization of 3D scanning technologies. The data obtained from this process are then stored within the DT. The MBSE models would provide the relationships between the information. However, the authors only provided an overall idea of the DT, without providing any evidence of its implementation or validation.

Out of the chosen articles, three presented case studies that specifically examined robots. Bickford et al. [32] demonstrated their DT methodology through an unmanned surface vehicle (USV) mission focused on coastal patrol. The mission consisted of a fleet of USVs and a USV base. Although the authors offered a detailed explanation of each stage of DT development, including the USV subsystems, they did not include visual representations, such as MBSE diagrams or models. Using Monte Carlo simulations, the authors examined the effects of DTs on the availability of USV subsystems. The findings indicated improvements in availability compared to missions that did not incorporate DTs.

Munoz et al. [38] implemented their high-level MBSE-based DT on a Lego Mindstorm car. Despite the simplicity of the case study, this work stands out as one of the few in which the authors connected the DT to its physical counterpart and demonstrated the results. The car and the information exchange were represented using UML, while the car’s behavior was described using SOIL, a language that can be executed in the USE environment. To enable two-way communication with both entities, both the DT and the physical car were connected to a data lake. The inputs sent to the physical car were also transmitted to the DT, and the outputs of both entities were compared. If a mismatch occurred, a notification was sent to the user.

Di Maio et al.’s [39] case study focused on an autonomous underwater vehicle (AUV). They utilized the CLOSE process to create a simplified EDT of the AUV propulsion system, incorporating the AUV 3D model, system requirements, functional design, operational design, and physics-based equations. The EDT was then simulated in a multidomain 3D environment that could handle rigid-body physics. By comparing the simulation results with the requirements, the authors were able to improve the design process.

Dickopt et al. [34] modeled an excavator to validate its proposed closed-loop system engineering. In the model-in-the-loop phase, the system modeled in SysML was executed in Cameo System Modeler in order to validate the system’s expected behavior. The results of these simulations were sent to the DT as field data to validate the DT in the early phase. This was achieved by integrating Cameo System Modeler with CONTACT Software Elements for the IoT platform. A graphical user interface was developed to allow interaction between the user and the model. In this case study, the excavator was simplified as a LEGO Technic/Mindstorms excavator. The excavator supplied data regarding its operational duration and power capacity. The data were then linked to the SysML model.

3.3. Categorization

The focus of this section is to categorize the types of relationships that DTs and MBSE can have. In the review process, two primary approaches were observed. In the first case, the DT is constructed using MBSE methods, tools, and/or language. This approach includes instances where the DT was designed with MBSE and was also used in the simulations. In the second approach, the DT makes use of the MBSE system models generated for the system design. The first type of approach was observed in seven articles, while eight were categorized into the second group. The remaining article did not fit either category, as it did not discuss the interaction of both concepts.

Table 2. Categorization of the types of DT and MBSE interactions.

Title	DT and MBSE Interaction	Ref.
Leveraging digital twin technology in model-based systems engineering	DT uses MBSE system models	[18]
Experimentable digital twins for model-based systems engineering and simulation-based development	DT uses MBSE system models	[27]
Representing adaptation options in experimentable digital twins of production systems	DT uses MBSE system models	[33]
Systems engineering and digital twin: a vision for the future of cruise ships design, production and operations	DT uses MBSE system models	[31]
Operationalizing digital twins through model-based systems engineering methods	DT uses MBSE system models	[32]
Digital twins of product families in aviation based on an MBSE-assisted approach	DT uses MBSE system models	[36]
Closed-loop systems engineering (close): integrating experimentable digital twins with the model-driven engineering process	DT uses MBSE system models	[39]
A Holistic System Lifecycle Engineering Approach—Closing the Loop between System Architecture and Digital Twins	DT uses MBSE system models	[34]
The modelling and operations for the digital twin in the context of manufacturing	MBSE-based DT	[26]
Model-Based Design of Complex Aeronautical Systems through Digital Twin and Thread Concepts	MBSE-based DT	[28]
Unified modeling for digital twin of a knowledge-based system design	MBSE-based DT	[30]
Construction method of shop-floor digital twin based on MBSE	MBSE-based DT	[35]
Digital twin-enabled decision support services in industrial ecosystems	MBSE-based DT	[37]
Towards collaborative life cycle specification of digital twins in manufacturing value chains	MBSE-based DT	[17]
Using UML and OCL Models to Realize High-Level Digital Twins	MBSE-based DT	[38]
Towards a digital twin: How the blockchain can foster E/E-traceability in consideration of model-based systems engineering	DT and MBSE are connected to the PDM, but do not directly interact	[29]

presents the categories identified for each article.

Upon analyzing the selected articles and their respective categories, several conclusions regarding the advantages and disadvantages inherent to each category can be formulated. These observations are summarized in

Table 3. Advantages and disadvantages of DT-MBSE interactions.

	DT Uses MBSE System Models	MBSE-Based DT
Advantages	- The DT has knowledge of the system behaviors and rules from the system designers.	- The benefits of using MBSE for the design process.
	- The system model can be simulated and validated in the early stages of its development.	- There is a roadmap for the development of the DT.
	- The DT can extend the system observation throughout the life cycle of the system further than the MBSE.	- The MBSE models can become a high-level DT.
Disadvantages	- The connection between the system and the DT is not defined.	- The connection between the system and the DT is not defined.
	- The MBSE system models must completely define the system and must be up to date.	- The information about the system must be provided by the designer.
		- The use of MBSE models as DTs is limited in functionality.

. A common disadvantage identified across both categories, as inferred from the reviewed articles, is the lack of explicit guidance in designing the integration between the DT and the system.

Finally, future works or new articles may increase the number of categories of relationships between DTs and MBSE, expanding the approaches presented in Table 3, but not invalidating those proposed in this work.

4. Discussion

The studied Perception system is designed to monitor and generate strategic assets through satellite data collection, coordinated by the University of Brasília (UnB). It serves as a bridge from scientific research to technological innovation, contributing to sustainable development. This project integrates multiple autonomous systems—including satellite health monitoring, ground data processing, and monitored assets—that work together to achieve a shared mission objective, creating a comprehensive system of systems. This system is based on the experience and learning derived from the AlfaCrux mission, an amateur radio and educational mission led by UnB, further advancing the university’s capabilities in satellite-based environmental monitoring [42]. Similarly to the AlfaCrux mission, UnB is responsible for the coordination, design, and operation of the mission. The Perception system is currently under development and is nearing the completion of the preliminary design review phase.

The Perception system’s pilot project is related to the Large-Scale Biosphere–Atmosphere Program in the Amazon (LBA), coordinated by the National Amazon Research Institute (INPA) in Manaus, Brazil [43]. In this pilot project, data collected from the K34, a tower with micrometeorological instrumentation, located in the Brazilian Amazon Rainforest, are used to monitor the carbon flux and the overall health of the tower. The INPA, which serves as the end client for the project, also plays a pivotal role by contributing its specialized expertise in micrometeorological towers to the project. The environmental monitoring structure used on the K34 tower is based on a large array of analog and digital sensors connected to a datalogger. The datalogger can connect to an external network through various internet and communication protocols (e.g., Modbus, Ethernet, radio frequency, GPRS, satellite link internet, and transmitters). Currently, the INPA collects data from the K34 tower through a high-gain, long-range, point-to-point radio configuration, through an intermediate communication tower, C14. Figure 7 represents the data collection infrastructure, including the Perception system. The Aerospace Systems Simulation and Control Laboratory (LODESTAR) of UnB is responsible for operating the Perception system and downloading and distributing the data from the satellites. In addition to monitoring and collecting data from the K34 tower, the Perception system also oversees the satellites’ health, as they are responsible for data collection.

One of the innovations of the Perception system is its integration with DT technology. Based on the parallel development of DTs presented in [22,32], the system and DT were designed simultaneously using MBSE. Therefore, this proposal is categorized as an MBSE-based DT approach. The concept of the DT adopted in this work is the five-dimensional model presented in [7] and shown in Figure 1. This model was chosen because it allows for the explicit separation of the models and simulations of the virtual entity from the services that the DT must provide, as well as because it clearly represents the databases.

For the Perception system, the MBSE tool utilized was the open-source Capella tool, (version 6.1) created by Thales Alenia Space, which integrates the Arcadia method and a domain-specific modeling language closely related to SysML [44]. This MBSE configuration has been adopted in several domains, such as transportation, avionics, and space [45,46]. Figure 8 presents a high-level view of the logical architecture of the Perception pilot project and its relationships with the external actors: the INPA and the University of Brasília. In this context, MBSE plays a vital role in defining the system’s architecture, ensuring seamless integration between physical entities (PE) such as the K34 tower and space segments and their digital counterparts (VE). The use of Capella and the Arcadia method allows stakeholders—from researchers at the INPA to engineers at UnB—to collaborate through a shared model, reducing ambiguity and promoting informed decision-making. The model presented in this work has been validated by the project stakeholders; however, as the system remains in the design phase, further refinements and modifications may occur in the subsequent development stages.

The system is divided into four sections based on the five-dimensional model: the physical entity, digital entity, DT services, and DT database. The physical entity is composed of the micrometeorological tower (MT), the space segment, and the ground segment (located at the LODESTAR). The high-level functions allocated to them are related to sensing the environment and transmitting data. The digital entity includes the DTs of the space segment and the MT. The space segment DT is responsible for monitoring the satellite’s health and simulating it, while the MT DT is responsible for monitoring the MT’s health and running carbon flux models for its study. The connection dimension present in Tao’s model [7] is explicitly represented in the MBSE model by the connections between the functions.

The DT services section demonstrates how the system will interact with internal and external actors. It is responsible for providing information to the actors, including the MT health status, processed MT data, and carbon flux data. Additionally, the system includes tools for the visualization of system-related data. In this high-level view, the DT database has two allocated functions: to store MT data and to store satellite data. The sources of these data can be divided into three categories: in-operation data, experimental data, and synthetic data [47]. The in-operation data are collected during the regular use of the PE. The experimental data are gathered through experiments conducted on the physical entities. To obtain synthetic data, specific mathematical models will be used for meteorological data, and, in the case of the satellite, the hardware-in-the-loop simulation structure of the LODESTAR [48,49,50] will be used, with the Ansys Systems Tool Kit (STK) software (https://www.ansys.com/products/missions/ansys-stk (accessed on 3 May 2025)) and a CubeSat Engineering Model (FlaSat) enabling end-to-end technology demonstrations for satellite data collection.

The Perception system interacts with two external actors in distinct ways. The INPA receives processed data from the micrometeorological tower via DT services, establishing an alternative communication channel with the tower. Additionally, the health status data generated by the tower’s digital twin are used by the INPA to support maintenance scheduling and operational planning. Since the digital twin relies on historical data to calibrate and refine its models, the system also requires access to the INPA’s micrometeorological tower database. Researchers at UnB focus on analyzing the carbon flux using the output generated by the carbon flux models embedded within the micrometeorological tower’s digital twin. The ground segment is physically located at UnB; however, as an integral component of the overall system, it is represented within the system model.

5. Conclusions

This paper investigated the interactions between digital twins and model-based system engineering utilizing the PRISMA 2020 framework alongside Okoli’s systematic review guide [23,24]. Through this methodology, we examined a representative range of articles, from different application areas, organizing them into two principal categories: MBSE-based DTs and DTs that utilize MBSE system models. Although these categories offer a structured overview, they may not encompass all aspects, given the methodological limitations. These include potential author biases in abstract screening and full-text analysis, as well as the exclusion of recently published or less-cited relevant articles. Future research can further explore and expand these categories.

The comparison of the two identified categories of DT-MBSE interactions reveals that both approaches offer distinct advantages and limitations. MBSE-based DTs offer a structured development pathway and support early validation and simulation, but they require a specialist to provide information about the physical entity. In contrast, DTs that use MBSE models benefit from the formal system knowledge embedded in these models and can extend system observability throughout the life cycle; however, this approach is impacted by model obsolescence, requiring more effort to keep the models up to date. Of the articles analyzed, only one discussed the parallel development of the DT and the system; however, it was performed separately and did not focus on the integration between the PE and VE [32].

Therefore, an MBSE-based DT approach is presented to model the system and DT simultaneously in the same project using the five-dimensional DT model from [7]. This proposal makes the DT an essential component of the system and not an afterthought. This approach is demonstrated through a case study of the Perception pilot project, designed to collect data from towers equipped with micrometeorological instruments in remote areas using satellite technology. By leveraging MBSE, the Perception system ensures consistency between physical and virtual entities, while the DT provides continuous feedback for system improvement.

Future work will enhance the proposed MBSE-based DT approach by further developing the Perception system, which will involve reducing the abstraction level, modeling additional use cases, and performing empirical validation and performance evaluations. There is also a need to deepen the research on the integration between the system definition and its digital counterpart in the early stages of development. The next step is to incorporate risk assessments directly into the MBSE process, linking hazard analysis, failure modes, effects, and criticality analyses, as well as fault tree analysis, to automated engineering checks and digital twin-enabled what-if simulations.

This study serves as a foundation for the exploration of the interactions of two key concepts in Industry 4.0, facilitating the development of robust, adaptive, and continuously improving cyber-physical systems across various application domains.