# A Categorization of Digital Twin and Model-Based System Engineering Interactions
## 3 Results
### 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, [PERSON] 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. [PERSON] and [PERSON] [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. Figure 6: Distribution of articles across case study areas. Created by the authors. [PERSON] and [PERSON] [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. [PERSON] and [PERSON] [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. [PERSON] and [PERSON] [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, [PERSON] et al.