Three-Dimension Digital Twin Reference Architecture Model for Functionality, Dependability, and Life Cycle Development Across Industries

The Digital Twin concept promises numerous applications across industries and its physical twin’s entire life cycle. Although numerous architectures have been proposed to develop and describe the setup of Digital Twin applications, current Digital Twin architectures do not address the versatile cross-industry character of the Digital Twin concept, its safety, security, and privacy aspects, and are often use case-specific and inflexible. We propose a three-dimensional Digital Twin reference architecture model for application across industries, considering functionality, dependability, and life cycle aspects. Our model provides practitioners a common platform to develop and discuss Digital Twin applications of different complexities and dependability aspects along varying life cycles and independent of the industry. Its applicability is validated and showcased by examples from the fields of mechatronic products, healthcare, construction, transportation, astronautics, and the energy sector. We compare our reference architecture model to existing architectures, discuss its advantages and limitations, and position the model within previous literature.

its digital representation, which evolves with its physical 23 twin in real-time and provides additional value [4].  tal Twin research can be found in Manufacturing, Aviation, 25 The associate editor coordinating the review of this manuscript and approving it for publication was Giovanni Merlino . showcase the differences between the architectures, while the 84 overview tables demonstrate commonalities. The overview 85 tables mention the application or purpose of each architecture 86 and place the architectures' functional elements in relation to 87 underlying functionalities (Table 1 and Table 2) and depend-88 ability aspects (Table 3). The differences in architectures 89 justify the need for a reference architecture model, while the 90 commonalities demonstrated in the overview tables justify 91 two of the dimensions considered in this article's model. 92 Grieves first proposed the general idea of a Digital 93 Twin [18] and further described it later in his White 94 Paper [12]. The fundamental structure consists of the physical 95 product, the virtual product, and the connections of data 96 and information that connect both (see Figure 1). He also 97 refers to the connection part as a unified repository. Grieves 98 illustrates his idea of a closely linked physical and virtual 99 factory for quicker and more intuitive design and execution 100 comparison of manufactured products. Grieves describes the 101 core elements of the Digital Twin concept upon which later 102 architectures are built. His work has not defined further func-103 tional, dependability, and life cycle aspects. 104 Tao et al. [19] propose a four-component Digital Twin 105 shop-floor architecture comprising a physical shop-floor, 106 a virtual shop-floor, a shop-floor service system, and the 107 shop-floor Digital Twin data tying all dimensions together. 108 The physical shop floor includes humans and machines. The 109 virtual shop-floor dimension consists of geometry-, physics-, 110 behavior-, and rule-based models of its physical counterpart 111 and evolves with its physical counterpart through the data 112 connection between the two. The shop-floor service system 113 contains services for specific demands from the physical 114 and virtual shop floor. These services comprise sub-services 115 in the form of computer-aided tools, Enterprise Information 116 Systems, models and algorithms, etc. The shop-floor Digital 117 Twin data is the center element of the model connecting the 118 other three components and enabling interaction and iterative 119 optimization. The data is integrated, resulting in no distinct 120 data storage entity. While Tao et al. mention dependability 121 and life cycle applications, they are not distinctively consid-122 ered in the architecture. 123 Josifovska et al. [20] analyzed existing Digital Twin lit-124 erature to identify four main building blocks for their Dig-125 ital Twin framework, which they propose for application 126 in Cyber-Physical Systems. The framework consists of the 127 physical entity platform, which incorporates the physical 128 entity (objects and humans) and physical nodes (sensors, 129 actuators, user interfaces), the data management platform, 130 which is responsible for data acquisition, management, and 131 storage, the virtual entity platform, which hosts various Dig-132 ital Twin models (geometric, physical, behavioral, rule, pro-133 cess), and the service platform, which handles the goals of the 134 Digital Twin. Dependability and life cycle aspects cannot be 135 found in the framework.   Intelligence (AI), Visualization, and Process management. 196 The authors mention that Digital Twins integrate into existing 197 enterprise applications which can be allocated to the seven 198 functional layers. Dependability and life cycle aspects are not 199 considered in IBM's reference architecture. 200 Borangiu et al. [24] applied the new four-layer ARTI 201 reference architecture to the production process of radio-202 pharmaceuticals to enable collective and predictive situation 203 awareness and bring software control and real process closer 204 together. The data acquisition and transmission layer acquires 205 and pre-processes process data. The process models layer 206 represents and emulates individual processes, which the data 207 analysis layer uses together with device data to predict equip-208 ment status, product characteristics, and process parameters 209 and detect anomalies. The decision-making layer applies 210 these insights to operate the supervised production control. 211 While functional elements are represented, the architecture 212 does not include dependability and life cycle aspects.
[25] apply their four-layer Digital Twin 214 control architecture to a shop floor transportation system 215 embedded in the global manufacturing scheduling and control 216 system. The data collection and edge processing layer creates 217 information from the data of the physical entity, forwards it to 218 the data transmission layer, and executes orders received from 219 the upper layers. The data transmission layer communicates 220 with the two upper layers in the cloud. The data update and 221 aggregation layer contains, for example, database storage, 222 CAD models, and transportation graphs. At the same time, the 223 analysis and decision-making layer makes decisions based 224 on AI techniques to send the decisions back down through 225 the layers for execution. Răileanu et al.'s architecture links 226 functional and dependability aspects by placing the data 227 update and aggregation and the analysis and decision-making 228 layer in the cloud. Therefore, the architecture only applies 229 to the mentioned application and restricts local Digital Twin 230 applications from being represented. Furthermore, a life cycle 231 aspect is not considered.

232
Redelinghuys et al. [26] propose a six-layer digital 233 twin architecture for various applications, highlighting the 234 exchange of data and information between the physical twin 235 and remote simulation or emulation. The architecture consists 236 of sensor and local controller/data acquisition layers, a local 237 data repositories layer, an IoT Gateway layer, a cloud-based 238 information repositories layer, and an emulation and simu-239 lation layer. Users interface with the Digital Twin through 240 the emulation and simulation layer, whereas the IoT Gateway 241 layer also provides a GUI. The architectural elements can 242 be divided into three dependability levels, local, edge, and 243 cloud. This allocation shows the fusion of functional and 244 dependability aspects, highlighted by data storage located on 245 both the local and cloud levels. Digital Twin implementations 246 across life cycles are difficult to visualize. 247 Zheng et al. [27] propose a generic system architecture 248 for Digital Twin establishment consisting of four layers, the 249 physical layer, the data extraction and consolidation layer, the 250 cyberspace layer, and the interaction layer. The physical layer 251 VOLUME 10, 2022 contains the physical system, its environment, and its data  Abburu et al. [28] propose three different capability ver-   Steindl et al. [30] criticize the often application-specific 308 Digital Twin solutions without general architectural concepts 309 and propose a generic Digital Twin architecture that can be 310 applied technology-independent. From an overview of con-311 cepts, architectures, and frameworks for Digital Twins, they 312 derive a generic 6-layer architecture. The asset layer con-313 tains the physical entity, whereas the integration layer makes 314 run-time and engineering data available. The communication 315 layer ensures the correct data transfer protocols to the infor-316 mation layer, which pre-processes and stores the data. The 317 functional layer provides simulation, monitoring, diagnos-318 tics, prediction, control, and reconfiguration services. Those 319 services are equipped with an appropriate human-machine 320 interface to engage with humans. The business layer hosts 321 the business logic that defines the Digital Twin's overall 322 objectives. Steindl et al.'s architecture describes functional 323 elements and targets the ''instance-phase'' in the life cycle 324 dimension of the RAMI4.0. Therefore, an application across 325 all life cycle stages is difficult, and dependability aspects 326 cannot be explicitly planned. 327 Aheleroff et al. [31] divide their Digital Twin reference 328 architecture model into three dimensions, Digital Twin layers, 329 value life cycle steps, and level of integration. This division 330 aims to facilitate the understanding of complex interrelations 331 by breaking them into smaller and simpler clusters. The 332 dimension of the Digital Twin layers consists of the physical 333 layer, the communication layer, the digital layer, the cyber 334 layer, and the application layer. The physical layer contains 335 the physical assets, sensors, and actuators. The communica-336 tion layer handles inter-layer communication, and the digital 337 layer incorporates static data locally, such as CAD files. The 338 cyber layer includes cloud processing, storage, simulation, 339 and modeling. The application layer makes the outcomes 340 available through user interfaces. The dimension of the value 341 life cycle mentions the iterative, incremental value life cycle. 342 The dimension of the level of integration contains the three 343 types of data flow of Kritzinger et al. [32] and the Digital 344 Twin predictive as a cloud-enabled Digital Twin using Big 345 Data and Machine Learning. Aheleroff et al.'s architecture 346 merges functional and dependability aspects in their Digital 347 Twin layers and involves dependability aspects in their level 348 of integration. This merging restricts the model from being 349 applied to Digital Twin applications with different depend-350 ability characteristics on these layers and levels.

351
Cyber-Physical Systems (CPS) are physical systems con-352 nected to communication and computation entities over 353 the internet [33], [34]. Digital Twins enable CPSs to self-354 configure, self-adjust, and self-optimize [20], and both con-355 cepts are often mentioned together. Lee [27], [30], [36]. The architecture often referred to as 359 5C architecture consists of five ''C'' levels, the smart con-360 nection level, the data-to-information conversion level, the 361 cyber level, the cognition level, and the configuration level. 362 Each level enables different functions based on its complexity 363 rate and reliable data from the physical entity. The data- norms. This reference architecture model is often referred 395 to in Digital Twin architectures [30], [31] and is also con-

418
The analyzed Digital Twin architectures focus on func-419 tional elements, sometimes combined with dependability 420 aspects. Life cycle applications are mostly only mentioned 421 without the aspect being explicitly integrated into an archi-422 tecture for the life cycle planning of an application. This 423 lack of flexibility prevents the application of different kinds 424 of Digital Twin use cases across industries, as they can be 425 applied across the entire life cycle of its entity and at different 426 levels of dependability. We present a Digital Twin refer-427 ence architecture model that addresses this research gap. The 428 model independently considers functionality, dependability, 429 and life cycle aspects in its design, enabling a broad range of 430 applications to be designed and visualized. 432 We see the need to develop a uniform architecture model as 433 a reference based on which interrelationships and details of 434 Digital Twin applications can be discussed. We propose the 435 Innovation Think Tank Digital Twin Reference Architecture 436 Model, which contains the essential aspects of a Digital 437 Twin. Figure (Table 1 and   501   Table 2). Still, the number of used elements, their capabilities, 502 and interactions are application-specific. The analysis further 503 identified six ubiquitous functional elements with distinct 504 sets of tasks, inspired by Schoueri [42]. The physical entity 505 is the basis for any Digital Twin application and builds the 506 functional dimension's basis. The integration element con-507 sists of data sources that record and transfer data from and 508 around the physical entity. Low-level pre-processing can also 509 be executed within the integration element. The data man-510 agement and information element further pre-processes the 511 data, creates information out of it by putting the different data 512 sources in context, and stores the data in a format convenient 513 for further analyses. The modeling and simulation element 514 combines data to digitally represent the physical entity in 515 time and space and simulate potential future scenarios. The 516 decision and user interfacing element orchestrates goals and 517 priorities of the Digital Twin with the user having access in, 518 for example, either read or write mode. The communication 519 element is not considered a distinct element in the reference 520 architecture model as its functionality is spread across the 521 other elements. Communication between the elements and 522 outside entities can be visualized through different kinds of 523 arrows and their annotations between the involved parties. The depth axis in Figure 2 represents the dependability 526 dimension. ''Dependability'' can be defined as ''The qual-527 ity of being trustworthy and reliable.'' [43]. In autonomy, 528 ''dependability'' is often used when referring to safety, secu-529 rity, and privacy issues as a whole [40]. The same defi-530 nition is used in this article. Dependability aspects can be 531 quite versatile and depend on the application. For example, 532

586
The first example in Figure 3 features a Digital Twin 587 setup in the field of medical mechatronic products along 588 the product lifecycle, which was developed and tested 589 at the Siemens Healthineers Innovation Think Tank to the room data storage, where also the point cloud data of 618 the radiography room is received. This data storage directly 619 interacts with the Robot Operating System (ROS) on the 620 room computing unit, where point clouds are merged, obsta-621 cles are detected and recognized, and the motion planning 622 subsystem calculates the planned path and outputs control 623 commands to the radiography device's motors. This setup 624 enables the device to detect and identify objects in the 625 room and adapt its movement accordingly without human 626 intervention.

627
The second application is a Digital Twin predictive 628 maintenance application along the three mentioned prod-629 uct life cycle stages. It can be described as a Digital 630 Twin of a Radiography device's condition using endurance 631 test data, technician maintenance data, and operational 632 encoder data in a data-based model for enabling usage-633 based maintenance. In the ''Development & Manufactur-634 ing'' stage, data is gathered during the endurance test 635 (integration element) of a ceiling-mounted radiography 636 device in testing (physical entity). This data is stored in 637 the factory data storage (data management and informa-638 tion element) before being uploaded to a cross-life cycle 639 stages cloud storage (data management and information ele-640 ment). In the ''Maintenance'' stage, a technician analyzes 641  shows the Digital Twin setup in more detail, as also described 665 by Schoueri [42].

667
The second example in Figure 6 illustrates a human pre-     is designed to guarantee functionalities depending on the 826 severity of an incidence. In case of a major incident with 827 a likely to an imminent threat to the provision of national 828 infrastructure services, individual windmills must comply 829 with SL4 standards. They are designed to locally sense and 830 store their state (integration, data management, and informa-831 tion element), model the effects of their behavior, and make 832 and act on decisions based on that (decision element).

833
In addition to this functionality, in case of a less severe 834 attack with unlikely or potential impact on national infrastruc-835 ture services, windmill clusters must be designed to follow 836 SL3 standards by guaranteeing inter-windmill data collec-837 tion (data management and information element), analysis 838 of network power generation and distribution (modeling and 839 simulation element) and acting based on the decisions made 840 from this analysis (decision element). In the case of a baseline 841 (level 0) event, SL2 standards must be met to guarantee the 842 collection of windmill data in the cloud (data management 843 and information element), its analysis for predictive analytics 844 (modeling and simulation element), and visualization on the 845 power grid surveillance dashboard (user interfacing element). 846 This setup protects critical functionalities depending on the 847 level of a cyber-attack incidence, promising continuous and 848 safe operation of the windmill. This structure helps the wind-849 mill operations staff better react to different cyber-attack 850 severities.

851
In the related work section, the shortcomings of existing 852 architectures were described. In this section, the applicability 853 of the reference architecture model was validated on exam-854 ples from six different fields of application.  [27], [31], observable manufacturing elements [29], and 887 asset layer [30]. Some do not consider the physical entity part 888 of the architecture [29]. Still, we see it as an essential part of 889 the Digital Twin concept where the type and whereabouts of 890 the physical entity greatly impact the rest of the Digital Twin 891 architecture. Therefore, we specifically include the physical 892 entity in the reference architecture model.

893
The integration element is referred to by other architec-894 tures as input data [21], coupling [22], IoT stack [23], data 895 collection and edge processing [25], physical twin sensors 896 and physical twin local controllers and data acquisition [26], 897 data extraction and consolidation layer [27], adapters [28], 898 data collection and device control entity [29], and integration 899 layer [30]. Some architectures do not separate the integration 900 element from the physical entity [12], [19], [20], [27], [31] or 901 the data management and information element [24]. We see 902 data about the physical entity not necessarily coming from 903 the physical entity itself, as demonstrated in the validation 904 example of the medical mechatronic product collision avoid-905 ance application. The data management can also be handled 906 separately from the origin of the data; hence, the integration 907 element is considered a separate element in our reference 908 architecture model. 909 VOLUME 10, 2022 The data management and information element is consid- layer [28], information layer [30], and digital layer [31]. Sev-916 eral architectures combine the data management and infor-917 mation element with the modeling and simulation element 918 [27], [29], [31] or the integration element [24]. We consider twin management layer and user interaction layer [28], user 948 entity [29], business layer [30], and application layer [31]. 949 We see the user interaction often being the decision input 950 and therefore decided to merge these two aspects into one    The reference architecture model was discussed and com-1156 pared with previous research. The importance of separating 1157 the functional and dependability dimension was highlighted, 1158 and the necessity for the life cycle dimension was described. 1159 The compatibility of the reference architecture model with 1160 existing architectures was showcased, and its advantages and 1161 limitations were presented.

1162
The reference architecture model allows practitioners to 1163 more easily plan, develop, and implement Digital Twin 1164 applications, independent of the field, the use case, or the 1165 complexity of the application. By applying our model, the 1166 practitioner is guided through three dimensions of Digital 1167 Twin architecture development, functional elements, depend-1168 ability levels, and life cycle stages. Considering all three 1169 dimensions, the outcome will be a detailed description of 1170 a Digital Twin application architecture. The model cre-1171 ates a common platform for practitioners to discuss Digital 1172 Twin applications, their architectures, capabilities, and fur-1173 ther improvement potentials.