Value Creation with Digital Twins: Application-Oriented Conceptual Framework and Case Study

Abstract

The internet of things, digital twins of smart connected products, and thereby enabled smart services are topics of great interest and have been gaining traction for many years. However, many questions concerning the application-oriented usage of digital twins still need to be scrutinized. Therefore, this paper examines the question of an application-oriented framework for value creation with digital twins using design science research approaches. A conceptual reference framework is presented based on earlier research and iteratively developed within workshops with three companies. The framework incorporates primary dimensions of external and internal value creation and data resources. Further, it discusses the product life cycle, the real-world counterpart, value creation in the ecosystem, and the generational aspect of the digital twins. Furthermore, applying the framework to a use case with an industrial research partner helps to show the contributions to the industrial sector. The framework provides utility to practitioners as a means of creating a common sense in interdisciplinary teams, communicating digital twin projects to internal and external stakeholders, and as a toolbox for specific challenges concerning digital twins. In addition, the framework distinguishes itself from existing approaches by including the service ecosystem and its actors while considering the principles of product life cycle management. Therefore, using the framework in other use cases will test the approach on different industries and products. Furthermore, there is a need to develop approaches for implementing and developing an existing case.

1. Introduction

Digitalization is a megatrend that has been changing our society on a large scale for decades. One of the more recent phenomena within this megatrend is the Internet of Things (IoT), which refers to the networking of physical products via the Internet. In a 5G world, with edge computing and intelligent networks, everything becomes a “thing”, and every “thing” produces data. A report by Juniper Research estimated the “total number of IoT connections” in 2020 at 35 billion and projected an increase to 83 billion by 2024, representing a growth of 13% [1]. Further development and progress will connect more traditional products to the IoT and transform them into smart connected products (SCPs), allowing for novel smart services and ultimately changing whole industries [2,3,4,5]. Here, the digital twin (DT) concept is regarded as a critical technology for creating value with smart services [6]. Although research and applications in the field of value creation with DTs are constantly growing [7], many questions and issues need to be further examined [8].

1.1. Origin

Using representations of an object under investigation to perform tests and thereby gain knowledge goes back to the Apollo program of the National Aeronautics and Space Administration (NASA) [9]. In the 1960s, NASA pioneered the development of a second, identical spacecraft that remained on Earth during the mission. This “twin”, which at that time did not exist digitally but in reality, was used extensively by astronauts for training during the pre-flight phase, while one spacecraft was in space, the second spacecraft (the physical twin) was used to simulate alternatives using available flight data to recreate flight conditions as realistically and accurately as possible. The origin of the idea to perform such twinning with a DT is attributed to Michael Grieves and John Vickers of NASA, with Grieves presenting the concept in a lecture on product life cycle management (PLM) in 2003 [10]. Initially, the idea was referred to as the “mirrored spaces model” and not as the “digital twin” [11]. However, it already had the three essential elements that are still used to identify DTs, (i) a physical product in real space, (ii) a virtual product in virtual space, and (iii) the connection of data and information which ties together these two spaces [12]. In summary, this core concept of the DT envisaged a system that ties physical entities to virtual counterparts, leveraging the benefits of both the virtual and physical environments to the advantage of the entire system by exchanging valuable information about the products and processes [13]. In 2012, the concept of DT was revisited by NASA, which defined the DT as a “multiphysics, multiscale, probabilistic, ultra fidelity simulation that reflects, promptly, the state of a corresponding twin based on the historical data, real-time sensor data, and physical model” [14]. Many academic publications refer to this definition of a DT, e.g., [6,11,15,16,17,18,19,20,21,22].

1.2. Status Quo

The definition of DT has evolved in the last decade [23], alongside its growing popularity and adoption into different industries and use cases, which rarely meet the stringent demands of an “ultra fidelity” one-to-one copy. Many publications adopted the DT concept with some deviations from the original definition, albeit avoiding defining the DT concept explicitly themselves [24]. Instead, they implicitly assume a particular set of abilities and properties, which hinders the formation of an accurate definition. The nature of the DT is described in many ways, for example, as a multi-domain simulation [25], a computerized counterpart of a physical system [26], a virtual representation of what has been produced [10], a virtual substitute of real-world objects [27], an integrated simulation and forecasting tool [28], or a linked collection of digital artifacts [29]. In summary, many definitions up until 2019 defined a DT as a virtual representation of a physical product, asset, process, or system in a cyber-physical system, and throughout its life cycle, capable of mirroring in real-time its static and dynamic characteristics as a result of seamless data transmission between its digital replica and physical entity (i.e., [30]). Van der Valk et al. [31] analyzed 233 DT definitions used in academic publications, and [32] analyzed the journey of the DT definition and described a paradigm shift from the classic definition with the three elements: physical space, virtual space and bidirectional connection to an expanded definition with five elements, adding data and services. However, there is still no common understanding of the DT concept, especially in practice [33,34,35], as the various definitions and concepts depend strongly on the respective application context [36]. This is illustrated through the frequent entanglement of DT descriptions with specific industries, such as manufacturing [37].

1.3. Research Gaps

Since DTs are still an emerging field of research in which theories, approaches, models, and frameworks are not yet consolidated, there is a considerable need for research that contributes to filling these gaps. In this subsection, we first describe the critical knowledge gaps before mentioning concrete calls for creating a conceptual reference framework in the second part.

1.3.1. Corporate Knowledge Gaps

Industrial systems and usage scenarios are complex and diverse; therefore, their requirements from DTs will be similarly diverse [38]. For this reason, it is difficult to identify the characteristics, nature, and level of sophistication of the DT needed to realize the benefits each industrial context requires [39,40]. DTs further create many unique and complex challenges, which must be addressed and managed to ensure effective value creation [13,41]. Given the potential costs and challenges of the infrastructure and workflow changes needed to implement DTs effectively, a lack of tangible understanding of the scale and nature of value creation is a substantial knowledge gap in practice, according to Jones et al. [39]. In a corporate context, “tangible” means communicating in an understandable way to various internal and external stakeholders, the type of DT used to create value. This is because establishing value-creating and sustainable DT-based service proposition concepts and business models involves collaboration between experts from various disciplines inside and outside a company [42,43], as they impact internal and external processes [44]. However, this collaboration to create value in businesses is hindered by the lack of a shared conceptual framework for DTs, an unambiguous terminology [36], and the missing common language based on a sufficiently abstract, intuitively understandable, and easy-to-use reference framework [34,42].

1.3.2. Call for a Conceptual Reference Framework of Digital Twins

As these cross-functional discussions turn out to be intricate, especially in practice, and academia struggles to provide suitable base frameworks, many authors call for a suitable conceptual reference framework to fill this research gap. Singh et al. [13] stated that new research-based architectures and DT frameworks are required for implementation into current systems and the industrial internet. Meierhofer and West [45] showed that further dimensions for structuring DTs are needed to achieve a differentiated yet understandable perspective, especially on their value creation. Sjarov et al. [24] referred to the complex and multifarious nature of DTs when pointing out the importance of future graphical models to provide clarification and systematization. Jones et al. [39] stated that it is only through a consolidated common understanding and terminology valid for a multitude of DTs that the envisaged benefits afforded by the DT can be fully realized and shared across domains. According to Boss et al. [38], a common understanding of the DT concept is also needed to enable interoperable DTs. Agrawal et al. [40] state that a clear articulation of the DT definition and a framework for unifying the various perspectives of project participants is critical for a consensus on the DT concept in practice. In addition, according to Sharma et al. [35], the lack of a universal DT reference framework is even one of the main delaying factors for DT implementation in practice. In summary, there is a clear need for an application-oriented conceptual reference framework for the value creation with DTs that is useful in practice and contributes to a common understanding of the concept in research and practice.

1.4. Relevance and Potential

The DT trend is gaining momentum thanks to rapidly evolving simulation, modeling capabilities, better interoperability, IoT sensors, and the broader availability of tools and computing infrastructure [46]. In principle, DTs are conceivable for all networked objects, and appropriately, emerging technologies such as the “digital twin of the person” and “citizen twin” can be found in the Gartner hype cycle of 2020 [47]. Over the coming years, DTs will be adopted by many companies, with the twins they design becoming more sophisticated [48]. The DT has also gained greater attention and popularity in Europe. For example, the two most prominent German industry associations (VDMA and ZVEI) have founded the “Industrial Digital Twin Association” together with 20 well-known companies from the mechanical engineering and electrical industries, such as ABB, Bosch, Siemens, and Volkswagen as user organization for Industry 4.0 [49]. This is because even though the DT concept is relatively young, the global DT market was valued at USD 6.9 billion in 2021 and is projected to reach USD 73.5 billion by 2027 [50]. Consequently, both academia and industry place great value on researching, developing, and seeking to apply DTs or the principles they represent [39].

1.5. Structure

After this introduction, the remaining parts of this paper are structured as follows. The next chapter presents preliminary work in a concise form. This consists mainly of a scientific conceptual reference framework for value creation with DT, which formed the basis and starting point for the research of this paper, as well as its evaluation and validation. To avoid wordy sentences, this paper shortens the term “conceptual reference framework for value creation with DT” to “digital twin framework” and abbreviates it to “DTF”. The framework in the preliminary work chapter is thus referred to as “scientific DTF”. Then, the objectives of this paper are explained, which, based on the preliminary work presented, are to close the research gaps explained in the introduction. The method chapter is completed with an overview of the research approach and the methods used. The results are presented in the following two chapters. First, the developed application-oriented conceptual reference framework for value creation with DT (abbreviated as “application-oriented DTF”) is presented in its generic, universal, and abstract form without reference to a specific use case. In the second part, the application-oriented DTF is exemplarily applied to a use case and thus presented in an instantiated, use case-specific version. Following is a discussion of the presented results and their contribution to practice and science. The paper ends with a conclusion in which the achievement of the initial objectives is shown, limitations to be considered are acknowledged, further research directions are pointed out, and finally, an outlook on the further development of the application of DTs in practice is ventured.

2. Preliminary Work

This chapter presents crucial preliminary work in a very brief form. These formed the basis and starting point for the research, and the results presented in this paper mainly consist of a scientific conceptual reference framework for the value creation with DTs and its evaluation and validation.

2.1. Conceptual Reference Framework for the Value Creation with Digital Twins

Barth et al. [41] proposed an ontology and a conceptual reference framework to discuss and analyze the main value-creating dimensions of DTs. The research questions and objectives in this previous study were:

• Which dimensions are used to classify and structure DTs in academic literature?
• What are the fundamental differences or specifications within these dimensions?
• How do these different specifications relate to each other?

The objective of the research was to find classification systematics that are

• representing the entire spectrum of DTs,
• universally valid in all DT-related domains and
• applicable in research and practice.

The resulting scientific DTF shown in Figure 1 required further research to evaluate and validate the framework regarding its application in practice and research and to examine further refinement and development priorities.

2.2. Evaluation of the Scientific DTF

The scientific DTF was presented to and discussed with 42 experts from 30 companies to evaluate and validate its application in practice and examine further refinement and development priorities. The evaluation of the quality of the framework, its benefits in practice, and its applicability for innovation process phases were collected with an online questionnaire consisting of open questions and quantitative ratings [51]. Qualitatively, the study unveiled the systematization and holistic perspective as the main strengths and the complexity as the major weakness of the framework. Quantitatively, the framework proved helpful as it benefits practice, especially in the early stages of innovation processes. Finally, development priorities and directions to improve and adapt the framework towards the created insights were derived in order to foster the DTF’s applicability in practice. In addition to a few adjustments to the designations for individual elements, the need for the framework to be adaptable to different use cases to be useful in practice became particularly evident.

3. Materials and Methods

Following on from the evaluation, in this research, the scientific DTF was further developed with a focus on its practical application. For this purpose, the derived development priorities and directions for improving and adapting the framework and the established contacts with the companies could be used.

3.1. Objectives

The main objective of this research was to develop and evaluate a valuable artifact for research and practice in the form of an application-oriented conceptual reference framework for value creation with DTs. Therefore the scientific DTF was further developed into an application-oriented DTF, characterized in particular by its usefulness in practice. By focusing on the needs of practitioners, including value creation with DTs, as well as the scientific rigor of the preliminary work, this framework contributes to answering the calls outlined in Section 1.3.2. For the framework to be applicable and valuable, it was designed as a tool that can be modularly adapted to specific use cases. The template for the application-oriented DTF is publicly available; the link can be found at the end of the paper in the Data Availability Statement.

3.2. Methods

We used the research framework and procedure from Hevner et al. [52] seen in Figure 2 for the iterative development of the application-oriented DTF.

The scientific DTF seen in Figure 1 formed the primary grounding for the knowledge base in the rigor cycle. It was comprehensively revised based on the extensive feedback collected from the practitioners during its evaluation phase. Their companies represent the application domain in the environment, and their requirements are included in the relevance cycle. The requirements taken into account comprise the verbal comments during the presentations, the answers given in the online questionnaire, and the valuations in the utility analysis.

Several workshops with three companies already involved in evaluating the scientific DTF were conducted in the design cycle to design a new artifact in the form of an application-oriented framework. The starting point was the three dimensions (internal value creation, external value creation, and data sources) of the scientific DTF. Taking into account the feedback from the preceding evaluation phase, the use cases of the three companies were conceptually modeled in an iterative process during the workshops. In the end, the commonalities were analyzed, and a use case-independent, generic, and application-oriented framework was created, which can serve as a starting point for representing or deriving other use cases for other companies. Since the created application-oriented framework contains partially different and additional elements, additional academic literature was consulted to ensure scientific rigor. For this reason, the theory used in the rigor cycle is woven into the first results section rather than presented in a separate theory chapter.

To evaluate the utility and application of the application-oriented DTF, it was instantiated as an example for another use case, which is described in detail in the results Section 5. This activity is again part of the relevance cycle, as the designed artifact is tested in the application domain for which it was designed. The application-oriented framework evaluated in this way is published with this paper both in generic form and instantiated for an exemplary use case, thus forming the addition to the knowledge base.

According to Hevner et al. [52], the design evaluation methods applied in this research are thus observational and descriptive. They are observational concerning the current status of the product-service system offered by the company. The potential innovations described along the dimensions and elements of the developed application-oriented DTF can be regarded as scenarios and therefore represent a descriptive evaluation. Additionally, analyzing the current status and discussing potential future states can be regarded as an informed argument, which also constitutes a descriptive evaluation method.

4. Application-Oriented Digital Twin Framework

In this first result section, the developed application-oriented DTF is presented in its generic, universal, and abstract form without reference to a concrete use case. For this purpose, the central elements of the application-oriented framework are presented individually, and the most important differences to the scientific DTF are explained before the entire framework is presented in Section 4.6. In this respect, it should be mentioned that the three dimensions of value creation with DTs and the corresponding color code established in the scientific DTF have been adopted unchanged for the application-oriented DTF: yellow for data resources, blue for internal value creation, and gray for external value creation, as seen in Figure 3. The specifications (e.g., Product Life Cycle), which occur in the scientific DTF as axis labels, are not explicitly labeled in the application-oriented DTF. They are structuring aids that can be largely omitted for a better overview in an application-oriented framework. Instead, the application-oriented DTF focuses on the subspecifications relevant for the value creation (e.g., Beginning-of-Life, Middle-of-Life and End-of-Life). Through this approach, it was even possible to go one logic level deeper at relevant points (e.g., individual activities within Beginning of Life, Middle of Life and End of Life could be represented).

4.1. Product Life Cycle

The life cycle of a product is commonly divided into three phases Beginning-of-Life (BoL), Middle-of-Life (MoL), and End-of-Life (EoL) [53]. Concerning the further subdivision into activities, there are different approaches with different granularity [54,55]. As shown in Figure 4, we distinguish twelve activities along the product life cycle in our framework. In BoL we distinguish

• Customer and market analysis,
• Product planning;
• Product development;
• Marketing and sales;
• Production;
• Distribution and commissioning.

Depending on the view, the activities in the areas of distribution and commissioning already belong to MoL, which is why this activity in the framework shows a transition from blue (for internal value creation during BoL) to gray (for external value creation during MoL). The other activities that are distinguished in the MoL phase are:

7.

Training;

8.

Service and maintenance;

9.

Updates;

10.

Upgrades;

11.

Resale.

With regard to the last life cycle phase of EoL, there is only one activity that is counted exclusively as EoL in the framework:

12.

Recycling.

In the sense of the closed-loop idea of PLM, however, some parts of the activity “Customer & market analysis” could also be counted as EoL. In particular, if valuable information and knowledge for the next cycle can be gained from the previous life cycle.

Figure 4. Product life cycle.

Figure 4. Product life cycle.

There are many studies on the application of DTs along the product life cycle (e.g., [17,19,56]) and the integration of the DT into PLM (e.g., [57]). Research is still focused on the potential of DTs in the BoL and MoL phase, for example, to optimize product design, engineering, shop floor design, supply chain management, customer demand analysis, and service and value proposition design (e.g., [8,17,19,21,43,56]). However, there is also a plethora of possibilities of DT applications in any other PLM discipline, which are not yet fully explored (e.g., [16,28,45]). In theory, DT-based services can provide value in every life cycle phase. Inherently, DT concepts embrace the whole product life cycle “from cradle to cradle” [58]. However, in a study from Switzerland, only 15% of the companies surveyed reported using DTs in the EoL phase, as the focus is mainly on the BoL (79%) and MoL phases (60%) [59].

4.2. Things as Real-World Counterpart Data Sources

The real-world counterpart usually provides data from the MoL phase to the DT. In the case of physical products, the sensors are often mounted directly to the product itself. The raw data generated in this way is processed in the embedded system for transmission to the DT [60]. However, also, in the case of processes or services, the relevant data can be generated via sensor-equipped, so-called “things”. We refer to these data sources in line with the widely used term “Internet of Things” in our framework [61].

Many sources (e.g., [17,18,22,23,62,63]) suggest dividing these “things” into different levels of hierarchy to structure the DT. The hierarchy levels mentioned differ, ranging from two [16,23,64] to six [43,45]. However, the most common and comprehensible hierarchy determination distinguishes three levels, mainly referred to as “component” or “unit”, “system”, and “system of systems” [6,8,21,65,66]. Structuring DTs according to such a three-tier hierarchy is also in line with the well-known model of Porter and Heppelmann [3,4], explaining the innovation from SCPs to systems and system of systems. Therefore, in our framework, we also distinguish three abstract levels with the terms used by Porter and Heppelmann [3,4], as seen in Figure 5.

However, when it comes to realizing value creation with services, the appropriate granularity of the DT of a SCP or cyber-physical system and the corresponding “family of twins” [45] that make up a system or system of systems must be determined on a use-case-specific basis and may distinguish more than three levels. It is necessary to note that rather than locally and individually optimizing single products (e.g., production machines), there will be significant efficiency and effectivity gains when the generated data and interactions are analyzed and optimized at higher system hierarchy levels [8,67].

Academic authors agree that the twin counterpart should at least cover physical products and components [24]. On a more generic level, this means systems, subsystems, and systems of systems, which also include the corresponding processes. Specific approaches also propose DT concepts for human workers [68] or business services [69]. Malakuti et al. [23] further stated that the DT definition had been enriched over time to be an evolving digital profile of the historical and current behavior and all properties of an asset—where an “asset can be anything of value for an organization”, such as a physical device, subsystem, plant, or software entity. An entity, as the real-world counterpart of the DT, can thus be defined as an item with a recognizably distinct existence [38] relevant to the value creation. In addition to this data from the “things”, additional data sources can be used to improve the DT. The next section introduces the complementary data sources used in this framework to enhance DTs further.

4.3. Complementary Data Sources

Companies collect data from various sources such as on-board systems of the things, internal enterprise systems, and third-party sources and store it in often scattered legacy systems. As a result, data is divided into silos across enterprise divisions and product life cycle phases. Consolidating these islands of information in a DT lays the foundation for data-based innovation of services and processes. The non-embedded systems connected to the DT are divided into internal and external information systems in our framework, as shown in Figure 6.

Firstly, DT concepts utilize, integrate, and recombine contents from internal enterprise information systems such as authoring systems, Product Data Management (PDM), Enterprise Resource Planning (ERP), Computer-Aided Design (CAD), Customer Relationship Management (CRM), and other systems for specific objectives [58]. Secondly, the DT may utilize, integrate, and recombine contents directly from corresponding systems of other companies and third-party data providers offering valuable data via API or IoT platforms. This second group of sources is referred to as “external systems”. In the reference framework, the different data sources for DT are therefore divided into things, internal systems, and external systems.

4.4. From Data to Value

This chapter describes how value is created from data with the help of DTs. First, the different categories of data will be explained, then data preparation, analysis, and interpretation will be examined, and finally, it will be described how the resulting services create value.

Data categories—Product, customer, and context data serve as the key to value creation, while practical data analytics tools enable its success [70]. DTs represent a product [11], and its processes [71] and therefore consist of datasets describing the state and behavior of the real-world-counterpart of the DT. Grieves and Vickers [11] elaborate on what data can be contained in a DT. Depending on the use case, they state a complete 3D model of the physical instance and its components, a bill of materials that lists current and replaced components, and a bill of processes that lists operations and processes that can be included. In addition, the results of any measurements and tests, a service record, and all available sensor data from the things should be added to the DT. In our framework, all these data are included under the term “product data”. Another frequently described category that serves as a foundation for knowledge-based decisions is contextual data (e.g., [15,20,23,72,73,74]), such as environment data (e.g., temperature, humidity) and any other contextual data relevant for the intended value creation (e.g., exchange rates, weather data, market data) which is not directly related to the state or behavior of the product or asset itself. Academia and practice show that the value of digitized products for the user of a DT increases with access to data from the surrounding ecosystem [3,4]. The third category that is distinguished in our framework is customer-related data, such as data about the actual owner, configuration and usage preferences, and other relevant customer relationship management data [75]. This customer-related data is gathered before the purchase, as the customer experience life cycle already provides valuable data during the earlier phases. By combining all the data obtained, it is possible to potentially unveil completely new insights that rend enormous business opportunities, as these comprehensive DTs illustrate the current lifestyle of users [43] and ultimately unexploited or future customer needs and demands. Hence, service-oriented DTs can be the source of several new knowledge-driven business opportunities [76].

Data analysis—To create value, the data must be structured and interpreted to achieve DT-based decision- and sense-making. According to the data life cycle for DTs defined by Tao et al. [19], eight different steps can be distinguished: Data collection, data transmission, data storage, data integration, data processing, data cleaning, data analysis, and data mining. After collecting, transmitting, and storing the data, the integration, processing, and cleansing of data are the crucial steps to achieve compatible, structured data formats for the analysis and interpretation phases. In the reference framework, this process is simplified to the three main categories of unstructured, structured, and interpreted data (following [8,20,44,64]). The data processing is referred to simply as “Smart Analysis”, which is carried out utilizing tools, algorithms, rules, and models (see Figure 7).

Unstructured data is raw data, often obtained from the sensors used to measure the real-world counterpart of the DT. Semi-structured data are either preprocessed unstructured data, for example, the transcripts of recordings, or have origin in external systems using different structuring standards, for example, customer reviews, comments, and complaints in the web or equipment maintenance orders. Unstructured and semi-structured data require preparation efforts according to the analysis and processing methods requirements before they can be interpreted. Therefore, semi-structured data is not further distinguished from unstructured data in the model. Structured data, on the other hand, is either the result of proper data processing or originates from external sources providing data-as-a-service. These data are thus characterized by a high degree of organization, clarity, and consistency [20], hence most data in internal information systems can be considered structured [77], but also many external data providers deliver structured data, for example, market information, such as exchange rates or sales numbers, search engine advertisement data or weather data. Traditional design methods, data life cycle management tools, and databases are developed to interpret structured information. Therefore, they are not suitable for dealing with the unstructured information generated without predefined models or formats [20]. Different authors embrace how to improve the data life cycle management in the DT context to achieve interpreted information that can be potentially used for automated interpretation in terms of decision—and sense-making (e.g., [15,64,72]). The more data is automatically interpreted by the DT, the higher the smartness maturity and the more solutions are implemented without involving users. The “user” in our framework can be either a human actor or another DT. DTs of systems may access the DTs of subordinate units or components and simultaneously may have a common objective and be aggregated to a composite system of systems DT (e.g., [17,22,23]). Therefore, users in such ecosystems might often be other SCPs, systems, system of systems, or their DTs, interpreting structured data and requesting data-driven services.

From services to value—The research on how the various components of DTs are encapsulated in services and used is not well-established [17]. However, the integration between DTs and services is promising, as new services can be enabled, and existing services can be enhanced by the new data supplied by DTs [21]. The common aim of the DT is to support the realistic model of system behavior that can support often already established services such as performance prediction and optimization [16]. However, concerning the concept of everything-as-a-service, services could fully release the potential of DTs [17], as the DT lends itself to contribute to the value proposition by supporting all of the actors around the product-service-system, in particular by relieving the pains and increasing the gains of the actors in new ways [45]. The attributes of a DT-based service can be defined in line with the widely recognized and used the concept of overall equipment effectiveness (OEE) that evolved into Total Productive Manufacturing. According to Nakajima [78], OEE measurement is an effective way of analyzing the efficiency of a single machine or an integrated manufacturing system. OEE is a function of availability, performance, and quality rate calculated as the product of its three contributing factors [79]. Especially in smart manufacturing and industrial IoT, this encapsulation of DT-based services seems promising, as the OEE concept is widespread and clearly defined by several norms (e.g., VDMA). However, to achieve a holistic perspective on DT-based services, the definition of OEE is too narrow. Still, it can be supplemented with an overall service effectiveness (OSE) concept applicable to describe data-based service [80]. Bange [80] elaborates the main contributing factors for services: Availability or time of the service is represented by the time needed between the occurrence at the customer triggering the need and the delivery of the service satisfying the need. The performance or cost contribution factor describes the relationship between input and output from the view of the customer. Hence it’s the price to pay for the service in relation to the value received. The quality is affected by the discrepancy between the offered and delivered services. The concept can be applied to any industry. However, the main contributing factors need to be tailored for every business case and are therefore only described generically in the framework.

Level of smartness—Intelligence and connectivity enable an entirely new set of product functions and capabilities. The benefits on the instance level can be structured and modeled according to Porter and Heppelmann [3,4] in four increasing levels:

• monitoring,
• control,
• optimization and
• autonomy.

In the reference framework, the level of monitoring is not included, as a product that is monitored but not controlled cannot be regarded as smart, and the model only respects SCP. A SCP can be controlled through remote commands or algorithms built into the device or in the DT. This allows the real-world counterpart of the DT to respond to specified changes in its condition or environment. If certain thresholds are exceeded, the DT can trigger a predetermined reaction. On the optimization level, the product still reacts to specific environmental triggers. In contrast to the control level, the DT can now optimize its reaction due to past experiences of itself or similar real-world counterparts. Autonomy is the highest level of smartness described in theory and practice and, thus, in the reference framework. The paradigm of an ideal SCP is provided by the research stream of cybernetics, which studies the concepts of control and communication in living organisms, machines, and organizations, including self-organization [81]. It studies how a biological or artificial system processes information and depends on it to make decisions and take action. Cybernetics provides the theoretical foundation for developing smart systems, which can collect, process, and understand various self-related and contextual information [43] to make smart decisions with the purpose of viability. However, the smartness is not fully embedded in the physical product, as it can be made more intelligent to actively adjust its real-time behavior by receiving recommendations from the DT [82], which has access to vastly more data and computing power.

4.5. Role of Digital Twins

The following sections take a closer look at the role of DTs. The focus is on their function as the connecting element of the product management levels and their generations on the time axis.

Product management levels—To enable the full potential of DT in product management, it is necessary to distinguish different abstractions or meta-levels of PLM integration. Even though most authors, especially in the field of PLM, only differentiate instance and type (e.g., [42,44], some authors started to distinguish a third meta-level [11,15,20,43,83,84], referred to as “portfolio” in our framework (see Figure 8)).

The different levels of product management are connected via several learning, feedback, and validation loops to exchange valuable data [43]. The DT of an instance is directly interconnected to the real-world counterpart and represents a bidirectional reflection from the expected digital world derived from the type and the real world observed from the instance. The DT of the instance mainly fulfills three different functions that can be described as follows, following Boschert and Rosen [56] and Tao et al. [20]:

• To integrate various data types from the real-world counterpart to map its state.
• To exist and co-evolve along the life cycle of the real-world counterpart to accumulate knowledge about it.
• To optimize the real-world counterpart based on variance analyses with the digital model.

To fulfill the third function, the DT instance must reflect the expectations on how the real-world counterpart ought to be structured, function, behave, interact with customers and respond to uncertainties. These expectations are derived from the type referred to as a blueprint from which the instances are derived. It is the offering presented on the market and includes all data needed to promote, sell, build, operate, and servitize [85,86], and recycle product instances. Examples of data describing a product type are requirements, BoMs, operation plans, manufacturing methods, and recycling instructions. Furthermore, configuration knowledge for the sales process or instructions and tools to fulfill a service are typical items described in a typed dataset [42], while the definition of types is continuously changed and improved, the instances follow their life cycle and might or might not be affected by changes in their type. In some cases, the average life cycle of an instance can be substantially longer than that of its type, for example, cars that are still on the road but are no longer built according to such specifications. Equivalently to the relation of DT instance and DT type, the DT portfolio monitors and optimizes the life cycle of the product types with data from different sources. The DT of the portfolio provides design, systems, supply chain, product, and value proposition engineers with the possibility to examine the life cycle data of instances and types generated by the DTs, discover patterns, and gain insights to optimize and innovate the types. These patterns may also unveil changing customer demands that may be matched with novel product and service concepts [87] to be implemented in future types and instances. Congruent to their real-world counterparts, their digitized versions on all product management levels also comprise a life cycle where they are developed and produced, used and maintained, and in some cases also recycled [88]. The separation of portfolio, type, and instance is a fundamental concept in the presented framework and an exceedingly relevant difference to traditional models.

Different generations—The DT concept represents a holistic model-based product description for current and future life cycle stages [58]. It includes a wealth of helpful information on the current and subsequent life cycle phases [89,90]. However, not only do the current and future concepts need to be stored in the DT, but historical data about, e.g., former states of instances, types, and portfolios are valuable for optimization and innovation processes. Historical information, for example, about previous software versions or parts built into a product instance, can be essential to determine the root cause of a problem [15]. Further, the next generation often has similar problems that could have been avoided by using knowledge about the predecessors [11]. Still, today the knowledge about the behavior of instances, systems, or system of systems is often lost when they are retired. Additional value can be created through DTs structured in at least three distinctive generations (historical, current, and future). The research is still scarce; however, some authors discussed the potential of such DT concepts applied, especially in product design. Tao et al. [82] suggest a DT-driven product design and underline that their research is in the initial stage. Furthermore, Landahl et al. [16] note that approaches that use design data related to products in use to form new concepts are rare and discuss the development of several generations of products and production systems based on the same platform, especially manufacturing companies seek to be able to meet the needs of a wide range of customer needs with modular concepts. To generate new concepts using platforms, knowledge of previously developed designs needs to be represented and structured to be sufficiently reused [16], which again underlines the need for DTs to separate historical, current, and future concepts. According to Qi et al. [17], product design can be more effective with such DTs as they reduce the inconsistencies of expected behavior and design behavior, lower costs and significantly shorten design cycles. Such DTs would also create the possibility to mine the through-life data to discover patterns and to gain insights about novel design concepts—ultimately enabling a broad exploration of the design space [87]. To blend new customer needs and demands into product portfolios with data of historical and currently existing product instances and types currently in use, the DT must be conceptualized to an appropriate abstraction level suited for the conceptual stages as proposed in the framework at hand.

4.6. Application-Oriented DTF

The elements presented in this chapter are shown in their interaction in the application-oriented DTF in Figure 9. It contains all dimensions, sub-dimensions and specifications of the previous scientific DTF and uses the same color code to distinguish the three dimensions of value creation.The main difference between the application-oriented DTF and the scientific DTF consists of the decision to structure the framework as a closed-loop model and, in turn, to omit the three-dimensional representation. From a scientific point of view, desirable granularity is lost, but in return, a more operational view could be realized, which brings some advantages in practical use. With this change, further elements, which were missing in the scientific DTF or were only implicitly available, could be added as explicit graphical elements. An apparent addition is the integration of the DT as a prominent separate graphic element. As with the previous framework, many practitioners wondered where to locate the framework’s namesake DT. Furthermore, the framework could be focused even more on value creation by integrating services, the value proposition, and the users for whom the DTs create value. In addition to the user, their interactions via the demanded and offered services, and their optional interpretation of the data was also integrated. In the revised framework, the product life cycle is centrally located, as many practitioners see it as the connecting element of internal and external value creation with DTs. In addition, twelve common activities have been integrated into the product life cycle phases, providing practitioners with the direct link points for the use cases they want to create.

The data resources that flow bidirectionally back and forth between internal and external dimensions, between the DT and the user, and between the data sources (also data recipients) are now visualized with additional graphic elements. Another addition is the smart analysis box, in which applications and tools relevant to the preparation and structuring of data can be visualized. Further additions of technical elements, such as interfaces and connectivity solutions, were omitted in favor of clarity. In the application-oriented DTF, highly relevant elements, depending on the use case, can be easily added during instantiation, just as elements that do not exist or are not relevant can be removed. This makes the application-oriented DTF the required and called-for tool for practice.

A significant change in the designations was made to the “Value Creation Hierarchy” sub-dimension in the scientific DTF, as it became apparent that practitioners did not intuitively understand this. In the application-oriented DTF, this sub-dimension is referred to as “Product Management Hierarchy”, and the top level has been renamed “Portfolio”, as the previous designation “Master” led to confusion, especially among practitioners from the IT sector. The common term “product management” was chosen since most practitioners with whom the research was conducted used a distinctly product-centric vocabulary, even if their companies offer intangible products or even pure services (for example, financial service providers). This is also the reason why the term “product” was kept for the data related to the real-world counterpart, and the term “product” was consistently added to the “life cycle” subdimension.

5. Use Case: Shiptec

The use case presented in this paper is based on the results of the Innosuisse project (35258.1 IP-SBM) about “DT-based services to support decision-making along the product life cycle of capital equipment”, as well as additional interviews and workshops conducted after the project ended. This use case is built around the shipyard Shiptec, which designs, develops, and builds vessels in Switzerland for inland waterways. Shiptec is located on Lake Lucerne in central Switzerland and is the leading Swiss manufacturer of climate-friendly vessels for shipping on lakes. The focus of the use case is the motor ship (MS) Diamant, the first climate-neutral ship in Switzerland, built for the Navigation Company of Lake Lucerne (SGV). Using MS Diamant as an example, we show how the application-oriented DTF can be applied in the Shiptec context to demonstrate its usefulness in practice and thus evaluate the framework (see Figure 10).

The information regarding the actors in the ecosystem was gathered in the Innosuisse project mentioned above and published [91] as part of this project. Further information on the results of the previous project regarding the design of the simulations and the structural approaches can be found in other publications [92,93,94]. Shiptec has already realized several DT-based services described in the following subchapters; further promising approaches are already visible and will be discussed in Section 6.1.

5.1. Product Life Cycle

Shiptec uses DT primarily in the two phases BoL and MoL of the product life cycle. The two activities, resale, and recycling from the EoL phase, are the only two of the twelve activities presented in Section 4.1 in which the DT is not yet used at Shiptec. This is due to the fact that the life cycle of a ship is very long, and it will take decades before a ship accompanied by a DT arrives at the EoL phase. The product life cycle adapted to the use case with ten activities can be seen in Figure 11.

5.2. Real-World Counterpart

The DT analyzed, in this case, represents a system with multiple hierarchy levels. A fleet of ships operated by a navigation company such as SGV represents the highest hierarchy level of the ecosystem in this case. Ships are often operated together, and therefore, Shiptec provides a dashboard to monitor them at the fleet level. However, for this case study, we focused on the value created by the DT on the next lower level, an instance of a single ship. Therefore, the counterpart seen in Figure 12 does not include higher ecosystem levels such as a fleet.

The ship MS Diamant is regarded as a system of systems consisting of different sub-systems. These are the propulsion system, the heating, ventilation, and air conditioning system (HVAC), the command bridge, and the kitchen. These systems interact in different ways, with the central subject being power distribution and consumption on the ship, since the ship generates its power completely self-sufficiently. The propulsion system plays a central role in this task. It can be seen as a small power station that supplies the other systems with power in addition to its primary task of moving the ship forward. Therefore, the remainder of the paper focuses on the propulsion system to outline the structure of the framework. Various connected products from different original equipment manufacturers (OEM) are installed within the propulsion system. In the case of MS Diamant, this includes two ship engines that drive the ship’s propellers via shafts. One shaft-driven electromotor is installed on each of the two shafts, which can also serve as a generator for charging the ship’s batteries. The batteries then provide power for the other systems on the ship, such as the kitchen. All these connected products are equipped with sensors that generate data flowing into the DT of the ship.

5.3. Data Sources

This section describes the data sources, things, external systems, and internal systems as described in Section 4.3 for the specific case of the ship MS Diamant. In the previous section, we introduced four systems forming together the ship as a system of systems. Each of the four systems contains “things” in the form of SCPs equipped with sensors. The data generated by these sensors is sent to a private cloud, where the data is further processed and used by the DT. A typical data flow, as seen in Figure 13, can be illustrated by following the data generated by the smart engines.

The data collected by their sensors is transmitted to the embedded information system of the propulsion system and from there to a gateway, which forwards the data via WLAN or 4G/5G to a private cloud. These data are structured and further enriched in the DT with data from internal and external systems. Regarding internal systems, data from the CRM, the ERP, and the PDM are used and fed into the DT. Furthermore, the data in the DT is enriched with map data, schedules, weather data, and passenger volume on the ships from external systems. The distinction between internal and external data sources is not always evident, as Shiptec and SVG are close partners. Regardless, the overall logic for enriching the sensor data with data from internal and external systems remains the same for all SCPs and systems.

5.4. From Data to Value

This section describes how the data is used to create value with the DT seen in Figure 14. The ship’s onboard systems already structured the product-related data received by the DT. Weather data added from external systems are an example of context data, and data from the internal CRM system are an example of customer data. The data from the three data sources arrive at the DT of Shiptec in various formats. For instance, engine data is structured and can be analyzed and interpreted either by the DT or by human users. The DT uses rule-based algorithms for power consumption optimization. Other services, such as error localization, require additional interpretation by human users using dashboarding tools. In this case, the DT of the ship analyzes data from the operation of the ship in combination with data from internal systems and can thus detect anomalies. However, interpretation by a Shiptec employee is required to locate the error further before taking action. The main interface between human users and the DT is the dashboard, where users can demand services or where services are proactively offered to them by the DT.

In addition, some services, such as schedule optimization for the ship operators, are provided by the ship’s owner, in this case, SVG. Based on these services, the DT provides value propositions on three levels: availability, performance, and quality. The availability of the ship is increased by better adherence to schedules through optimization of ship deployment and fewer unforeseen breakdowns and service operations. Regarding performance, improved energy and fuel efficiency results in a smaller environmental footprint and cost savings. With the help of the intelligent HVAC system, Shiptecs DT optimizes air conditioning to increase passenger comfort and customer satisfaction regarding quality. Concerning smartness maturity, Shiptec covers two of the three in the application-oriented DTF distinguished levels: control and optimization. Currently, the focus is on controlling crucial functions and processes. However, some of the systems are already self-optimizing. For example, the propulsion system self-optimizes the energy and fuel consumption of the ship. The potential further development of the smartness of the DT and the additional services enabled by it are discussed in Section 6.1.

5.5. Role of Digital Twins

As with smartness maturity in Section 5.4, the generational aspect of the DT is not yet fully exploited at Shiptec. However, as visible in Figure 15, all three layers are used to some extent. Shiptecs DT uses current and historical data to control and optimize the ship and generate future-related data, such as predictions used to schedule maintenance and updates. As described in the section on data resources, the DT aggregates data about the current state necessary to control and optimize the ship. Historical product-oriented data, for example, about previous states of the ship, are mainly stored in the ERP and PDM systems. The CRM system contains both currently valid information, such as contact details of the current contact person at the customer, as well as data assigned to the past, such as completed orders.

Type and portfolio of the product management hierarchy are not represented in this case. MS Diamant is a highly customized product and was developed as a unique instance, not derived from a type. However, MS Diamant shares certain aspects and subsystems with other ships previously built by Shiptec. Currently, Shiptec refers to them as sister ships and uses some of the knowledge from their development for future ships, but so far, without explicitly managing them as types.

6. Discussion

This chapter first summarizes value creation with DTs before outlining further developments of the presented use case in a second part. This is followed by a discussion of the contribution to practice by indicating why the application-oriented DTF is useful for practitioners. Finally, we discuss to what extent the calls for a conceptual reference framework for value creation with DTs presented in Section 1.3.2 could be answered.

Value Creation with Digital Twins—DTs are considered integrators of the physical and digital worlds and internal and external value creation. Further, creating DTs requires, by definition, the use of digital data. Hence, the proposed application-oriented DTF includes the following dimensions for every DT: data resources, external value creation, and internal value creation.

Internal value creation—As DTs enable the connection and interaction of internal and external processes and stakeholders, they become the hub of data-based value creation in digitized product service systems. In the dimension of internal value creation, DTs connect the product management hierarchy with the processes that manage their life cycles. In this way, they contribute to reducing and mastering the complexity and variety of variants in the internal value-creation processes. They achieve this by linking the necessary data from isolated internal systems, external systems, and the IoT ecosystem and making it usable through data processing. DTs also enable a generational view of the relevant elements for value creation by storing historical data and making it available for optimizing the present and anticipating the future.

External value creation—The resulting data-based services form the core of the value proposition, which can be communicated to internal and external users. In the dimension of external value creation, DTs connect the SCP, systems, and systems of systems in their use phase with the MoL processes of the providers. They make it possible for these to have “control”, “optimization”, and even “autonomy” capabilities and thus qualify to be described as “smart”. Only through these capabilities do DTs enable providers to ensure that the services they offer create the value promised and agreed upon in the value proposition regarding availability, performance, and quality in real-world use.

Data resources—DTs also enable users to be involved in data structuring and interpretation, for example, making it easier for humans to interpret data by providing optimally prepared decision-making bases. DTs can learn from the interpretation processes and decisions of users and, over time, will be able to interpret an increasing proportion of the data themselves. This ability forms the basis for achieving the “autonomy” level regarding smartness maturity. Overall, DTs have been shown to offer an integrative approach to value creation that includes internal services, market-side services, and comprehensive data provision.

6.1. Value Creation with Digital Twins at Shiptec

As discussed in Section 5, Shiptec does not yet use all elements described in the application-oriented DTF. Therefore, by presenting the use case in the framework and comparing it to the generic version, many options for further development are revealed. Four possible approaches and their benefits for Shiptec and its customers are discussed in this subchapter.

Product management levels—Regarding the levels of product management, Shiptec currently creates value with DTs on only one of the three levels, the instances of the ships. Even though there are already approaches to not only use instances, the product management levels type, and portfolio are currently unused. A phased approach would be beneficial for the introduction of types and portfolios. The next logical step is the introduction of types for the ships, including corresponding subordinate systems and connected products. This would not only unlock potential for future developments but also create additional value for existing instances of ships, for example, by optimizing the management and availability of spare parts. With the introduction of types for specific subsystems, the added value of such an approach could be demonstrated cost-effectively before introducing types at the ship level and later a portfolio of ship types.

Integration into higher ecosystems—With regard to network effects, it certainly would create additional value to not only manage individual ships with DTs but also higher levels of the ecosystem. The next step would be to optimize the fleet management on a lake with the information and knowledge provided by the DTs of the ships. Furthermore, by connecting such DTs of fleets to other smart traffic systems, for example, public transportation providers such as Swiss Federal Railways (SBB), the operation of fleets could be optimized and controlled by DTs across several lakes.

Additional sensor data—Last but not least, the equipment of the ships with sensors and the usage of sensors provided by OEMs is far from being exhausted. In this context, generating additional data with sensors is conceivable in three areas. On the one hand, using sensors that provide additional data on the ship’s critical processes could help to optimize the operation and maintenance, such as vibration or rotation sensors to provide condition-based maintenance. Furthermore, installing additional sensors that detect environmental influences on the ship’s behavior and state could further optimize the journey for crew and passengers. For example, sensors for pollen and other air pollutants could allow the air quality inside the ship to be improved with existing systems. Finally, there are opportunities to attach sensors to the ships to gather data to provide services for external partners. For example, sensors to measure the water quality for the cities or regions in which the ships operate.

Higher smartness maturity—As previously mentioned in Section 5.4, the DT of Shiptec has further potential regarding autonomy and self-optimization. Using data from the propulsion system and the HVAC system, an optimization algorithm could be developed to control the onboard climate system, ensuring optimal conditions for crew and passengers with minimal fuel consumption, while the necessary data is already available, adding more sensors to understand indoor climate and air quality better could help further optimize the crew and passengers’ experience. It is also possible to envision an operation with partial or full autonomy, but this would require the installation of additional sensors to record the surrounding conditions in real-time. This could enable services such as autonomous docking and undocking of ships.

6.2. Contribution

In this subchapter, the contribution to practice and science is discussed. The focus of an application-oriented framework is inherently on its usefulness for practice. However, the developed application-oriented DTF also contributes to answering the calls presented in the introduction for a conceptual reference framework for value creation with DTs, which are explained in the second section of this subchapter.

6.2.1. To Practice

The application-oriented DTF contributes to practice by providing utility for practitioners as an artifact for communication and as a tool for specific challenges in corporate innovation processes regarding systematic value creation with DTs.

For communication—Apart from technical challenges, the successful implementation of DTs requires a holistic understanding of external value-creating ecosystems, internal value creation with PLM of products and services, and data resource management. The application-oriented DTF enhances an individual’s understanding of the relation and context of DT-based innovation by providing a holistic and comprehensive systematization of these interrelationships. The division into dimensions and specifications and the compatibility with the scientific DTF suit it well for designing courses for the education and training of employees and customers. The application-oriented DTF supports practitioners in positioning and structuring their DT activities and communicating them to internal and external stakeholders. It helps break down complex projects and challenges into units that are easier to communicate, understand, and handle. It contributes to creating a shared big-picture, common sense, and language and thus the trust needed to allow experts from various fields to focus on their work efficiently.

As a tool—Furthermore, the application-oriented DTF can be a helpful tool in every phase of an innovation project. In the early phases, it is suitable to define the level of sophistication of the DT required to create value in the respective use case in the early stages of a project. It can be used, for example, for understanding the needs of the users of the system being created and for conceiving, agreeing, defining, and documenting the processes and design of the system together with them. The application-oriented DTF thus facilitates innovation teams to decide which data their SCP must provide for the DT to fulfill the needs of a particular business process or use case to create intended value. Subsequently, the systematic consideration of the data resource dimension enables one to derive the data required for desired applications or to derive further possible applications from already existing data. The application-oriented DTF also facilitates keeping an overview for the project leader and ensuring that the developed objects behave as planned. Even after the innovation enters the market introduction phase, the instantiation of the framework tailored to the use case is practical, for example, as a basis for pitch and sales decks. If an innovation project or use case is documented with an instantiation of the application-oriented DTF, it enables systematic classification and comparison with other use cases. It also simplifies further development at a later point in time and ensures long-term consistency, for example, when the next generation is to be developed.

The instantiation of the application-oriented DTF for the use case presented also contributes to practice as it illustrates how a traditional product can become a SCP, which, combined with a DT, becomes a product-service system and thus enables services that create value. Moreover, the example from public transportation is familiar to many, which allows the basic systematics and logic of value creation with DTs to be demonstrated understandably.

Closing knowledge gaps—As stated at the beginning of this paper (cf. Section 1.4), the knowledge gap in practice consists of a lack of tangible understanding of the scale and nature of value creation with DTs. Therefore, companies seek tools to evaluate, compare, and communicate different types of DTs (e.g., level of authenticity), their impact, value creation, and ideal application in their service business model and across the value chain. The application-oriented DTF presented here significantly contributes to closing this knowledge gap in practice. In particular, as explained in this chapter, it facilitates communication with internal and external stakeholders on creating value with DTs during different project stages. Finally, with its modularity and adaptability, the application-oriented DTF is a valuable tool for evaluating, comparing, and optimizing different projects and use cases.

6.2.2. To Science

Many authors have called for a shared definition and a suitable conceptual reference framework to fill the research gaps described. Therefore, the extent to which the proposed application-oriented DTF can answer these calls is considered. Through the holistic and structured consideration of all dimensions of value creation with DTs, by integrating the value proposition, service scopes, and users, the call by Meierhofer and West [45] could be answered. The graphical representation answers the call by Sjarov et al. [24], who hoped that such a representation would bring clarity and systematics to this complex and multifarious topic. The rigor in considering the academic knowledge base and consolidating it with practitioners’ perspectives responds to the call by Jones et al. [39] for a shared understanding and terminology. In particular, the application-oriented DTF was designed to meet the requirements identified at the outset by being sufficiently abstract in terms of research requirements to answer the call of Sharma et al. [35] for a universal DT reference framework and yet intuitive and easy to use in terms of practical requirements, thus filling the gap described by Nyffenegger et al. [42]. The common terminology and understanding underlying the scientific as well as the application-oriented DTF can also serve as a basis for developing interoperable DTs, as called for by Boss et al. [38]. Further, the application-oriented DTF is a useful tool as a reference point for communication in project teams, answering the call of Agrawal et al. [40]. Finally, as it is based on scientific rigor and the preceding scientific DTF, it contributes to answering the call from Singh et al. [13] for research-based architectures. In summary, it can be deduced that the proposed application-oriented DTF, which is compatible and consistent with preliminary work, contributes to answering the calls for a unified and common view of value creation with DTs and a corresponding conceptual reference framework.

7. Conclusions

To conclude the paper, the achievement of the set objectives will be shown. Then the limitations are acknowledged, and further research directions are outlined. Finally, an outlook on the further development of DTs in practice is ventured.

7.1. Objectives Achievement

The main objective of this research was to develop and evaluate a valuable artifact for research and practice in the form of an application-oriented conceptual reference framework for value creation with DTs. The application-oriented DTF developed aims to give practitioners a profound understanding of the underlying architecture of DTs and provides practical ways to integrate DT models that organically create internal and external value. The instantiated application-oriented DTF is an artifact constructed for the use case, which embodies the knowledge collected in the case study project about problems and solutions in the analyzed system. It is an illustrative example of how a product can become a SCP, which, combined with a DT, becomes a product-service system and enables services that create value. Furthermore, the instantiation allows practitioners to use the application-oriented DTF to conceptualize their applications for creating value with DTs. The application-oriented DTF and its instantiation for the case study thus contribute to closing the gaps in research and practice identified in the Introduction. They contribute toward a common understanding of the DT and develop the theoretical foundation of the concept while providing practitioners with a profound understanding of the inherent structuring dimensions of DTs. This is done, firstly, by providing an artifact that conveys the fundamental principles, basic functionality, and significant relationships among the entities of the value creation with DTs in an abstract, universal form. Secondly, it can be instantiated for specific applications and be used as an individual reference framework and means of communication for projects in research and practice. Accordingly, it contributes to answering the initially mentioned calls for conceptual reference frameworks for value creation with DTs.

7.2. Limitations

A conceptual reference framework is a simplified representation of reality in that it reduces the complexity of reality to present a topic in a comprehensible and communicable way. Consequently, it does not include all the attributes of the actual phenomenon but only those that seem relevant. It is unavoidable in the design cycles that subjective influences come into play, especially in identifying meta-features and constructing the dimensions used. Since the focus in developing the application-oriented DTF was to consider practitioners’ collected input and perspectives, there are corresponding constraints. For example, the three-dimensional representation of the scientific DTF was omitted to meet the demand for a more straightforward, intuitively understandable representation. Through this omission, interrelationships in the individual dimensions are lost. Therefore, the application-oriented DTF can claim less of a complete mapping of the dimensions of value creation with DTs. On the other hand, the application-oriented DTF could be supplemented with elements that increase its usefulness in practice, as they enable a more operationalized representation. Furthermore, the application to the use case has shown that a representation chosen for the application-oriented DTF can easily be supplemented with additional elements or specifications if required. Such additions could be, for example, the connectivity solutions used or additional levels in the system hierarchy. Conducting an individual case study has the advantage that a use case can be examined in depth and detail. However, this also results in limitations. The most critical limitation is the constrained generalizability of the findings and the created instance of the application-oriented DTF. Even if it is assumed that the basic mechanisms of value creation with DTs are transferable to other cases, it is unclear how similar these use cases must be. Furthermore, no statements have been made about the economic viability of the project or the commercialization of the created value. Therefore, whether an equivalent development of DTs is worthwhile for other companies from an economic point of view cannot be answered.

7.3. Further Research

An artifact may have utility because of some yet undiscovered truth, and a theory may yet be developed to the point where its truth can be incorporated into its design [52]. In both cases, research assessment via the justify/evaluate activities can result in identifying weaknesses in the theory or artifact and needing to refine and reassess it. The recommended directions and avenues for future research leading to such a refinement and reassessment process are described here.

The application-oriented DTF will be instantiated for a variety of different use cases. Therefore, the usefulness of the created artifact will be further validated, and the approach to deducting specific instances will be further investigated. A larger number of instances will provide further insights into how the generalizability and insatiability of the application-oriented DTF can be further improved through extensions and adaptations. The generalizability of the application-oriented DTF to different industries and products must be examined in more detail and encompassing ways. Of particular interest in this regard is investigating which products, industries, and economic ecosystems are particularly well suited for value creation with DTs and the application-oriented DTF. Another critical research topic regarding generalizability will be validating the link between external and internal value creation and the associated data resources. To foster the suitability of the application-oriented DTF to be used in practice as a tool for innovation projects, developing a workshop methodology and analyzing complementary tools and concepts should be considered. Two different directions are of particular importance concerning the instantiation of the application-oriented DTF for use cases. The first is that tools and guidelines must be developed to simplify the correct instantiation of an existing case. The second is the need to develop tools and methods that simplify the further development of an existing case.

The development of suitable revenue and business models was outside the scope of this research project but remains an essential aspect of future research. Due to the progression of value and the permanent customer relationship via DT, innovative billing models such as pay-per-use or pay-per-value seem imperative.

7.4. Outlook

In a 5G world with edge computing and smart networks, everything becomes a “thing”, and everything generates data. DTs are thus expected to be used broadly across industries in the coming years for multiple use cases. In logistics, manufacturing, and supply chains, DTs, combined with machine learning and advanced network connectivity, will increasingly track, monitor, control, and optimize the flow of goods and information worldwide. The ultimate goal is to have sophisticated DTs that are self-adaptive and can evolve themselves over time and undertake decisions and actions without human intervention—not only for simple tasks, but also for complex tasks where not all interdependencies are known or which are too dynamic to be managed, if the DT is not autonomously learning and self-adapting.