Design Principles for Shared Digital Twins in Distributed Systems

The first approach involving a Digital Twin originates from NASA’s early Apollo space projects. Within these projects, an identical version of the space capsule remained on Earth for test purposes during the mission (Rosen et al. 2015). However, this is not a Digital Twin by today’s understanding, as it lacks a virtual representation. The first mention of a Digital Twin by Professor Michael Grieves stems from the year 2003, who introduced the concept of the Digital Twin in a lecture on Product Lifecycle Management (PLM) (Grieves 2014). Therefore, Digital Twins have essentially emerged from PLM according to the original understanding. The most frequently cited definition to date is provided by Glaessgen and Stargel (2012). It describes the Digital Twin as "[…] an integrated multiphysical, multi-scale, probabilistic simulation of a vehicle or system in its current form, using the best available physical models, sensor updates, fleet history, etc. to reflect the lifetime of the corresponding flying twin" (Glaessgen and Stargel 2012, p. 7; Karakra et al. 2019). This definition includes essential aspects that characterize a Digital Twin. However, it is necessary to examine Digital Twins in more detail to enable a holistic investigation.

The Digital Twin concept primarily focuses on providing data in a structured and semantically described form over the lifecycle of an asset (Glaessgen and Stargel 2012). The knowledge of the Digital Twin expands with the corresponding life cycle of the respective asset and thus, ideally, has a complete digital representation of all sensor and operating data, master data, and all relevant documents and CAD models (see Fig. 1). That distinguishes the Digital Twin concept from comparable approaches in the field of Big Data applications, such as Data Lakes or Data Warehouses. A data lake is “a large, raw data repository that stores and manages all company data bearing any format” (Sawadogo and Darmont 2021, p. 98). In contrast, a Data Warehouse “is generally understood as an integrated and time-varying collection of data primarily used in strategic decision making […] It is essentially a database that stores integrated, often historical, and aggregated information extracted from multiple, heterogeneous, autonomous, and distributed information sources.” (Hüsemann et al. 2000, p. 1). A Digital Twin combines both concepts as a data repository and uses these as an additional data source (Al-Ali et al. 2020). In contrast to previous database systems, users of Digital Twin have the advantage of possessing direct access to all relevant data of a specific asset without the need to search intensively. That leads to significant benefits such as reduced costs, innovation promotion, higher reliability, and easier decision-making (Jones et al. 2020). In this context, the taxonomy of Digital Twins by van der Valk et al. (2020) provides a comprehensive overview of the fundamental conceptual building blocks of Digital Twins. It bases on the analysis of 233 publications and illustrates eight essential dimensions and 18 characteristics of a Digital Twin (see Table 1). The following section bases on van der Valk et al. (2020).

The dimension Data Link is divided into the characteristics one-directional and bi-directional and describes the data flow between the Digital Twin and its physical counterpart. The dimension Purpose includes the characteristics of processing, transfer, and repository and defines the primary functions of a Digital Twin. Conceptual Elements is another dimension of Digital Twins and refers to the connection between the Digital Twin and its physical counterpart, either physically independent or physically bound. The dimension Accuracy specifies the level of detail of the Digital Twin concerning the respective physical counterpart and consists of the characteristics identical and partial. The dimension Interface consists of M2M and HMI characteristics and refers to the form of data transmission of a Digital Twin. Synchronization distinguishes between the characteristics with and without synchronization and describes the chronological alignment between the Digital Twin and the physical counterpart. The dimension Data Input outlines the various data formats that a Digital Twin must integrate and process and is therefore divided into raw and processed data. The dimension Time of Creation addresses the time of the actual instantiation of the Digital Twin in relation to the corresponding physical counterpart and consists of the three characteristics: physical part first, digital part first, and both simultaneously. Here, the individual characteristics are either mutually exclusive or non- exclusive.

The taxonomy shown in Table 1 provides the conceptual basis for developing the design principles for Shared Digital Twins, as it allows for a structured mapping of the principles identified. Furthermore, in the further course of this publication, it needs to be clarified whether the mentioned dimensions and characteristics of the taxonomy sufficiently represent the concept of the Shared Digital Twin. An important basic idea regarding the utilization of Digital Twins is an accurate mapping and description of processes and operations from the actual operating world (Weber and Grosser 2019). Due to this conceptual feature, a Digital Twin makes it possible to provide these data as a gateway to other actors within a cross-company network. However, a vast majority of Digital Twin applications still remain within a company (Weber and Grosser 2019).

According to Longo et al. (2019), Digital Twins are particularly suitable for cross-company use in horizontal integration to prevent information asymmetries along a value chain. However, the topic of Data Sharing via Digital Twins has received little academic attention. Compared to the steadily increasing number of Digital Twins publications, the description of a cross-company use of Digital Twins occupies only a small part of the research area (see Table 2). For example, Ramm et al. (2020) describe Digital Twins as central platforms for collaboration. Furthermore, Uhlenkamp et al. (2020) investigate different levels of cooperation enabled by a Digital Twin. They conclude that Digital Twins, especially in combination with platforms and cloud hosting, only reach their full potential through cross-company use. In this context, Wang and Wang (2019) address, among other aspects, individual life cycle phases of a Digital Twin. Compared to Ramm et al. (2020) and Uhlenkamp et al. (2020), Wang and Wang (2019) describe a different form of cross-company data exchange since they address the transfer of ownership associated with the various life cycle phases. Most of these publications focus only on conceptual ideas, without showing concrete design approaches for this instance of Digital Twins. Although these publications provide valuable insights and initial ideas for the collaborative use of Digital Twins, they provide descriptive knowledge. They do not yet offer any prescriptive design approaches. Besides, most contributions do not include perspectives and views from the industry.

Based on these aspects, we consider a Shared Digital Twin to be a specific instance of a Digital Twin, enabling the sharing and integration of data in multilateral and cross-company networks. The aim is to share data from the individual lifecycle phases of an asset across company boundaries and, at the same time, to enrich the Shared Digital Twin with data from external organizations. Accordingly, in this case, the aim is to embed a Digital Twin in a distributed system. A distributed system is a “collection of autonomous computing elements that appears to its users as a single coherent system” (van Steen and Tanenbaum 2017, p. 2). In this context, distributed systems are characterized by the design goals of sharing resources, transparency, openness, and scalability (van Steen and Tanenbaum 2017).

These design goals directly impact the design of Digital Twins when deployed in a distributed system. That means that in resource sharing, the Shared Digital Twin must be able to provide submodels of the twin to the relevant participants. In the context of transparency, a Shared Digital Twin must supply the respective users with a complete overview of the shared submodel. Regarding openness, a Shared Digital Twin requires standardized subelements that enable the respective participants to access the elements of the Digital Twin without barriers. The scalability property of a Shared Digital Twin makes it possible to easily expand the number of potential participants. Therefore, the design goals of distributed systems have a direct impact on the design of Shared Digital Twins (see Fig. 2) and influence the design of the necessary functions that a Digital Twin must fulfill in a distributed system. In this context, Shared Digital Twins differ significantly from internally used Digital Twins and common inter-organizational information systems.

In relation to Digital Twins which are solely used internally, Shared Digital Twins differ in those requirements that arise due to the integration of various cross-company actors. The characteristics shown in the taxonomy primarily emphasize aspects that describe the relationship between the Digital Twin and the respective physical counterpart. Especially concerning the design goals shown in Fig. 2, Shared Digital Twins require greater consideration of interoperability and data security aspects. Both aspects are rarely considered in the context of the literature on Digital Twins and are at best described as a possible requirement (see Halenar et al. 2019, Jones et al. 2020 and Tao et al. 2019a). The use of Shared Digital Twins raises questions about data ownership in particular. Despite using the Digital Twin in a distributed system, the data owner must always be able to retain sovereignty over the data. These conceptual shortcomings of Digital Twins which are solely used internally need to be avoided and overcome when designing Shared Digital Twins.

Compared to standard inter-organizational information systems, Shared Digital Twins enable the collaborative use of the machine and operational data. In general, inter-organizational information systems are systems “that involve resources shared between two or more organizations” (Barrett and Konsynski 1982, p. 94). The data sharing described here goes beyond the standard data exchange in Electronic Data Interchange (EDI) and especially considers a collaborative aspect where, for example, new business models create additional values (Otto et al. 2019b). In the case of a Shared Digital Twin, this additional value is particularly evident in the fact that a holistic view of the asset over its entire lifecycle, including a complete semantic description of the data, is possible. Thus, it allows for the sharing of data that describes the behavior of an asset and therefore enables deep insights into its processes.

Our research generates design principles for Shared Digital Twins. As our data resides in the field, i.e., in the experiences of industry practitioners, we opted for a qualitative study with expert interviews. Qualitative studies are a common methodological approach when generating design principles before artifact instantiation (Möller et al. 2020b). Design principles, per se, are the formalization of prescriptive design knowledge (Chandra et al. 2015) and are a part of the theory of design and action (Gregor 2006). In that sense, design principles are not a traditional, material artifact (see March and Smith 1995), but an abstract meta-artifact that assists their users in designing artifacts more efficiently (Iivari 2003; Vaishnavi et al. 2004).

Our study consists of the four steps aggregated and proposed by Sarker and Sarker (2009). First, we started the study by identifying relevant industry experts from practice through immediate channels of senior personnel (similar to the ‚known sponsor approach ‘ (Patton 2002)). Weinstein (1993) distinguishes between epistemic and performative expertise. An expert with epistemic expertise is “a person who is capable of providing strong justifications for a range of claims in a domain” whereas a person with performative expertise “is able to perform a skill well according to the rules and virtues of a practice” (Weinstein 1993, p. 71). Within the scope of this study, we include experts with both epistemic and performative expertise. This results in a broad distribution of experts who have been responsible for or involved in both the actual implementation of Digital Twins and the planning and projecting of activities in this context. Furthermore, throughout the study, we used the snowball method or chain reference sampling, identifying additional suitable contacts for the study with help of the interviewees themselves (Biernacki and Waldorf 1981). To ensure a common understanding of relevant terminology, we asked a question regarding basic knowledge of Digital Twins at the beginning of each interview, allowing for a better classification of the answers.

We contacted each candidate with an invitation and a corresponding short presentation of the research project. Following the advice of Sarker and Sarker (2009) we retained flexibility and considered the interviewees’ restrictions for finding a suitable date. As the interview study was done during the COVID-19 global pandemic, all interviews were held remotely. The interviews were always conducted with a colleague so that there were always two interviewers and one interviewee in each interview. After we had collected the data, we followed the general principles of Grounded Theory to analyze the data qualitatively. As design principles are part of design theory and Grounded Theory, explicitly, it is a methodological approach to generate theory from all types of data. Thus, after formulating the design principles for Shared Digital Twins, we followed the recommendations of Iivari et al. (2020) and conducted interviews for evaluation with a smaller set of experts to validate our findings and stress test them for theoretical saturation. The aspects mentioned here are summarised in Fig. 3.

We opted to split data collection dichotomously into two phases. The first phase collected data that we used to generate the results, i.e., the design principles. That phase entailed a significant body of expert interviews (n = 15). We interviewed another set of experts (n = 3) in the second phase to evaluate our findings.

The interviews were designed as semi-structured interviews with open questions to enable the experts to express their opinions freely. We chose a semi-structured interview as it provides a checklist of content that one needs to address to make the interviews comparable, yet, it also leaves enough freedom to react flexibly depending on the interviewees' answers (Merton and Kendall 1946; Myers and Newman 2007; Patton 2002). The interview guide is structured threefold. The first set of questions was meant to break the ice between interviewers and interviewees by asking personal questions about their backgrounds (Myers and Newman 2007). Next, the second set of questions aimed at uncovering requirements, principles, and general information on collaborative Digital Twin implementation. In that regard, the questions drew from the taxonomy of Digital Twins as proposed by van der Valk et al. (2020) and used the design dimensions as conceptual borders and as flexible starting points for inquiry. Lastly, concluding questions left the interviewee with the possibility to add any issues that might not have been addressed and gave space to comment on any topic freely. The interview guide itself was designed within the research group and created in multiple iterations.

We collected data for about four weeks with 15 industry experts to generate our initial design principles. Additionally, we had three interviews with experts in the second data collection period to evaluate our findings. The interviews lasted between 42 and 66 min for the design phase and between 39 and 51 min for the evaluation phase, with an average duration of 52 and 43 min. The notion of Digital Twins is strongly driven by industry practice. In this context, Table 3 shows the composition of the interview partners in terms of their positions, industry sectors, and the respective interview durations. Naturally, all interviewees were guaranteed to stay anonymous.

As Digital Twins are an essential object of manufacturing analysis, we selected most interviewees from mechanical and electrical engineering (Enders and Hoßbach 2019). We aimed for a well-balanced distribution of interview partners across industries to mitigate industry biases, including logistics, telecommunication, and chemical industry experts. The main aim was not to limit the data collection to a specific industry and to select interview partners who were involved in digital transformation processes or had decision-making powers on the use of new digital technologies.

We transcribed the audio data fully, intending to leverage the maximum engraved information, which would hardly be possible by relying only on notes (Lapadat and Lindsay 1999). Also, transcribing is the first step when going in-depth into the data (Ochs 1979). Naturally, having the complete textual documentation of each interview makes the process of coding the data, i.e., attaching descriptive labels to portions of the data, more meaningful (Saldaña 2013). We used the software tool for qualitative data analysis MaxQDA both for transcription and coding.

The division of the contents along the four thematic blocks of the interview guideline allows a rough first structuring of the relevant contents. Nevertheless, the interview partners may already anticipate the contents of a subsequent thematic block. Therefore, coding is of importance in the context of data evaluation. Regarding the derivation of design principles for Shared Digital Twins, content-coding primarily involves identifying dimensions and characteristics beyond purely internally used Digital Twins. Especially in IS-Research, Grounded Theory often describes new technologies in emerging research areas (Birks et al. 2008; Urquhart and Fernandez 2006; Wiesche et al. 2017).

In the course of the evaluation, the authors decided to use selective coding. This type of coding differs slightly from the usual Grounded Theory methods, as the researcher defines some codes in advance to data analysis (Blair 2015). In the context of this research project, template coding is particularly well suited because the coding adapts to the dimensions of the taxonomy of Digital Twins by van der Valk et al. (2020). In the sense of Urquhart and Fernandez (2006), the authors do not consider the use of template coding as a deviation from pure Grounded Theory Methodology, but rather as an adaptation in the sense of a flexible approach that considers prior existing research.

Design principles are constructed linguistically as prescriptive statements for action. They require structure in how they are formulated. The literature provides some templates for design principle formulation (Cronholm and Göbel 2018), (e.g., see Goldkuhl 2004 or van Aken 2004). We chose to adopt the template proposed by Chandra et al. (2015), as, next to linguistic guidance, it also gives underlying conceptual advice on building blocks of design principles. The template is as follows Chandra et al. (2015):

“Provide the system with [material property – in terms of form and function] in order for users to [activity of user/group of users – in terms of action], given that [boundary conditions – user group’s characteristics or implementation settings].”

Per se, design principles must address a class of artifacts rather than one instance (Sein et al. 2011). Thus, before formulating design principles, one must derive meta-requirements for an artifact that apply to a class of artifacts (Walls et al. 1992). The coding itself focuses on the taxonomy dimensions shown in Table 1 and follows template coding, meaning that some codes are already defined before the study (Blair 2015). At the same time, however, we paid attention to characteristics beyond these taxonomy dimensions extending the initial literature-based findings. Table 4 provides a sample of codes that are not part of the taxonomy but are nevertheless mentioned repeatedly by the interview partners. In this context, the use of the taxonomy forms the theoretical lens.

To ensure that no design principle is without purpose, each design principle must address at least one meta-requirement (Goldkuhl 2004). Eliciting meta-requirements from interviews and generating responsive design principles that address them is a typical avenue for design principle generation (Möller et al. 2020b) (e.g., see Niemöller et al. 2019 or Feine et al. 2019). Following the advice of Koppenhagen et al. (2012), we applied logical content aggregation to synthesize meta-requirements to key-requirements to ensure that the resulting design principles actually address issues of high importance rather than a broad spectrum of particular problems (see Fig. 4). Additionally, that provides the benefit of limiting the number of design principles, which helps cognitive understandability (Miller 1956).

Following Pratt (2008) and the notion of ‘power quoting,’ we include illustrative excerpts from the interview transcripts throughout the presentation of the design principles to substantiate our findings. These power quotes are suppoed to be extraordinarily significant and catchy, to an extent that they cannot be paraphrased in a better way.

The Collaborative Condition Monitoring use case is based on a working group of the German Plattform Industrie 4.0 that develops collaborative, data-based business models. The foundation is a highly simplified, cross-company network consisting of a component supplier, a machine supplier, and a factory operator (see Fig. 5). The component supplier produces components for a machine, whereas the machine supplier assembles these components to construct a machine. The factory operator then uses this machine within a production system. The following points in this section relate to the publication Plattform Industrie 4.0 (2020).

A key aspect of the use case in this context is the collaborative use of technical operating data of a machine in a multilateral network. The technical basis here is formed by Digital Twins, provided along with the components. Furthermore, there is a Digital Twin of the entire machine which embeds the individual Digital Twins of the components. The factory operator is the data owner and can freely decide how to use the data. Therefore, the objective is to enable the factory operator to share the machine’s data with the component and machine supplier. The condition monitoring approach provides a rationale for this, whereby the factory operator receives additional services in return for providing the data, thus extending the machine's lifecycle. Another aspect here, however, is the conceptual design of the Digital Twins so that the operating data can be shared without barriers on the one hand and without compromising data sovereignty on the other. The design principles for Shared Digital Twins developed here provide an important entry point for the implementation of such a collaborative use case.

Illustrative Quote:

“These are at least the questions we are asking ourselves, yes. Or have - exactly. Case by case it is different, that is. A data link for example. It can be one-directional, but it can also be bi-directional. It is not either or, but it is an and, often.”

It is decisive for using a Shared Digital Twin to implement a one-directional data link between the Digital Twin and the physical counterpart. The link ensures an enrichment of the Digital Twin with the critical process parameters relevant for sharing. However, this one-directional data link is not enough in many cases, and it requires a bi-directional connection. Examples for this are use cases from the maintenance field where a plant operator provides the service company with access to the plant via the Digital Twin.

Illustrative Quotes:

“I must be able to store it and I must be able to transfer it in any form, so that I can do meaningful processing.”

Purpose is also… Actually… Well, the primary topic is transfer, as I said, as an integration technology. But it is, in a sense also a repository and of course processing.”

Illustrative Quote:

“I mean the interface both (M2M and HMI), yes, makes sense. So especially in this logistics-related world or where I really deal with physical entities, I think it makes sense to describe it that way, yes.”

This design principle considers the need to allow for manual intervention in the processes. However, there is still the requirement to automate a significant part of the operations. The processes via the M2M interface operate autonomously, while an HMI interface provides the user with access to the process parameters of the counterpart.

Design Principle 4: Provide the Digital Twin with convenient synchronization functionalities in order for users to receive both a constant real-time update of incoming data and on demand also a a non-real-time data update, given that the Digital Twin enables cross-company and multilateral data sharing.

Illustrative Quote:

“So, I think there are many cases where the real-time connection is not crucial. And where on the other hand it would cost you a lot of money to implement. If I look at marketing and sales data now, sales data is nonsense, how my products are used by customers. I do an analysis every three seconds, I kind of do, I look at the product for a month and see how they have behaved, the twins that are outside, the physical twins how they have behaved this month, but I don't need the data from the last 4 milliseconds. On the contrary, I find it important to see where I need a real-time synchronization and where a discrete or sporadic synchronization is enough for me and makes it much easier for me to collect it.”

This design principle specifies the data connection between the Digital Twin and its counterpart. Furthermore, this design principle describes the synchronization with distributed systems, where the Digital Twin receives data from external sources. The synchronization from distributed systems is very complex, so that a real-time update is not always possible. Moreover, a continuous real-time update requires considerable effort, which is often not appropriate for the respective use case. Therefore, the possibility of on-demand synchronization is important for a Shared Digital Twin. However, there are also use cases where real-time synchronization is of crucial importance. These include, for example, condition monitoring, where undesired process events must be detected immediately.

Illustrative Quote:

“Data input, I would expect, that it then flows from the Digital Twin into the companies. With raw data, processed data, that's really hard because you try to map it. […] I need raw data if I have a system somewhere that produces raw data. How do I feel me what temperature I have, it's more like raw data. With the other one (processed data) it is really a photographing data that is available somewhere.”

This design principle refers to the type of data processed by a Digital Twin, considering both unprocessed raw data and already processed data. In a Shared Digital Twin, both aspects are important. Like an internally used Digital Twin, a Shared Digital Twin must process and store all raw data generated by the counterpart. To create an image of a counterpart that is as complete as possible, the Digital Twin is required to possess the ability to use various data sources and the ability to link together a number of other data formats. Many analyses require knowledge that the counterpart itself cannot generate.

Illustrative Quote:

“I mean, for example, in data acquisition. When I define a goal, for example in the cross-company area, I commit myself to semi-manual. This is already mentioned here that I say I also leave it manual, because otherwise I would exclude too many partners. They may not have the IoT for automated data acquisition.”

This design principle refers to the possibility of manual data storage. The background of this design principle is an aspect of distributed networks, where not every participant has the technical prerequisite to enter data into the Digital Twin automatically. In order not to exclude individual partners, a Shared Digital Twin must be able to accept manually inserted data. Manual data acquisition is also crucial when it comes to the knowledge of domain experts. It must be possible to enter expert knowledge into the Digital Twin manually. Nevertheless, a Shared Digital Twin aims to automatically capture a large proportion of the data to keep operating effort as low as possible.

Illustrative Quotes:

“So, there is non-interoperability, interoperability via interfaces and translators or full interoperability, because I can use common models [...] if I use a common model to create Digital Twins then I am fully interoperable, so to speak, because I follow a common standard. A Company “A“ language and a Company “B” language, they do not follow a common standard. That is why common standards can be so powerful.”

“On the technical side, I would then have to have exchange standards. The way we describe the Digital Twins at the moment and how we make them available - this is what is happening at our company. If another company uses a different solution, then they probably can't communicate with each other, which means that there would have to be some kind of standards for such an exchange.”

This design principle is of crucial importance, especially for the aspect of multilateral data sharing. Shared Digital Twins must either be designed so that the Digital Twin and the distributed systems are fully interoperable or at least have interfaces that serve as translators. That applies to both the interfaces of the Shared Digital Twin and those of the distributed systems. Without this design principle, multilateral data sharing would not be possible; the exchanged data would not be interpretable and would have to be adapted to the data model of the respective system at great expense. Especially in terms of largely automated data acquisition, manual adaptation of incoming data is to be avoided.

Illustrative Quotes:

“My experience is that this is seen by many as extremely important. So respecting data ownership is essential. Especially nobody wants to give out any critical IP. […] So it is extremely important that the person who owns the product or who has done something with it, who has processed it, for example, that this information belongs to him or herself and that he or she can decide for himself or herself what information he or she wants to pass on to others.”

“[…] who is actually allowed to do what? What roles are there, who is allowed to do what to whom, who gets what data, that's what I would call data governance. At IDS, for example, the topic of data sovereignty, such roles are described.”

In addition to design principle 7, this design principle is of decisive importance for a Shared Digital Twin in terms of data security. In general, all parties involved must be willing to share data, although there are numerous hesitations about sharing data. These hesitations must be overcome with the help of technical solutions. As with design principle 2 regarding the purpose of the Shared Digital Twin, the topic of data in use plays a decisive role here. The data provider must be able to determine what happens to the data after its release via the Shared Digital Twin. This approach goes beyond access control, which merely controls access by the data owner before release. A further aspect that has emerged from the interviews is the customer requirement for data sovereignty:

“But this issue data sovereignty. That is simply a K.O. criterion for us, coming from the customer.”

Often there are relationships between partners where the partners are equally dependent on each other's data. Both partners must ensure that they retain sovereignty over their data and that the shared data originate from trustworthy sources.

This paper aims to develop design principles for Shared Digital Twins. The use of Digital Twins offers considerable potential for cross-company use but requires a specific structure and implies special implementation requirements. This paper aims to identify these requirements, which must be reflected in this type of Digital Twins design. A significant added value of the present study lies in identifying characteristics that enable the use of Digital Twins in distributed systems. This identification goes beyond the examination of the corresponding literature and involves the expertise of professionals, allowing for increased consideration of relevant practical aspects.

In this context, the Digital Twin Conceptual Reference Framework by Barth et al. (2020) serves to classify the developed design principles. This classification highlights the conceptual difference to merely internally used Digital Twins. Therefore, we adapt the Reference Framework for Shared Digital Twins so that the ontology (see Fig. 7) allows a classification of the design principles into the sections Internal Value Creation, External Value Creation, and Data Resources. Using the ontology and the three classifications mentioned above, it is possible to show how the results of this study relate to each other and how the concept of the Shared Digital Twin differs from internally used approaches. First, the conceptual overlap between regular Digital Twins and Shared Digital Twins becomes apparent in the present review. Both approaches form a technology that can integrate data from multiple sources, describe them semantically and represent them over an entire lifecycle. However, the Shared Digital Twin goes much further in this respect in that it is technically capable of transferring the integration process to distributed systems. This emerges clearly from the External Value Creation feature, as Shared Digital Twins focus on interoperability and security features. In this context, External Value Creation describes the possibility of creating value based on cooperation with external actors (Barth et al. 2020), including Interoperability and Data Security principles. Internal Value Creation involves value creation achieved with processes within the company itself. This includes the Purpose and Interface specifications. In this case, Data Resources describe the design principles that enable the comprehensive recording of data, consisting of Data Input, Synchronization, Data Link, and Data Acquisition characteristics.

The use of Digital Twins in a distributed system extends previous approaches of an inter-organizational information system (Uhlenkamp et al. 2020). It forms a concept that significantly facilitates the collaborative use of operational and sensor data in a network of various actors. The data exchanged in this way allows detailed insights into operational processes and thus enables the emergence of new business models, for example, in maintenance (see Plattform Industrie 4.0 2020).

The derivation of the design principles based on 18 expert interviews with in-depth domain knowledge results in numerous managerial contributions, expressed in design principles 7 and 8 regarding interoperability and data security. Both design principles are key factors for participation in collaborative networks, enabling assets that have a Shared Digital Twin to share data with other stakeholders and use them for smart services as described by Azkan et al. (2020). Simultaneously, the design principles presented provide a practical guideline for implementing Shared Digital Twins, allowing practitioners to follow the eight categories of key requirements and the associated technical implications.

Again, the respective implementation steps depend largely on the context of the individual use case. It is often also a matter of identifying the appropriate software components that meet the requirements of the particular use case. The 15 key requirements from Table 5 serve as templates and provide a basis for workshops in which the respective focus groups can identify these software components. The use of Shared Digital Twins offers the opportunity to link the information flows of the individual stakeholders in a value chain more effectively. It thus creates the basis for developing business models based on the collaborative use of data. By considering the use case Collaborative Condition Monitoring, we also highlight the practical implications of the results described here. The collaborative use of operational data makes it possible for a network of component and machine suppliers as well as factory operators to gain insights into the use of components and the resulting improved service performance. Overall, this demonstrates a collaborative digital business model enabled by the use of a Shared Digital Twin, suggesting that the design principles developed here provide important added value for developing such collaborative business models. In this context, the application of Shared Digital Twins, as described within this contribution, offers the possibility of a holistic integration of operational data. Furthermore, the specifications of a Shared Digital Twin identified here provide information about the technical prerequisites for the collaborative sharing of technical, operational data. On the one hand, the use case benefits from these design principles, and, on the other hand, the use case itself illustrates the relevance of Shared Digital Twins by placing it into a practical context. Finally, the design principles we propose for Shared Digital Twins can very probably be applied to an array of similar use cases for Shared Digital Twins in distributed systems. Transferring the design principles might require adjustments in specific characteristics, for instance data security or interoperability, based on the specific requirements of different domains. However, they are a significant starting point to enable designers of Shared Digital Twins to draw from them in other cases and “(…) write their own versions of those principles (…).” (Chandra Kruse et al. 2016, p. 40).

This paper makes scientific contributions especially in expanding the literature-based knowledge to include the industry's requirements. Therefore, this paper essentially contributes to developing prescriptive knowledge for the design of Digital Twins used in collaborative networks. In addition to developing design principles for Shared Digital Twins based on 15 expert interviews, three other industry experts evaluate and rate these principles (Iivari et al. 2020). Design principles tend to be evaluated only rarely so that the present contribution addresses the demand for reusability of design principles.

Thus, this study differs from many other scientific contributions on the topic of Digital Twins, which mainly focuses on the manufacturing domain (Enders and Hoßbach 2019). Especially fundamental contributions such as those by van der Valk et al. (2020) or Jones et al. (2020) help to understand the basic characteristics of Digital Twins by providing descriptive knowledge. The aim basis of this paper is to extend this knowledge base to the collaborative use of Digital Twins and the enrichment of the existing descriptive knowledge with the practical knowledge of domain experts.

Regarding the limitations, we encountered the difficulty of keeping the design principles generic so that these principles address a class of artifacts and not only an instance (Sein et al. 2011). The focus in deriving these design principles is on technical design. Thus, not all aspects of expert interviews could be included. Legal issues, here classified as mandatory characteristics, also remain a realm which needs to be looked into more closely (see Table 6). Furthermore, this contribution illustrates that an entirely literature-based approach to developing descriptive knowledge in taxonomies is not sufficient to cover the topic of data sharing based on Digital Twins in a holistic manner. Especially the last aspect leads to the necessity to extend the taxonomy of van der Valk et al. (2020) with the aspects of a cross-company usage of Digital Twins in the course of further research. In this context, the dimensions of interoperability and data security must be mentioned again, which experts consider essential requirements for Shared Digital Twins. Accordingly, the topic of Shared Digital Twins must be examined from different perspectives that go beyond technical issues and have a legal and organizational context. This refers to standardization efforts that must be promoted during the cross-company use of Digital Twins and also refers to the examination of existing standards that can be taken into account.

The cross-company use of data is becoming increasingly important in industry and reveals the current barriers to sharing data with other companies. Key aspects of this are a lack of trust in the infrastructure and the fear of releasing critical data, thereby risking competitive disadvantages. In this context, the use of Shared Digital Twins provides the best solution as it relies on on existing structures and standards. In the future, concepts such as Shared Digital Twins will have to be accommodated in vendor-neutral integration platforms, which, on the one hand, enable the secure storage of data and, on the other hand, allow sovereign data sharing in the sense of collaborative use of data. Furthermore, it is worth to conduct further qualitative research to identify different configurations on the basis of various use cases. This could involve configurations that contain other characteristics from the taxonomy or provide for a different concept in terms of the level of data security. Another important aspect is instantiating a Shared Digital Twin based on the design principles identified here, which represents an part of our current research agenda.