Development of a Generic Implementation Strategy of Digital Twins in Logistics Systems under Consideration of the German Rail Transport

Featured Application

Utilization of research results to realizing digital twins in logistic systems of the rail transport.

Abstract

In the course of digitalization, the concept of the digital twin (DT) has become increasingly important in recent years. Hereby, initial concept approaches focus on use cases in industrial production. Although the concept has diverse potential for the asset intensive and increasingly important German rail transport sector. Due to the still low level of research of the DT, there are few empirical values on how this promising concept can be implemented in a target-oriented manner. In a qualitative-explorative research design, this work focuses on answering the question of how a generic implementation strategy (GIS) of DTs in logistics systems of German rail transport can be designed. The central result of this work is a validated GIS which has a sufficient level of detail for the targeted implementation of DTs. Due to its socio-technical system focus, this process model enables user-oriented development and consideration of the complex framework conditions of German rail transport for the first time. The perspective use of the GIS as well as the utilization of the derived recommendations for action contribute to realizing DTs. Consequently, this work is to be regarded as an important instrument for achieving the operational optimization and intelligent management of rail transport assets.

1. Introduction

In the course of digitalization, the possibility of interaction between the real and virtual world promises innovations, new business models and considerable optimization potential in industry and logistics within the framework of Industry 4.0 [1]. To realize this potential, digital networking of production and logistics using the Internet of things (IoT) and cloud technology as well as other digital technologies, such as artificial intelligence, is necessary. With respect to the energy transition and the predicted growth in freight and passenger transport, German rail transport is becoming increasingly important due to its climate-friendly CO₂ balance compared to other means of transport [2]. In response, the federally owned railway company Deutsche Bahn AG (DB), which is the largest railway operator and infrastructure owner in Europe, launched its umbrella strategy Strong Rail and decided on the largest modernization program to date, amounting to 87 billion euros [3,4,5]. It is a comprehensive approach for expansion of the rail network, passenger and freight transport, which should serve the top maxim of securing the system capacity as it plays an important role in the provision of overall transport services [3,6].

With the need to modernize the rail network and infrastructure comes the need for targeted operational monitoring and predictive maintenance of relevant assets to ensure the operational reliability and availability of German rail transport. To achieve this, digital technologies promise the necessary innovation potential to solve challenges that have not been satisfactorily solved so far, such as the punctuality of German rail vehicles, which result from rail network congestion and the partially inadequate technical condition [7,8]. The transfer and representation of real objects in a digital and virtual environment, the so-called creation of a DT [9], enables operational and visual monitoring in real time as well as early detection of unscheduled deviations in operation. The early prediction of future events, based on data-driven evaluations as well as simulations and forecasts, can optimize operations and maintenance, enable preventive measures, and generate potential savings. In addition, this holistic data collection and visualization in a downstream instance provides the opportunity, for example, to network the value creation network of maintenance in a cloud-based manner and to profitably exchange and analyze data-driven information among manufacturers, operators and maintenance staff [10]. In an EU research project called EU OPTIMSED it was shown that a DT implementation in rail transport can be profitable. Through the DT, the management of train maintenance work was hereby simplified and efficiency as well as availability of the train fleet realized [11].

Looking to the future, the gradual introduction of DTs in rail transport thus forms the basis for a holistically networked and intelligent system that can monitor and control operations in a targeted and efficient manner [12]. This so-called Supra-system connects self-contained DTs on an open and comprehensively networked platform and thus avoids data silos. Due to the openness of the platform, additional services can be integrated and considerable added value can be created for all stakeholders [10]. A study by the information technology (IT) market research company Gartner reveals that more than 74 percent of companies in a wide range of industries are planning to implement DTs in their processes in the next five year [13]. Furthermore, business scenarios for DT implementations are expected to become more attractive and the technologies used more reliable and cost-effective. Nevertheless, only 13 percent of companies in a wide range of industries that have already implemented IoT technology and solutions, are making use of the promising DTs [13]. Furthermore, a study by the worldwide largest logistics company DHL comes to the conclusion that within the logistics industry, companies largely have the necessary technologies for DT implementation, but are not yet fully exploiting this potential due to planning and implementation uncertainties [14]. With reference to the listed potential and the expected increase in attractiveness, the question, therefore, arises which aspects make the implementation of DTs more difficult or even prevent it.

The application domain of DTs is still dominated by proprietary solutions and prototypes and therefore at an early age. It focuses predominantly on applications in manufacturing and production industries, while DT applications “lack the necessary generality and openness to be widely used” [15]. The use of individual DTs for assets amounts to less than one percentage point in a representative survey of CIOs, whereby market maturity is also not expected for three to five years [13].

In the context of barriers to implementation, the transport and logistics industry notes that “implementing a digital twin is a complex and challenging task” [14]. A meta-study categorizes possible challenges for companies that consider the implementation of DTs to be useful into technical, commercial, technological, data-driven and other challenges [10]. The analysis of data is a central challenge of DTs, whereby the existence of a sufficient IT infrastructure plays a crucial role [16]. Companies are facing the challenge of designing uniform data structures and management systems as well as merging and analyzing collected data sets in a targeted manner. This raises questions for companies about data security, ownership, and distribution. Hereby the avoidance of data silos is difficult, as there are no uniform legal structures and approaches for the exchange of data. Furthermore, the existence of different IT systems and software complicates the implementation of DTs [10]. Regarding the maturity of DTs, two further challenges are the management of expectations and trust. DTs should only be used where it makes sense and they must be understandable for all stakeholders, regardless of their IT expertise [17]. In addition, there are also challenges regarding the standardization and compatibility of data, interfaces and components [16] as well high costs and interoperability of DTs [14]. Furthermore, “regarding the implementation of DTs, a critical question is how to build a practically viable DT model. On the one hand, almost every paper […] acknowledged the importance of DT modeling. On the other hand, no consensus has been reached regarding how to build a DT model in a generic way” [18].

From the aspects described, it can be deduced that companies in the rail transport sector, which consider the use of DTs regarding operational optimization to be sensible, lack a generic method, which they can use as a guide for the implementation of DTs. In this scientific work, a generic strategy is therefore developed, which serves as a guideline for the implementation of DTs in German rail transport and should thus contribute to overcoming the challenges mentioned. A multi-perspective research question is derived from this, which, following a broad understanding, illuminates technical as well as organizational aspects. The research question is:

“How can a generic implementation strategy of digital twins in logistics systems be designed considering German rail transport?”

As this research question aims to provide a specific answer that can comprehensively answer the complexity of the research problem, it is complemented by the following research objectives:

• To identify and define the essential theory needed for the entirely novel development of a GIS for DTs in German rail transport;
• To analyze related scientific work and derive requirements for the problem-oriented development of a GIS for DTs;
• To develop, apply and validate a GIS of DTs in logistics systems of the German rail transport;
• To derive and discuss practical implications to the German rail transport.

The structure of this work is divided into a total of six sections. Section 2 serves the research background, which lays the foundation to derive relevant aspects for the independent development of GIS in Section 3. In detail, this means that a qualitative content analysis on relevant research papers is carried out to develop the GIS. Based on the insights gained, the GIS is further developed and reviewed in Section 4. This inductive evolution and validation of the developed approach is carried out based on an individual case study at the micro level in German rail transport and methodologically examined in the form of qualitative expert interviews with DT experts of DB. The result of this Section is the validated GIS. In the penultimate Section 5, a comprehensive discussion of the results is obtained, which serves to derive findings as well as generalization and theory building. In addition, a closer look is taken at the relevance of the results for science and practice. Finally, the work is concluded in the last Section 6 with a summary and classification of the results as well as an outlook.

2. Research Background

2.1. Understanding of the Generic Implementation Strategy

With reference to the research area of implementation derived in Section 1, it can be stated that an implementation can be holistically differentiated into functional and institutional anchoring. Institutional anchoring comprises the totality of all persons involved in the implementation, whereas functional anchoring describes the activities necessary for it [19]. The focus of this work is a functional design of the GIS.

The term strategy is in the entrepreneurial manner understood as a long-term behavior and combination of measures for the realization of long-term goals [20]. The term implementation focusses on “the process of translating a design into hardware components, software components, or both [and] the result of that process” [21]. It transforms the defined requirements, architecture, design and interfaces of the design phase through process activities and is carried out according to a defined implementation strategy, which contains constraints as well as defined procedures [21,22]. In a broader sense the activities of implementation are supplemented with testing and acceptance as well as maintenance and operation [23]. The term implementation strategy is an amalgamation of strategy and implementation. It is the purposeful behavior and combination of measures of the enterprise towards its environment, for the realization of an implementation of systems. In the context of IT systems, it includes the process of implementation and production, tools, and equipment as well as tolerances of implementation and uncertainties of verification. The processes are defined more precisely if the system under consideration is to be implemented several times and repeatedly. This serves to ensure consistent and uniform production and implementation [22].

There are different procedural models of an implementation strategy. A distinction is made between forward- and reengineering, whereby reengineering refers to implementation strategies that serve to transform a legacy system into a new target environment, i.e., a reuse of an existing system [24,25]. Within forward engineering, a system is either functionally further developed on the basis of a system specification, newly created or acquired [22]. To implement this, there are various models, so-called process paradigms, which represent the structure of necessary processes, whereby a distinction is made between plan-driven and agile processes [25]. Plan-driven implementation strategies represent procedures in which all development process activities are planned. In agile implementation strategies the development process does not follow a strict plan made in advance. However, there is no universal process model. This is because the requirements of stakeholders and the environment in which the system is to be used have a significant influence on the process [25]. Regarding the understanding of the term GIS, generic means that the property or designation of an object or concept is to be understood in a generally valid sense and not specific [26]. In the context of DTs, this generality is of particular importance (see Section 5.1 and Section 5.2) to avoid isolated systems and secure the interoperable and standardized communication of multiple DTs [15,23,27]. Industry and business have also recognized this need and are therefore dedicated to the standardization of DTs with multi-layered consortia such as the Industrial Digital Twin Association or the Digital Twin Consortium. In the context of this work, a GIS of DTs is, therefore, defined as the targeted behavior and combination of measures that serves the generally valid implementation of the DT concept.

2.2. Understanding of the Digital Twin

2.2.1. Definition of the Concept

The origin of the concept of DTs goes back to Grieves in 2002. The DT concept comprises a real and a virtual system, as well as the connections for the flow of data and information from the virtual space to the real and vice versa. Grieves describes the existence of a real or potentially real physical system, which is the basis for the newly created virtual system, as a central prerequisite for the concept [9].

To date, there is no uniform definition of the DT concept [28] and many further developments and different understandings of DTs exist [18,29]. Due to the multitude of definitions and the resulting inconsistent conceptual use, it is difficult to describe the main components of a DT [30]. These ambiguities have led to some difficulty in clearly delineating conceptual similarities such as the digital shadow or digital model [16,27]. This is due to the fact that DT has evolved technologically and there are different areas of application, which have also expanded [29,31]. Furthermore, the extent to which the DT is integrated into other systems is decisive for the definition [27]. The definition of DTs is, therefore, application-related and specific. In general, based on the literature and industry, it can be concluded that the overarching goal of a DT is the provision of services [30,32].

In comprehensive studies on the current state of research on DTs [17,18,29], provide an overview of commonly existing definitions [33]. In summary, the digital representation and information exchange between physical and virtual space are important artefacts. Furthermore, the use of five dimensions in the conceptual description and implementation of DTs in the context of implementing a DT in a production facility are recommended. According to this, a DT consists of a physical and virtual space, data, services, and the connections between the individual dimensions. This conceptual description is confirmed by [29,34]. In addition, with reference to the functionality of a DT, the DTs include the reflection of real-time processes—an interaction and convergence as well as self-development. Furthermore, the majority of published studies and research focus on the implementation of industrial applications in production [18,27,35]. They summarize the primary fields of application such as the design, production, forecasting and maintenance of a product, and therefore, exist along the life cycle of a product or asset [29]. In addition, to summarize, DTs have promising advantages along the product life cycle in industry, and furthermore, they have great potential for the realization of Industry 4.0.

In practical use, DTs are still at the beginning of their widespread implementation. Among industrial and IT companies as well as IT market research institutes and consultancies, different definitions exist, as well. For example, Gartner defines processes, organizations, or people, besides the initial the concept of a DT, as relevant components, and the focus of the virtual mirror image. The definition of a DT is steered in the direction of an ecosystem, as the data of different DTs are linked and aggregated [35]. This definition is supported by the understanding of the common data environment (CDE) envisaged in the rail industry, as mentioned by Capgemini. This is regarded as the basis for the goal-oriented management of critical assets along their life cycle in rail transport [36]. In addition, IBM describes that a DT can represent not only the pure virtual representation of a physical object but also its entire life cycle and emphasizes in particular the interoperability of systems, i.e., the ability of different systems to work together as seamlessly as possible [37]. Several of the companies listed address the point that a DT obtains data from operations, i.e., through IoT sensors, and other internal and external sources of information. GE Digital makes the connection to analytics tools and machine learning in terms of a DT’s ability to run simulations, and sees the primary application areas in assets, networks and processes [38]. With reference to the maturity level of an implemented DT, Detecon addresses the level of communication between physical and virtual object as well as the degree of standardization of the data models and sources of a DT, whereby standardization means the ability of the DT to exchange data with internal and external systems to be integrated into a multilateral ecosystem. According to this, a DT only exists if there is bi-directional communication between physical and virtual entities and interactions with one of the two entities have direct effects on the other and vice versa [39].

The environment in which the DT is to be implemented significantly influences the definition of a DT. In the context of this work, these external circumstances, also referred as the digital twin environment (DTE), are mainly driven by the DB environment [9]. The IT subsidiary of DB defines DTs as a digital representation of objects, persons or processes that enable a comprehensive exchange of information and pursue the goal of optimizing a business result. Furthermore, they can contain “algorithms, simulations and services that describe or influence past, present or future properties and behavior of the represented object” [12]. To give justice to the scientific claim of this work, the definitions from science and practice are assembled with the philosophy of DB. Based on the described fact that no uniform DT definition exists, and that the definition is related to the case of application, this work is based on the following DT definition in the context of the research project:

“The concept of the digital twin consists of a physical and virtual space in which four system platforms exist: the physical and virtual asset, the data management and the services. The different dimensions are interconnected and exchange data. The virtual system platform is a physically correct digital representation with very high fidelity of the physical system platform. The overall goal of a digital twin is to offer concrete services and business outcome in its environment. This serves the operational optimization of the asset under consideration along its life cycle.”.

This definition, which is illustrated in Figure 1, is kept general due to the objective nature of this work, and therefore, does not specify the maturity level of DTs in terms of communication and standardization, as well as the services and properties offered. Furthermore, it does not go into detail about the technologies that are necessary for the development and use of the DT, as these also depend on the specific use case. The term asset is chosen due to the fact that [40] is defines an object as an “entity that has a perceived or actual value to an organization and is owned or managed individually by the organization”. The term thus covers the areas of DT application mentioned by DB Systel GmbH and is in line with science, as no clear definitions exist here.

2.2.2. Application along the Asset Life Cycle

The concept of DTs is designed to accompany the entire product lifecycle of an asset and, depending on the respective phase, to provide corresponding services and benefits. In general, a DT focuses on the design, development, operation and decommissioning phases of assets [41]. DTs can be used to develop new products more responsively, better informed, and more efficiently. In addition to improved data feedback, early use in development provides a basis for collaboration between development and production and enables the synergetic integration of knowledge gained from production or operations into product development, which can lead to significant improvements in the quality of a product. With regard to production, DTs are considered capable of monitoring and controlling complex production processes in real time and optimizing the processes through timely adjustments [29]. Along the life cycle, DTs also promise benefits in operations and maintenance [15]. For example, researchers recommend the use of DTs in the aviation industry, where DTs are implemented to replace conventionally used methods of real-time monitoring to accurately predict relevant events. By integrating historic, fleet and sensor data and combining it with intelligent services, the prediction of aircraft life and fleet maintenance can be improved and facilitated [17]. However, these benefits in the operation and maintenance of an asset are not limited to the aerospace industry [18]. In additive manufacturing, for example, DTs are used to predict the cooling rate, temperature gradient, micro-hardness, velocity distribution and solidification parameter with increased accuracy to enable improved operation and predictive maintenance [17,18]. In addition to the use of DTs in industry, there are also use cases in the logistics sector, which have, however, been little researched to date. In logistics, the described ability of real-time monitoring enables real-time communication between products and different systems [16]. Based on the collected data sources, realistic performance indicators can be determined in real time, which contribute to targeted decision-making. DTs, thus, offer considerable potential in logistics [27]. In addition, DTs also provide added value for the operating resources used in logistics systems along their respective life cycles. Furthermore, DTs will play a central role in the realization of holistic asset management of critical rail transport components, as they build the basis for a CDE of the rail industry [36].

Regarding the life cycle of assets described before, the concept of DTs is of great importance. Due to the possible mapping of only a potentially real system or asset, i.e., a prototypical artefact, a distinction is made in DTs between digital twin prototypes (DTP) and digital twin instances (DTI) [42] (see Figure 2). The DTP is a DT that contains information records necessary to describe or create a physical system. These information records can range from simple parts lists to fully annotated 3D models. DTIs, on the other hand, are DTs that describe a specific real physical system. They can but not must represent the further development of a DTP and can vary arbitrarily in their characteristics regarding the information data sets [41]. Both DTPs and DTIs are operated and used in their environment, the DTE [9,42]. An example of a so-called DTP in rail transport could be a virtual prototype of a high-speed train such as the German Intercity-Express (ICE) 4, which could be used for operationally optimal research and development. The DTP is crucial here because it allows product developers to realize enormous cost and time savings while avoiding the consumption of resources and potentially dangerous situations [29]. Furthermore, DTIs can be designed to carry out simulations and derive recommendations for action or even make automated decisions [31]. With regard to increasing digitalization and the advancement of Industry 4.0 as well as the industrial IoT (IIoT), the interoperability of DTs, i.e., the ability to work together almost seamlessly, is becoming increasingly important [15]. This aggregation of DTIs is known as digital twin aggregation (DTA). It can be a computer construct that has an independent data structure and queries the DTIs either ad-hoc or proactively. In a visionary picture, a DTA of the German rail transport, including all its relevant assets, could proactively and continuously utilize data of different DTIs to enable a fully digital and optimized operation of the whole system [9] (see Section 5.2.3 and Figure 2).

2.3. Development of Systems

To secure problem-oriented DT development, the needs of people and organizations involved must be recognized and integrated, as it is with systems [17,25,42]. A system represents the purposeful sum of its components, which are used in an organized way to achieve specific functions. Hereby, the interaction and combination of the individual components as well as the interaction with its environment are crucial [21].

Regarding the development of systems containing software, a categorical distinction is made between technically computer-based and socio-technical systems. Technically computer-based systems consist of hardware and software components that do not contain processes and persons for the purpose-free fulfilment of functions [25]. Socio-technical systems contain one or more technical systems and, in addition, to define work processes, are characterized by the fact that there are dedicated persons who understand, monitor, and understand the system. Thus, these are systems with interactions between social and technical systems, so-called human–machine interactions. The work processes and responsible operators within the system are clearly defined [43]. The core of a socio-technical system is the technical system with the work processes. Socio-technical systems are mostly business systems that are designed to support the fulfilment of business objectives. Thus, the company’s policies, cultural values, strategies, and goals, as well as national laws and regulations, influence the procurement, development and use of the system. In this context, the system boundaries can be variable, as there are different views in science on the extent of the integration of corporate layers [25].

In the context of this work, the layered structure of socio-technical systems and DTs is understood to include all these levels. An example of socio-technical systems is a railway control system of railway undertakings, as it includes, in addition to the many hardware and software components of the technical system, indexed persons such as dispatchers who make decisions on the basis of the computer system [44]. Thus, it can be concluded that the corporate environment in which socio-technical systems are used has a decisive influence on the development process of the systems [25].

The term of systems-engineering (SE) is the basis for the development of such systems and defines its development processes. Due to the high system complexity, SE encompasses a multitude of activities consisting of specification, development, validation, deployment as well as operation and maintenance of the system [25,45]. These are developed considering the hardware and software characteristics as well as the human factor. Socio-technical systems can be classically divided into seven layers.

Table 1. SE influence on socio-technical system layers; source: own representation based on [25].

Socio-Technical System Layers	Systems-Engineering	Software-Engineering	Hardware-Engineering
Society	Focus	Non-focus	Non-focus
Corporate	Focus	Non-focus	Non-focus
Work and business processes	Focus	Focus	Non-focus
Application system	Focus	Focus	Non-focus
Communication and data processing	Focus	Focus	Non-focus
Operating system	Focus	Focus	Non-focus
Devices	Focus	Non-focus	Focus

illustrates the close interlocking of the SE within the different layers and reveals a holistic approach, since—contrary to classical software engineering—micro- and macro-economic as well as hardware-technical aspects are covered. Thus, the focus lies on the whole system and enables the inclusion of a wide range of system-specific factors, which makes the SE a suitable starting point for the successful GIS development [25].

Every system, whether it is real or virtual, has a life cycle. In the classical sense, a life cycle model represents the abstract and functional description of the conceptualization, realization, use, further development and decommissioning of a system. A system evolves because of actions. These actions are carried out and controlled with the use processes by those responsible for the system [21,25,46]. The SE described is supplemented by the IEEE 15288 standard (2015), which contains all processes of the SE and serves the successful realization of a system. The standard focusses on the early integration of stakeholder needs and required system functionalities to secure a problem-oriented solution development and validation. Thus, the standard provides a comprehensive and structured process for realizing DTs from conceptualization to decommissioning [22]. The standard contains four key process groups: agreements and contracts, organization and project enabling, technical management and engineering, which serve the successful system realization along its life cycle [22].

3. Development of the Generic Implementation Strategy

3.1. Methodological Fundaments of the Development

3.1.1. Structure and Rationale of the Approach

This work is methodically based on the design science research methodology (DSRM) for information systems research, as the methodology result—in literary accord—in a nominal procedure model as well as a mental representation model [47] aimed at successful development in information systems (see Figure 3). Its application was validated in the context of DTs, so it provides a suitable basis for the development of GIS for DTs [27].

Following its logic in step two, a qualitative content analysis was conducted to identify research needs [48]. Based on that, an analysis was executed to provide essential information regarding existing DT research characteristics and the determination of GIS requirements. The relevant papers identified were found in-between the research window from 1 January 2018 to 14 August 2020 using the scientific search engines Google Scholar and Science Direct as well as the particularly relevant search engine of IEEE Xplore [29]. Papers published before 1 January 2018 were deliberately excluded due to novelty in the field of DTs. The scientific publishers were elected due to their reputation and close relation to the theoretical foundations of a DTs. The search process followed the keywords digital twin, implementation, application, and strategy using the following search strings: digital twin and/or implementation and/or strategy and digital twin and/or application and/or strategy. The selected papers were chosen due to their close relation to the implementation or description of the implementation of a DT. Hereby, no research papers could be found that focus on the development of a detailed GIS for DTs nor on the implementation of a DT in logistics systems of German rail transport (see Figure 4).

Following the logic of the qualitative content analysis, a category system was derived both deductively and inductively. Based on the research questions of this work, the first upper and lower categories were formed deductively. Hereby, in the delimitation of the research project, the real-time monitoring was chosen as the use case and a physical-existing asset as the application object in the physical space of the DT. Based on this, the further breakdown and categorization was followed through the theory of Section 2 to build the non-functional categories. The functional categories are based on the stages and processes of the SE along its life cycle described in Section 2.3. In summary, twenty categories were developed deductively.

Due to research quality assurance, these categories were reviewed through examining the identified papers and supplementing the categories inductively if required. Therefore, a coding guide was developed and used as the central analytical tool (see Appendix A, Figure A1). With the exemplary text passages for the respective categories, it could be determined that, except for one category, corresponding examples exist in the evaluation units. Since the left-out category is a specific requirement from the research question of this work, it was retained despite the lack of an anchor example. The existing categories, therefore, did not need adaption.

Regarding the aspect of whether categories need to be added, it could be stated that the study by [17] is one of the few studies with a generic approach and the only study with a complete socio-technical system focus. It is also almost the only study to include the implementation environment and stakeholders in the process of developing a DT. In this study, this process is very closely aligned with the life cycle phases of the concept of DTs (i.e., design, development, operation, and decommissioning). Since this is in line with the stages of SE as well as the life cycle of systems mentioned in Section 2, another category, orientation along the life cycle phases of a digital twin, was introduced. However, it is also apparent from this study that, despite an orientation that makes sense for answering the research questions of this work, there is a lack of details on how the described implementation strategy of DTs can be implemented [17]. For this reason, a category named sufficient level of detail of the approach was introduced as well. The upper categories functional and non-functional proved to be useful due to the orientation of this work, as functional and non-functional requirements are also spoken of in classical SE. For this reason, they were retained as central superordinate categories. Through the content delimitation of the categories, four sub-upper categories were established, which are functionalities, use case, procedure, and SE.

The coding and evaluation of the research papers has shown that Zhuang et al. investigate the process of implementing a DT for the management of complex satellite production processes. In doing so, Zhuang et al. recommend a DT reference model and illustrate its implementation [49]. Zheng et al. develop a framework for implementing DTs in the use case of the product life cycle of production lines. They address the interaction of the real and virtual space as well as the connecting layer of information processing. They functionally structure these into data storage, processing and mapping, which forms the core of their DT framework [28]. Aivaliotis et al. recommend a generic approach to modelling DTs in the context of a case study on predictive maintenance of industrial robots [50]. Ma et al. focus on providing a DT approach for optimization and quality control within product assembly. In doing so, they recommend an implementation strategy for developing a platform that will serve as the basis for a subsequent DT application [51]. Lin and Low develop a DT system architecture for the practical implementation of a DT prototype in surface-oriented assembly. Hereby, the architecture consists of three functional layers: operation, visualization and information layers [52]. Jiang et al. focus on developing a framework for implementing DTs that meets the requirements of synchronous operation of production and logistics. In doing so, Jiang et al. aim at merging the services of DTs and product service systems, which focus on the manufacturing phase [53]. Bevilacqua et al. describe current technologies related to DT and recommend a reference model of a DT for process plants, which should serve the safety and risk management of its operators. In doing so, Bevilacqua et al. divide the reference model into four layers: industrial process layer, communication system, DT, and user layer. In their work, it should also be emphasized that the reference model developed does not have a socio-technical system focus, despite the explicit focus on the interaction between people and machines [54]. Barricelli et al. investigate the development of DTs in the context of manufacturing considering the socio-technical system focus for the first time and therefore clearly differentiate themselves. The central statement is that “to [their] knowledge, this aspect, which is crucial for a successful DT development, has never been identified and described by any state-of-the-art work” [17]. Due to the high system complexity of DTs, a socio-technical approach is essential for its realization. The inclusion of all relevant stakeholders of a DT, from experts to designers and decision-makers, is indispensable already during the development of the DT idea. This involvement must be continuous, collaborative and as early as possible in the design process. Along the life cycle, the process can adapt to changing requirements in advance, or to integrate aspects that are not yet known at the initial design of the DT at a later point in time. The socio-technical and collaborative approach can thus meet the diverse and complex requirements in the realization of DT projects. In this regard, Barricelli et al. underline: “The need to find new strategies to support such collaboration therefore becomes an open challenge” [17]. It can be concluded from this that there a current lack of GIS to realize this.

From this qualitative comparison of the research papers, it could be concluded that all papers use plan-driven processes of forward engineering to describe or implement a DT (see Figure 4). All works show similarities and parallels to the SE approach. Within the functional requirements for the GIS, the works are characterized by a strong focus on the technical design and development of a DT. Hereby, only one work on the application area of logistics and a few works on the recording, analysis and inclusion of the implementation environment and the stakeholders. This leads to the assumption that the existing papers have a rather specific character, which consider the implementation of a DT as an isolated technical process, as they do not include the socio-technical implementation environment. The non-use of socio-technical design can lead to the result of the implementation not serving the needs of the stakeholders and ultimately the users of the DT. For this reason, the usage is recommended, as it involves stakeholders along the development process in a collaborative and iterative way. This implementation aspect is also mentioned in the work by Sommerville (2018) as well as IEEE (2015). Likewise, the papers show gaps in a possible procedural alignment of the approach within the (non) functional requirements as well as the presence of an iterative and generic approach. Regarding the overall agreement of the categories of the category system, it can also be seen that a large proportion of the papers only have an agreement of 40 to 50 percentage points. The minimum is 35 percentage points and the maximum 53 percentage points. The weightings within the categories should also be seen as a reference and a benchmark for the development of the GIS. In summary, it can be emphasized that no approach for a DT GIS was identified, that specializes in logistics application or the German rail transport. This research need further justifies the relevance of this work.

To guarantee an accurate GIS development in Step 3 of Figure 3, the functional and non-functional categories of Figure 4 were evaluated in greater depth since they form the requirements for the successful GIS development. For this purpose, the following characteristics are considered: adequacy, completeness, consistency, comprehensibility, uniqueness and testability [55]. The defined requirements from Figure 4 are based on a comprehensive analysis of existing research on the implementation of a DT, and thus, completeness and adequacy can be concluded. Consistency is fulfilled by the clear separation into non-functional and functional as well as the individual description of all requirements. By embedding the theoretical foundations, and therefore creating necessary foundations for understanding, comprehensibility is fulfilled as well. The partly detailed description of the requirements and the theoretical foundations ensure that the requirements are unambiguous. Furthermore, the testability is given based on comprehensive research and analysis. Looking sorely at the GIS, it must, according to IEEE 2015:15288, give a description of its intended application as well as the processes included accordingly. In addition, relationships of the processes with their application as well as any secondary processes included must be described, which is also conducted in Section 4 [22]. In addition, no further specifications are made within the framework of the GIS with regard to the aspects of performance and quality of the implemented system, since the requirements focus on the processual procedure as such and not on the technical system to be implemented [55].

3.1.2. Model Objective and Approach

The objective of the GIS is to provide a targeted procedure for the practical realization of DTs in logistics systems of German rail transport, which fulfils the independently defined requirements from. The analysis of papers focusing on the implementation of DTs has shown that no paper is dedicated to the implementation of DTs in logistics systems. Furthermore, there is a lack of an implementation strategy that provides a detailed and generic procedure to support various DT implementation projects. If the claim of reproducibility is pursued, the strategy must not be limited exclusively to the documentation of a single DT project, as for example in the research papers by Zheng et al. (2018) or Jiang et al. (2020), because otherwise it can only be applied to a similarly specific project and thus lacks genericity. On the other hand, as shown in Section 2.3, DTs can be widely used in different industries and application fields. However, the value proposition of DTs varies greatly and results in different characteristics of DTs. The properties of DTs are therefore application specific. For this reason, the development of a GIS that covers all application fields and areas is not possible within the scope of this work.

Regarding the primary requirements of the GIS, further orientations as well as derived benefits of the development can be identified. The GIS should continuously involve relevant stakeholders at an early stage and thus contribute to a goal-oriented implementation. In a research paper on barriers to supply chain data analysis in logistics companies, Herden et al. emphasize the relevance of early integration of business interests and end users [56]. This socio-technical focus thus ensures that the strategy has sufficient stakeholder influence. Since changes can occur in the context of DT during the design and development process that are not foreseeable at the beginning of the design, an iterative procedure that also allows for changes in an already advanced development process is indispensable and a target component of the strategy [17]. Furthermore, the actual design and development of the DTs technical system remains fundamental and essential to the strategy. This was confirmed by all the papers analyzed.

In addition to the aspects described the orientation of the GIS is also limited by the non-functional requirements. Since the concept of the DT includes a physical and virtual space that are connected via IoT sensors and represents an IT system with the presence of hardware and software, the strategy is aligned with the SE. Furthermore, the already described socio-technical system focus and forward engineering is aimed at. These represent, derived from the SE as well as the examined reference works, the following phases: design, development, operation, and decommissioning. This work examines a DT for a physically existing asset. Therefore, the life cycle of the asset is relevant and thus justifies the orientation of the strategy to the DT life cycle phases. This interaction of the life cycle phases of physical and virtual world, is of crucial relevance for the GIS development. The GIS aligns itself with plan-driven and dedicated process steps that have the sufficient level of detail to implement DTs. This means that the processes run as a series of phases and iterations between the individual processes occur (see Section 2). Conclusively, due to their relevance, the entirety of the requirements described is examined in combination for the first time in the context of science by this work and combined into a holistic strategy. Through it, the development of the GIS is oriented in the best possible way based on science and practice to logistics systems under consideration of German rail transport and thus contributes to the further research and development of DTs.

3.1.3. Model Framework and Components

The framework of the GIS (see Figure 5) was derived from the theoretical foundations of Section 2 as well the qualitative content analysis in Section 3.1.2. Hereby, the reference process model of the IEEE Standard 15288:2015 was chosen as a fundament [22]. To apply this standard, it was tailored to the requirements of its application object, i.e., the research objectives of this work. Therefore, the adaptation measures derived are the relevant influencing factors, which are represented by the GIS requirements described in Figure 4. Secondly, relevant decision-makers and experts of the DB were included through explorative and iterative interviews. Lastly, it was determined that the development of the GIS, due to the resources available within the scope of this work, focus on the technical processes of IEEE 15288:2015(E) only [22]. Therefore, non-technical processes were only marginally dealt with in the context of this work, but their importance is to be noted. To meet the requirement of completeness, all relevant processes and aspects of the strategy were included in the GIS.

Conceptually, the GIS is oriented towards the life cycle phases of the DT as well as the corresponding asset. Within the GIS framework, a distinction is made between a GIS in the narrower and broader sense (see Section 2.2). Contrary to the existing scientific opinion, the decommissioning phase is also considered here in the context of GIS in the broader sense, since DTs have data and experience at their disposal when they are decommissioned, which can be relevant for future implementations [17]. Furthermore, the concept of a DT, which consists of the virtual and physical space as well as the environment of the DT, is crucial for the modelling approach. This results in three core components within the life cycle phases: the environment, the virtual and physical space. Derived from this, the framework of Figure 5 results as the model approach of the GIS.

3.2. Generic Implementation Strategy in the Narrower Sense

3.2.1. Phase 1: Design Phase

The life cycle phase of the design is used to design the DT prototype. Contrary to the use cases of DTs, where assets in the production industry are designed and developed with the help of DTs, the considered use case focuses on assets that already physically exist. The design of the asset is therefore neglected in this phase and is not considered further, so that the focus lies on the DTP and its DTE. Within this phase, the requirements for the DT are defined at an early stage to enable a targeted implementation.

With reference to Table 1 of the layered structure of socio-technical systems, the design of the DT begins with an analysis of the entrepreneurial environment in which the DT is to be implemented. This step serves to understand the entrepreneurial characteristics and is in line with the socio-technical system focus. In addition to the analysis of regulations and guidelines as well as the corporate strategy and mission, the focus primarily lies on the identification of concrete objectives and problems, or ultimately of operational challenges that serve to characterize the solution. When identifying the solution, it is essential that the solution is chosen based on the challenges and that the DT is not the predefined solution. This is important to ensure that the best possible optimizing solution is chosen for the existing challenges, even if the solution does not include the DT. To ensure the greatest possible objectivity, alternative solutions are also identified and compared alongside the characterized solution. This should serve to avoid the phenomenon of overengineering [16], which causes a non-beneficial technical playfulness due to an intrinsically over-optimal manner for technical perfection and quality [57]. The operationally optimal solution is then further specified with an initial operational concept, which provides information about elementary stakeholders, the expected life cycle, and the operational environment. This preliminary operational concept serves as the basis for the subsequent processes. Based on this, it is useful to conduct a risk analysis [54]. This process step could not be identified in its entirety in any of the research papers analyzed. Only Bevilacqua et al. mentioned that it is very important to understand the environment in which the DT will be used. This low occurrence may be related to the fact that the use cases and the environment in the analyzed works are already fixed, and the works have a very technical focused character, without the presence of a generic approach. Another important aspect is that the focus on operational optimization is not firmly anchored in some cases and thus the dedicated business analysis is not in focus. Nevertheless, the described fields of action and objectives of this first process are elementary for the implementation of a DT, as they enable the described operationally optimal solution finding and the identification of company environment-specific characteristics (see Figure A2).

After defining the business context and the operationally optimal solution, the next process step includes the identification of stakeholder needs related to the identified DT and its life cycle, what serves to prepare the DT requirements that will be placed on the implemented DT by the users and its environment. Regarding the stakeholders, there is a strong focus on the involvement of end users to ensure a user-centric solution. For this purpose, the operational system concept is specified, which shows possible interfaces and interactions between end users and the system to identify necessary needs and requirements. In order to overcome possible hurdles, as users do not have sufficient expertise for the technical design of the DT, methods of end-user development (EUD) design can be applied [17]. Once all stakeholder needs have been captured, they are translated into concrete requirements. This means that constraints are identified, and qualitative requirements are defined. Aspects of safety, health, insurance, or the environment may be relevant here. To enable a later verification of the defined requirements, the requirements are checked for their meaningfulness and specific evaluation criteria are defined. They serve the subsequent validation of the DT. Based on the defined requirements, systems or services are derived that are necessary for the further implementation process (see Figure A2).

Building on the previous process steps, the third process aims at defining the concrete requirements for the DT. For this purpose, the requirements defined by the stakeholders and user-centered approach are translated into technical specifications. This procedure is performed with the help of the operational concept and context of use defined in the previous step. Relevant requirements can be interfaces, data, data quality, system boundaries and components [17,28,49,50,54]. In addition to the requirements, constraints that could influence or hinder the implementation must also be recorded [17]. To enable a verification of the implemented DT solution at a later point, the requirements are also checked for their plausibility and corresponding evaluation criteria are introduced in this step. After the fields of action have been carried out and final DT requirements have been defined, an iteration with the identified stakeholders takes place to validate the requirements and subsequently select necessary systems and services (see Figure A2).

To meet the requirements, the DT architecture must be designed in the following process. Hereby, it may be necessary to develop different levels of detail regarding the architecture for different stakeholders [15]. To prepare the architecture design, the first step is to identify the critical drivers of the architecture, as they have a significant influence on the architecture itself [54]. This identification can be performed based on internal and external research and analysis. In addition, it is necessary to capture other constraints on the architecture. These constraints can be identified through stakeholders. Before the final architecture is defined, different architecture variants are designed and evaluated against each other. For this purpose, evaluation criteria are first defined and necessary systems and services for the design are determined. This process is followed by a design of different views of the architecture, which are used to identify possible architecture frameworks and models. These are rationalized and tailored to the context in which the necessary system context is defined in terms of interfaces and interactions of the DT with its environment [49]. The defined architecture units are adapted and tailored to the identified possible architectures. A connection of the architecture with possible DT designs follows [54]. For this, the final interfaces, and interactions of the DT with its environment are defined and the DT elements are connected to the architecture units to identify design characteristics. These characteristics are addressed in the fifth process. After the possible DT architectures have been designed, they are evaluated against the defined evaluation criteria to identify the architecture that best meets the requirements already defined. Once the best possible DT architecture is identified, the final views, models and descriptions of the architecture are defined. The core components and decisions of this process are recorded for management of this definition. Based on this, the explicit agreement of the stakeholders with the architecture is obtained to enable a later valid and verified implementation (see Figure A2).

In the following, the DT and its elements are further specified, in line with the architectural units defined in the previous process. To enable a successful implementation, design characteristics and enablers of the individual DT elements are identified and defined what includes the identification of necessary DT technologies and supporting services or systems. In the subsequent definition of the DT design, the defined requirements are assigned to the elements of the DT and the architecture characteristics are transferred into design characteristics. Based on this, design enablers are defined, i.e., aspects such as models or algorithms that support the definition. After all relevant design characteristics and enablers have been defined, it is checked which of the corresponding DT elements do not have to be newly developed but can be provided through reuse or acquisition of commercial-of-the-shelf (COTS) products. This requires a detailed assessment and evaluation (see Figure A2).

In the last process step of the design phase, an analysis of the designed DT is carried out, which is the basis for the technical understanding of the DT and the subsequent development of the DT. For this purpose, the objectives of the analysis are defined, a methodology for the implementation is identified and necessary services and systems are procured that are required for the implementation. Based on the analysis carried out, assumptions are made which serve to derive results and recommendations for action for the further course of DT implementation (see Figure A2).

3.2.2. Phase 2: Development Phase

The second life cycle phase serves to connect the real and virtual space, i.e., the transition of the DTP into a preliminary DTI. Referring to the concept of DTs presented in Section 2.3, the development of communication systems and DTIs is necessary for the connection of the virtual and real world [17,49,54]. To establish this connection, an implementation of the systems addressed is necessary.

In order for this to take place in a targeted manner, an implementation procedure is defined in this process step, which is based on the results of the previous processes. As described in Section 2.2, the strategy includes the decision whether the DT elements are implemented by means of forward- or re-engineering. Hereby, parts can also be provided and implemented by the already mentioned COTS products. Before the elements are implemented, it is advisable to identify any limitations that may occur with the chosen implementation strategy that may hinder the implementation. After the preparation is complete and all necessary resources are available, the DT elements and the communication system are realized in accordance with the implementation strategy. The focus is on the hardware and software as well as the services of the real and virtual world. Afterwards, an inventory is made of whether the realized DT meets the defined requirements (see Figure A2 and Section 2).

The next process step serves to assemble the DT elements into a DT that verifiably fulfils the previously defined DT requirements, architecture and design [50,54]. Before the DT elements can be integrated successively, the necessary services and systems for the process are provided and a procedure is developed. After integration, the interfaces between the elements, but also the relation to the environment, as well as critical quality features and functions are checked. This step is followed by a verification based on defined criteria and a final management of the process, which includes, among other things, the approval of the stakeholders that DT fulfils the defined requirements (see Figure A2).

Lastly, the developed DT is transitioned to its operational state, in which it can demonstrably provide the requirements and characteristics placed on it. For this purpose, the transition is prepared by various systems and services and then carried out. Once the transition has taken place, a demonstration of the DT’s functionalities follows. These are then confirmed by specific validation procedures and the stakeholders, so that the DT can move into its operational phase [54]. This validation and transition build the last process of the GIS in the narrower sense (see Figure A2).

3.2.3. Derivation in the Narrower Sense

After the components and the model approach have been defined in Section 3.1 and the individual process steps have been developed and specified, the GIS in the narrower sense is derived. In addition to the three core components, the essential process steps are listed in the GIS. Their structure and sequence are based on Section 2 and the results from Section 3. As mentioned, the supporting processes are not a core component and are therefore only of subordinate manner for the final GIS. In an implementation project, they must be considered and affect each lifecycle phase of the DT to be implemented. For example, the agreement and contract processes for the provision of essential systems and services and the procurement of COTS products must be reviewed at each stage. Following the guiding principle of sociotechnical system focus, the first two processes begin in the environment of the DT and pave the way for the design of the DTP [41], i.e., process steps three through six, until the designed DT moves into the development phase. Here, the focus is no longer on the environment of the DT, but on the interaction of the real and virtual worlds, i.e., the pre-DTIs and the IoT asset. The asset under consideration transitions into an IoT asset as the communication system is implemented in addition to the pre-DTI [41]. These systems and elements are assembled into a validated and operational DT later in the development phase. Within the processes, two to four and six to nine essential iterations must be performed between the processes to ensure that the ongoing processes meet the requirements and needs of the DT and its stakeholders as defined at the outset. In addition, the socio-technical system focus reflected in processes one and two creates the basis for a collaborative exchange between the system being developed and its environment. This explicit involvement is becoming increasingly important due to the increasing complexity of DTs and enables a targeted DT implementation that meets the requirements and needs of its environment [17]. Furthermore, the socio-technical system approach creates the opportunity to continuously adapt the DT based on changing user and environmental requirements. This enabled influence of the environment on the DT is essential not only in the design phase, but also later in the operational phase. The open and iterative design of the processes that enables subsequent system adaptations by the environment attempts to ensure the long-term value proposition of a DT, which ultimately serves the long-term achievement of operational optimizations and business goals.

3.3. Generic Implementation Strategy in the Broader Sense

3.3.1. Phase 3: Operation Phase

In a broader sense, as already mentioned, the consideration of the life cycle phase of operation and decommissioning can also be relevant for the GIS. The operational phase of the DT essentially consists of operation and use as well as maintenance and evolution. After an operationally optimal and validated state has been established in the previous process step, this process step serves the operation of the DT, and thus, the provision of the defined functions and services that serve the use and generation of operational optimization [17,49]. In detail, this means that before the operation starts, an operational procedure is defined on how the operational operation will be carried out. This can range from the planning of resources needed for operations to the definition of relevant performance operational criteria. In the preparation phase, constraints on operations are also captured, appropriate systems and services are provided, and essential training and operators for operations are identified and assigned. In the actual operation phase, the performance of the DT is recorded and monitored, which serves as the basis for any maintenance claims. Here, the DT, paired with its communication system of the IoT asset, unfolds its full potential and provides the services requested by it, such as the real-time monitoring of the IoT asset, for its stakeholders and other systems [54]. In other words, the DT enters into an exchange with its environment. Depending on the maturity level and use case, interoperable exchange with other DTIs, the DTA, can take place (see Section 2.3 and Figure A2).

The maintenance and evolution process step serves to maintain and ensure the functionality of the communication system and the DT. Maintenance work is carried out here based on planned maintenance and servicing measures or due to reduced performance of the DT identified during operation. For this purpose, a maintenance concept is created which, among other things, defines planning, preventive measures and necessary resources that serve the maintenance of the DT and communication system. In addition to classic maintenance, the evolution of the DT is also of crucial relevance, as it also ensures the continued operation of the DT. For example, stakeholder exchange or changing environmental factors can result in an adjustment of requirements, which have direct or indirect effects on the communication system or the DT [17]. To ensure the continuity of the systems, a corresponding evolution may be necessary (see Figure A2).

3.3.2. Phase 4: Decommissioning Phase

In the fourth and final phase, the DT is decommissioned. In addition to the actual technical decommissioning and the associated implications, other processes are relevant that legitimize the consideration of this phase within the development of the GIS. For this reason, the necessary process steps of the decommissioning phase are developed and specified in more detail below. In the context of the DT, decommissioning can occur when the IoT asset is no longer used due to its age or for another reason, or when the services of the DT are no longer needed. In the classical case, it is assumed that the IoT asset is no longer used what means that decommissioning is first prepared and carried out for the IoT asset and then for the DT [17]. In detail, this means the definition of a procedure as well as the identification of constraints and important criteria that fathom and enable the implementation. An important aspect is that the stored historical data of the DT is secured and made available to other DTs and stakeholders, as this use of the collected information and experience can form the basis for the development, use and optimization of future hardware, software, and DTs (see Figure A2).

3.3.3. Derivation in the Broader Sense

The GIS in the narrower sense is supplemented with the broader sense. For this purpose, the core results of the research conducted are derived and transferred. Here, too, the supporting processes of the implementation strategy are not a focal component. Nevertheless, they play a decisive role in the actual implementation of DTs and must, therefore, also be considered here. Accordingly, the following can be found on the left-hand side of Figure 7. In detail, there is a crucial exchange between DTI, IoT asset and DTE in both the operational and decommissioning phases. Within the operational phase, the exchange between IoT asset and DT ensures the provision of the services requested by the DT to its environment. Hereby, the exchange with stakeholders and especially with the DT users plays a central role, as well as, depending on the use case, the exchange with other DTs. This results in four process steps, which are marked numerically with ten. If maintenance or evolution is necessary, the two processes in Step 11 arise, depending on the system concerned. Due to the lifetime of the DT, this process step of maintenance and evolution can be carried out repeatedly, so that iterations arise between process Steps 10 and 11. If a need for adaptation is identified in Step 11, further components may need to be implemented, so that process step seven can be carried out again. If the result of a maintenance or planned evolution is that it is no longer appropriate to continue operating the DT for certain reasons, one moves on to process Steps 12 and 13. These two processes symbolize the respective system decommissioning. After decommissioning, a new exchange with the environment takes place, which includes the reuse or further use of (partial) components of the DT as well as the transfer of knowledge with stakeholders [17]. This can have implications for future DTs, which is why there is a link between process Steps 15 and 2 as well as 14 and 3 (see Section 4.2).

4. Validation in German Rail Transport

4.1. Methodological Principles and Application

The objective of the practical application of the GIS is to validate and correspondingly readjust the developed model where necessary (see Figure 3). To carry out this validation, semi-structured expert interviews were conducted in a single case study-based research [58]. Hereby, DT experts and decision-makers from DB were chosen and secondary corporate data sources from DB were collected. Subsequently, these data were analyzed and evaluated by means of a qualitative content analysis [48] and are being presented hereafter. The overall focus lied on the first four process categories of the GIS (see Section 4.2).

Within the German rail transport, DB must act economically and therefore make investment decisions based on the greatest economic benefit. The operational objective is to provide a reliable, attractive, and competitive service for its customers. Therefore, processes and assets must function and be protected, and disturbance variables, e.g., weather or vandalism, must be avoided and eliminated. Availability can also be ensured by replacement assets, which is financially expensive. Therefore, a solution is required that ensures that these challenges are met, whereby the planned and unplanned maintenance of the assets and their operations have the greatest benefit and need. Hereby, DTs provide the operationally optimal solution for DB, since they enable the provision of information, e.g., condition, history, inferences for the present and future, about assets and allow to map the interaction of different components relatively easily. This can optimize operations as well as planned and unplanned maintenance, what is no longer possible without data. The DT provides necessary data and, above all, condition data, which is indispensable, for example, for complex fault analyses as well as the analysis of the performance of assets. Dependencies of different systems and their mutual influence is very large and complex, so that it is often necessary to diagnose an entire system, e.g., a train, and not just a single component. For this purpose, all data of an asset must be brought together in a central place to carry out various analyses and identify interactions.

Due to the practicability and the relevance of maintenance, the use case of providing asset condition data from an existing ICE train asset was chosen, which is intended to optimize maintenance as well as operation. In this context, the DT becomes the hub for all data analysis and visualization tools through intelligent linking, evaluation and use of all condition-relevant data from operation and maintenance. The required data can partly be acquisitioned by the already existing control and monitoring systems (TCMS) of an ICE train, which connects subsystems with each other and enables the control and monitoring of these. Within this TCMS, there are nowadays nested bus systems due to hierarchical control levels, which are very complex, and its data are not fully accessible. This complexity poses a great challenge, as the bus systems are essential for data acquisition and processing. For example, the vehicle control unit has a lot of information and operating records. These data are held by the ICE manufacturers and is currently only partly available for DB. For these reasons, it is essential to consider from the beginning exactly which data are needed for the use case of the DT, because not all data can be acquired for economic reasons. Although it would be possible to obtain the necessary data from the TCMS by reprogramming the DB internally, this would lead to a comprehensive change at all control levels of the bus systems due to its complexity, which would entail a very expensive re-registration of the ICE train. Therefore, the acquisition of this data becomes the central challenge. Regulatory, organizational, and contractual aspects represent a greater hurdle than the necessary technology for the implementation, since the TCMS data could simply be provided via an interface without reprogramming. However, since modifications are to be made and the data have commercial value, data acquisition must be carried out in dialog with the manufacturers (see Figure 6).

For the DT to serve its goal of operational optimization of DB’s ICE train operations and maintenance, the DT solution must provide understandable and comprehensive data about the ICE asset as well as its environment through collection, storage, and provision. Hereby, the performance of analysis and linking data enables the provision of information that the ICE asset does not initially possess. To realize the DT, it is recommended to use a DT framework, an IoT platform, IoT analytics and systems that serve data processing, persistence, and provision. In addition, the use of modern and future-oriented system landscapes is recommended, as well as the integration of subsystems for the collection of environmental data of the ICE asset. It can also be useful to reuse DTs that already existed in the environment of the ICE asset or even for the asset itself. The inclusion of other DTs can be useful in some use cases and should be included in the design phase of the implementation strategy. However, it is recommended that for the success of the implementation for the ICE asset, it should primarily be limited to the exact use case. Hereby, it must be noted that a complete mapping of state data of the environment of the ICE asset is not realistic, and the generation of an operational added value is the top priority. The collection of all available data is also not recommended since it is often the case that data are collected, and it is assumed that it will already find the solution. Accordingly, it is important to identify the necessary data based on the defined solution. Finally, it is important to note that a central building block for the implementation of DT is the availability of expert knowledge and technical expertise. Particularly regarding the intelligent and standardized interfaces mentioned, the exchange with experts from industry is essential, as the interfaces require intensive specialist knowledge on the one hand and the desired establishment of standards cannot take place in isolation within a company on the other hand, as the claim and added value of DTs is the cross-organizational exchange in perspective (see Figure 2 and Figure 6).

4.2. Supplementation and Validation of the GIS

It was determined that the most important foundation of a successful GIS is the existence of a use case for DT. Hereby, the DT must represent the most operationally optimal solution after an objective evaluation of all alternative solutions, otherwise the implementation will lead to the effect of over-engineering. Furthermore, data plays a central role in the concept of DT and can lead to lengthy and cost-intensive processes in the context of German rail transport due to regulatory and contractual aspects. It is, therefore, essential for a timely efficient implementation to identify and characterize the necessary restrictions in the acquisition of data at an early stage to be able to initiate countermeasures within the agreeing and contractual processes at an early stage. As a result, the early identification and specification of necessary and relevant data are included as a field of action in the first and second processes. Furthermore, existing, or decommissioned DTs can provide useful insights that can be of value for the further course of implementation. The described practical complexity due to the already existing strategic projects can nevertheless be mapped by the GIS, as it represents a process model that shows relevant fields of action and process steps but does not call for a compulsory run-through of already existing content. The validation of the developed system was carried out by comparing the requirements defined in Section 3.1 and the evaluation of whether the GIS can be used in the practice of German rail transport. This assessment shows that the developed solution approach has an overall compliance with the defined requirements from Figure A3 of 91 percentage points. The lack of complete requirements fulfilment is because supporting processes, which reflect requirements seven to nine (see Figure A3), are addressed in the GIS, but due to the scope of the work no detailed inclusion has been made at this point. In addition to the content adjustments, the practical relevance and fit was also directly validated through the conducted expert interviews (see Figure 7).

5. Discussion

5.1. Implementation of Digital Twins Using the Generic Strategy

Through the review and evolution of the GIS, it was shown that the GIS can be applied in the context of a single case study. With reference to the theoretical foundations, it could be determined that the definition of DT necessary for the framework of this work is appropriate and corresponds to the practical understanding. The adoption of the SE approach and the IEEE Standard 2015:15288 as a reference basis for the development of the GIS seem to be proven as valid and practical based on the results. Through the additional combination with the socio-technical system focus, it was possible to develop a strategy that includes the environment of a DT early in the design phase to enable a targeted implementation. With reference to the SE and its process steps it has been shown that the inclusion of the decommissioning life cycle phase is not part of any existing research (see Section 3.1). Nevertheless, it was included in the context of GIS in a broader sense. The use of the term GIS, in the narrower and broader sense, was also addressed for the first time in the context of this work. The basis for this decision was the theory presented in Section 2 as well as the derived model approach in Figure 5. Due to the interoperable claim of the DTs as well as the requirement mentioned within the interviews that a DT needs to be able to evolve and adapt in an evolutionary manner, it became apparent that the inclusion of the operational phase within the GIS should be considered reasonable. It also became clear during the interviews that a DT should pursue the requirement of reusability for new IoT assets even after the corresponding IoT asset has been decommissioned. The DT can thus influence the design phase of new DT projects. Therefore, it can be concluded that it is of added value to consider all lifecycle phases from design to decommissioning when implementing a DT to enable a targeted and operationally optimal solution.

Based on the interviews conducted, it became apparent that it appears difficult to define clear boundaries between the individual processes, since aspects could already arise in the implementation of the first process that are only relevant in later process steps. In order not to lose sight of these aspects, but to still ensure a planned approach, early documentation can be useful. Since the interview guide was drawn up based on the objectives of the GIS, and can therefore, be assumed to be representative, one possible cause for this phenomenon could be that the content of the other processes was not sufficiently recognizable due to the isolated and independent questioning of the experts. Therefore, two recommendations for action can be useful for the practical application of GIS. Firstly, it is recommended that all stakeholders have the same level of information about what has been decided within the framework of the GIS, so that they can continue the strategy in a targeted and collaborative manner. This was not possible due to the research framework. On the other hand, it may be useful to store all information in a central place so that information can be shifted and maintained across processes what would also solve the question of the necessary documentation and make it possible for notes to be included. In this way, a uniform and plan-driven procedure can still be ensured.

In particular, the use of the socio-technical system has led to the analysis of the initial operational situation as well as the relevant national regulations and laws in the first step of the process. This seems to be of crucial importance, especially in relation to DB and ICE assets, as all interviewed experts have described regulatory constraints in the implementation of DTs. In addition, the early identification of stakeholders as well as the characterization of data requirements show that challenges can arise during the implementation strategy, which need to be identified and addressed at an early stage. This need was illustrated, for example, by the fact that the central challenge in the collection of relevant status data of an ICE asset in operation is not the technical feasibility per se. Rather, the central challenge is the acquisition of the data, since the necessary sensor technology exists, but it is not accessible to DB without costly reprogramming, since it is the property of the manufacturer. Moreover, the existence of a business outcome was identified as essential for the implementation of DTs. This can be attributed to the fact that the evaluation of DTs as a trend [12] can lead to an implementation in use cases where DTs are not necessarily the operationally optimal solution. This was also confirmed by the interviews and justifies the inclusion of the critical evaluation of alternative solutions in the first process step of GIS to avoid over-engineering and high data volumes. It can thus be concluded that in the application of GIS, contrary to its focus on DTs, it is first essential to critically question the actual use of a DT for the concrete application. Thus, it can be assumed that if a more suitable alternative solution than a DT exists, it is necessary to stop the implementation process to ensure an operationally optimal solution. In addition to the critical accuracy evaluation of fit of a DT, the data represents the central challenge. Based on various results, it can be concluded that the acquisition of status data of an ICE asset can only be conducted through a dialogue with the manufacturer due to contractual and technical constructs. For this reason, simultaneously with the initial use of a DT, it is important to question which data are needed and whether it can also be acquired indirectly via other components or systems than the sensor technology, which is difficult to access (see Figure 6).

With reference to the comprehensive research and analysis of practice-based research papers and activities in Section 3.1, it was found that Barricelli et al. are the first to address the relevance of the socio-technical system focus in the context of a DT implementation [17]. However, the analysis found that his work does not have the necessary level of detail to use the strategy as a reference model for actual implementation. Furthermore, no specific area of application, such as a focus on logistics systems or German rail transport, could be identified in the identified papers. It can, therefore, be concluded that this work has developed a strategy that has the necessary level of detail for the implementation of a DT in logistics systems of German rail transport for the first time.

5.2. Relevance for Science and Practice

5.2.1. Limitation and Need for Further Research

The GIS presented is used for the implementation of DTs, which represent assets in operation within logistics systems of German rail transport. Thus, the application is limited to assets that have already been developed and therefore physically exist. In the context of German rail transport and DB, for example, this means an operating signal box or an operating ICE train. Consequently, regarding Section 2.3, the GIS is limited to the implementation of DTPs and DTIs for existing assets. Thus, future research could focus on the development of a GIS for DTs used in the development of assets in production. The potential of doing so is also confirmed in the other papers [17]. In addition, the aforementioned work by Tao et al. provides a detailed overview of existing theories and research on the topic of DT use for product development [18].

Despite the necessary consideration of the described aspects, the research has shown that the implementation of a DT is elementary for the perspective interoperable exchange with other (sub-) systems. The work of Bevilacqua et al. confirms that and outlines further that to ensure interoperability between the DTs, several standardization issues, such as the synchronization of the physical asset and its DT, syntax and semantic interoperability needs to be addressed [54]. It has become clear that further research and development of standards is required and that this can only be conducted in dialogue with stakeholders and the industry. This dialogue is also of essential importance regarding the acquisition of data. Therefore, it could be concluded that in the considered use case, it is necessary to enter negotiating and contractual processes with the manufacturer at an early stage to obtain access to the relevant status data through a software update. However, due to the research framework, this was not explored in further detail and represents a starting point for further research work (see Section 4.1 and Section 5.1). In addition to the establishment of these standards and data property, there is also a need for organizational research and development at DB, as regulatory framework conditions prevent the free exchange of data between subsidiaries of DB. With a view to the technological results, it has also been shown that the use of individual technologies is shaped by and depends on the use case. Nevertheless, the use of cloud services, also with a view to interoperability, is to be considered elementary. Based on the results analysis, it was also possible to develop functional and non-functional requirements as well as a reference architecture for the DT of an ICE asset. In particular, the requirements obtained represent new findings for science and practice, as no suitable references could be found. These must be further researched and developed in the future.

Looking into the application of the GIS, it has been shown that the data collected during the research validates the solution approach. Still, the focus was on the first three technical processes of the GIS (see Figure 7). The processes four to fifteen as well as the supporting processes were not an active target component of the implementation and validation. Based on the results, it could be concluded that the interaction of technical and supporting processes during the implementation of DTs is essential, because as mentioned, such as the restriction of data acquisition and the contractual dialogue with manufacturers to be aimed for, are essential for the future implementation of DTs. Their application and investigation in further research, are therefore, recommended. This could lead to new insights into implementation inhibiting and facilitating factors that support the further establishment of DTs. With a view to practice, potentials were identified in which DT is promising in solving operational challenges. The existence of a comprehensive infrastructure within German rail transport as well as capital- and maintenance-intensive assets of DB reveal fields of application for DTs. Despite the identified euphoria for this promising concept, critical analyses are needed in the practical application to prove the actual clear solution power of DT and to ensure an operationally optimal solution. Rail transport has a lot of catching up required, compared to other industries such as the automotive or aviation industry, which already use DT successfully. Especially regarding the use of DT for the simulation-driven development of assets, there are many potentials. This is addressed in the context of DB with reference to the tendering procedures for new ICE trains (see

Table 2. Generalized working hypotheses of this work.

No.	Working Hypotheses
Conclusions on the developed GIS:
WH 1	VALIDITY ▪ “The developed GIS is practical and suitable for the implementation of DTs, which are to digitally represent assets of German rail transport that are in operation.”
WH 2	APPLICATION ▪ “No separable boundaries can be drawn in the practical application of the developed GIS. Thus, it may be useful to keep a list including all processes, which will enable the cross-process storage of relevant information at an early stage.” ▪ “The GIS can serve to create empirical values in the implementation of DTs. Based on these empirical values, representative GIS versions for individual asset groups can be established (i.e., DTs of ICE trains, DTs of railway infrastructure), which enable a standardized and targeted-oriented implementation of several DTs of the same asset group.”
Conclusions on the DT in German rail transport:
WH 3	USE CASE ▪ “For the implementation of a DT, there must be a specific use case for which the DT represents the operationally optimal solution. Otherwise, the implementation must be refrained from.”
WH 4	DATA ▪ “Data represents a central role in the implementation of a DT in German rail transport. Their requirements must be defined in an application-oriented manner, i.e., based on the concrete operational challenge.” ▪ “Transmission of real-time rail traffic data is not necessary in normal operations. They are limited to irregular cases such as fault clearance. Thus, some care is needed when using the term real-time with reference to DT. ▪ “Acquiring condition data of a train asset enables condition-based maintenance and forms the foundation for predictive maintenance.” ▪ “Acquiring data from a train’s TCMS is only accessible through dialog with the manufacturer, otherwise the train operator will face resource-intensive reprogramming and re-registration. Here, the creation of a win–win situation is necessary. In the future, this data access will be facilitated by a simplified ethernet-based TCMS.”
WH 5	DT LIFE CYCLE ▪ “From a current perspective, along the value chain of an asset, multiple DTs will exist.” ▪ “The introduction of DTPs in train tender processes simplifies the reconciliation of requirements immensely and has the potential to serve as the basis for the DTI of the developed train within its operational phase. Furthermore, the inclusion of DT standards within tender procedures creates the potential to establish generally applicable standards in rail transport. With a view to other industries, there is a need for action in this regard.” ▪ “The use of DTPs, which were used for the design and development of a train, can be profitable for the implementation of a DTI.”
WH 6	INTEROPERABILITY and STANDARDS ▪ “The interoperable operation of DTs (DTAs) requires not only technical standards but also a situationally adapted organizational structure, since the regulatory framework of German rail transport makes interoperable exchange difficult.” ▪ “Within the implementation of DTs, a bundling of activities is needed to ensure a common thrust. This is indispensable for the ability to operate interoperable.” ▪ “Establishing DT standards can only be done in dialogue with stakeholders as well as industry.”
WH 7	PARTNERSHIPS ▪ “In the context of DT research and development, participation of (inter-)national rail transport companies in consortia are recommended. Here, the initiation of a rail transport-specific consortium can be useful.” ▪ “In the context of digitalization, rail transport can use empirical values from other industries, for example with reference to the simulation of capital-intensive assets.”
WH 8	DT VISION ▪ “Achieving the goals of a digital rail system requires modern systems and approaches. In this context the DT, due to its intended interoperability, provides a unique opportunity for data management as well as the connection of promising services, such as the creation of networked and complex analyses and simulations of different (sub-) systems. These serve to increase the reliability and availability of rail transport fundamentally.”

).

In these procedures, requirements engineering for the tender is done by DB, as it sets the requirements for the asset to be developed. Within an interview, the relevance of simulation-driven and iterative exchange between manufacturers and operators was outlined, as this enables targeted development on the one hand and efficient matching of requirements on the other. It is, furthermore, a concept that is already a standard in other industries. The rail transport lags behind here, as requirement documents are only a written representation and it is difficult to ensure this atomicity, when each requirement is checked for fulfilment manually. This leads to ineffectiveness and room for interpretation, which results in high resource costs and project delays. Therefore, a logical conclusion is to check whether, in future, tendering procedures of cost-intensive assets, a kind of DTP exists between manufacturer and operator, which makes the design and development more attractive by creating a win–win situation for both parties. One possibility for DB would be to include an initial DTP in the award procedure when the asset is put out to tender, which on the one hand receives the necessary requirements that correspond to the operationally optimal and desired parameters of future rail operations based on the simulation and on the other hand already contains standardized interfaces and parameters. The aim of this procedure for all manufacturers would be to submit their offer including the further developed DTP, which would reflect the iterative further development of the asset on the one hand and the basis for a DTI in the operational phase of the asset on the other. The standards defined at the beginning would ensure interoperability and reusability for DB. This possible solution represents a set screw for a more efficient and operationally optimized award process for DB as well as a more digital railway operation in the future. Its further investigation in practice is therefore recommended (see Table 2).

5.2.2. Generalization of the Core Results

The generalization of the results serves to theoretically abstract the findings and give readers of this work the opportunity to critically engage with the results. The goal of generalization is to formulate hypotheses that can be tested by subsequent studies [59]. Thus, the working hypotheses for German rail transport, based on the analyzed results of the DB AG single-case study, are reflected in Table 2.

5.2.3. Importance of Strategic Partnerships

Due to the interoperable claim of DT, the existence of standards is indispensable for technical feasibility. For this reason, many industry partners, and companies within consortia such as the digital twin association or the digital twin consortium are focusing on bundling research activities and establishing standards. Through the results of this work, the acquisition of data and the establishment of standards was identified as a central challenge in the implementation of DTs within DB. For this reason, it seems to be a logical conclusion that companies from the German rail transport participate in the described initiatives to represent interests and possibly establish standards. The initiation of an own consortium with supra-national rail transport partners could also be a solution to jointly research DT and create an industry-specific platform to investigate specifics such as regulatory restrictions in rail transport companies regarding DT. By joining forces, the consortium would potentially combine its bargaining power with manufacturers to enforce standards within rail transport. In addition, the promotion of the DT-based tenders described above could be a strategic field of action for the consortium. It could also make sense to make use of the experience of the aviation industry, which is playing a pioneering role in the use of DTs. Moreover, a corresponding consortium could serve in the discussion of new developments, such as the train-as-a-service business model introduced by Hitachi Rail for the first time in rail transport [60]. The described cooperation of different stakeholders is becoming increasingly important, especially regarding the interoperability of DTs. The aforementioned vision of DB, to be able to digitally represent the entire railway world in order to enable simulations and experiments [12], requires cross-organizational DTAs (see Figure 2) and further research into organizational and technical aspects in order to overcome regulatory restrictions and establish standards.

In addition to these aspects, a uniform procedure is also highly relevant to enable the targeted establishment of DTs and not to have several individual DTs that have been developed based on diverse interfaces and can thus only be assembled through resource-intensive reprogramming.

5.2.4. Significance of Data Sovereignty

In the context of the implications described, the commercial value of data and its relevance in optimizing operations and maintenance was described (see Table 2). It was shown that in the context of German rail transport, the legal legitimization of the use of data often lies with the manufacturers (see Section 3.2 and Section 5.1). Due to currently valid contracts, it is difficult for DB to change this fact without creating a positive situation for all parties. This phenomenon of data sovereignty can also be observed in agriculture, where, for example, farmers are restricted in the use of the data of the agricultural machines they operate. The machines they have purchased collect a lot of data. However, this data is not accessible to them, as its use is in the custody of the manufacturers of the machines. Within their business models, the data becomes a central component, as it has immense economic value. With reference to the presented problem of DB and its ICE assets, the same problem arises for farmers [61]. Data sovereignty thus seems to be a central challenge not only for rail transport. For this reason, it is recommended for operators to include the legal use of the data collected by the acquired and operated asset as a central element in future contractual negotiations.

6. Conclusions

6.1. Summary of the Results

In the context of the logistical management of the sparing use of resources and the increased transport and traffic volume, the need for coupling real and virtual worlds has increased in recent years, as this interaction promises new business innovations and the optimization potential. In addition to the virtualization of realities, rail transport is becoming increasingly important as it enables resource-saving transport and traffic. To successfully meet the challenges described regarding German rail transport, the federally owned railway group DB has adopted the group strategy strong rail. For this strategy, digitalization and technology have become the decisive key, which justifies the relevance of DB’s digital and technology strategy. In the context of science and practice, the potential of the DT concept was recognized, which should help to solve operational challenges. As this is a new concept, there are many challenges, such as the way in which DT is implemented, which need to be solved to realize its full potential. Therefore, the goal and research question of this work was to develop a strategy that would serve as a reference for the future implementation of DTs.

The systematics of this work was based on the DSRM research methodology shown in Figure 3, which serves the successful development of representation models in information systems. As a result of the work, the following aspects can be summarized, which furthermore fathom the answer to the research question:

• GIS: target-oriented behavior and combination of measures for the generally valid implementation of DTs; focus on forward engineering as well as plan-controlled process steps.
• DT understanding: the virtual system platform is a physically correct digital representation with very high fidelity of the physical system platform; the overarching goal is the concrete provision of services in the DT environment which serve the operational optimization of the asset under consideration along its life cycle.
• Theoretical foundations: use of the SE approach and its life cycle processes according to IEEE Standard 2015:15288; integration of a socio-technical systems focus.
• Validation of the GIS: conducting qualitative expert interviews in a single-case study design on the application of the GIS; reviewing the specially developed GIS requirements and evolution based on the findings
• Model approach: inclusion of four life cycle phases within the GIS; in the narrower sense the inclusion of design and development and in the broader sense the operation and decommissioning; focus on assets that already exist and the DT and its environment in the context of the socio-technical system focus.
• Components: 15 dedicated technical process steps in the process model; nine in the narrower and six in the broader sense of GIS; plan-driven relationships and coupling of real and virtual (environment) world.

The results obtained demonstrate the validity of the assumptions made as well as the practical applicability of the developed GIS. Furthermore, this work has provided important and novel insights as well as practical implications for the promising use of DTs (e.g., see Figure 6 and Figure 7 and Table 2). In this context, for the practical success of DTs, it is particularly important to emphasize that the DT must solve a specific use case for which it represents the operationally optimal solution. The definition of data requirements must be application-oriented and pragmatic, as data are a key challenge in the implementation of DTs. For example, indiscriminately collecting data in real time to optimize operations and maintenance was identified to be not goal-oriented or operationally optimal (see Table 2). Furthermore, it can be generally stated that the interoperable exchange of different DTIs requires a cross-company approach to develop and establish standardized or self-learning interfaces as well as open organizational structures. The technological maturity as well as organizational and regulatory frameworks hereby determine the progress of DTs. To achieve this, participation in consortia and the possible initiation of partnerships and working groups between national and international stakeholders is considered essential (see Section 5.2.3).

The research objective of developing a GIS in logistics systems of German rail transport was fulfilled within the framework of the qualitative-explorative research design (see Section 3, Section 4 and Section 5 and Figure 3). Based on the single case study design at DB, concrete results were obtained for the implementation of a DT for the transmission of timely status data of an ICE asset. The findings provide information about relevant requirements for the DT as well as its architecture and design, which form the basis for defining an implementation strategy for the considered use case (see Figure 7 and Table 2).

Concluding it can be stated, based on science and practice, that the developed solution approach represents a first-time and novel scientific result for implementing DTs in logistics systems of the German rail transport.

6.2. Outlook

DTs offer diverse and novel fields of application in logistics systems of German rail transport, whereby their relevance has been confirmed in other industries already (see Section 2.2). Since DTs pave the way to the vision of a digitally networked rail transport operation that enables complex analyses and simulations of interactions and effects of decisions, further research and application is needed (see Section 5.2.3 and Section 5.2.4 and Table 2).

In this context, finding regulatory frameworks and technical standards that enable interoperable operation of DTs in a DT network (DTA) are a major implementation hurdle of DTs (see Figure 2). Due to the sheer complexity and necessary consent of many stakeholders, the exploration within strategic partnerships of sufficient size that have the power to establish standards, is highly recommended (see Section 5.2.3).

In addition, data are an increasing challenge in the realization of DTs. Current regulatory and contractual frameworks make data sovereignty difficult for system operators. Corresponding parallels were shown in other industries (see Section 5.2.4), leading to a potential conflict in the use of operational data. This area of conflict must therefore be addressed by for instance changing historical contractual structures (see Table 2).

Regarding the developed GIS (see Figure 7), further research is recommended as well. The GIS can be applied to already existing and operating assets. Hereby, the extension to assets that are still under development (DTP) was identified as promising (e.g., in the inclusion in tenders and developments of ICE trains) should therefore, be pursued (see Section 5.2.1). In addition to the described strategic bundling of DT activities (see Table 2), which enable a standardized and future-oriented GIS application, subsequent research should focus on validating and evolving the developed GIS in a multiple case study design. It can serve to identify correlations between technical and supporting processes as well as to create empirical values in the implementation of DTs. Based on these empirical values, a GIS of individual asset groups, such as ICE trains, can be enabled. In the long term, it thus, contributes to the standardized and targeted evolution of DTs and the operational and environmental improvement of the German rail transport.