Methodology for Digital Twin Use Cases: Definition, Prioritization, and Implementation

The cross-industry concept of Digital Twin promises numerous beneﬁts in areas such as product customization and predictive maintenance, but many companies often struggle to determine a starting point. Digital Twin use cases are abundant, but efforts and stakeholder beneﬁts are difﬁcult to estimate when developing and implementing Digital Twin applications. This paper proposes a management approach to Digital Twin use case prioritization suitable for planning Digital Twin applications at an early phase of development. Considering stakeholder satisfaction, infrastructure scalability, and effort for implementation and maintenance, we present a methodology to determine the most impactful Digital Twin use cases requiring low effort and high scalability. Tools and related methods from the ﬁelds of software development, innovation, process engineering, and product development are described, and the methodology is discussed with regard to these and other research works. An example from mechatronic product development at Siemens Healthineers Innovation Think Tank validates the approach.


I. INTRODUCTION
The Digital Twin (DT) concept consists of a physical entity and its digital representation, which evolves with its physical twin through real-time connection and provides additional value [1].The concept promises to efficiently solve physical issues, predict potential outcomes, help to design and manufacture better products, and create additional value for its customers [2].While many potential benefits are anticipated across industries, it is still difficult to estimate and balance the effort needed to develop and implement a Digital Twin concept and the value it creates [2], [3].An allembracing and in-depth Digital Twin implementation entails high costs and significant effort [4], [5], and is likely not to address any objective sufficiently [6].Therefore, the trend is to start with the use cases that create the biggest value The associate editor coordinating the review of this manuscript and approving it for publication was Yang Li . in the shortest amount of time [2].Current research does not provide approaches to derive impactful Digital Twin use cases for stakeholders and evaluate them for prioritized development.While methodologies exist, for example, for prioritizing software development features, innovation projects, manufacturing data sources, and product features in product development, they have limited applicability for Digital Twin use cases.
The versatile, cross-industry character of the Digital Twin concept makes it difficult to define a universally applicable methodology for deriving and prioritizing Digital Twin use cases.We propose a two-step methodology that, in the first step, derives promising Digital Twin use cases and evaluates their value, and in the second step, evaluates their efforts and scaling potential.
For deriving promising Digital Twin use case opportunities, we see the life cycle aspect of the physical entity as the backbone for broad Digital Twin applications, as advocated by Parrott and Warshaw [2].Our methodology derives and evaluates use cases based on the value-receiving stakeholders' ratings along an entity's life cycle.Other solutions than Digital Twin use cases might address the needs better and are also considered.The needs where Digital Twin use cases seem to be the best solution are taken into the second step of our methodology.
We see data as playing an essential role in estimating Digital Twin applications' effort and scaling potential.Collecting data sooner than later is critical in developing a Digital Twin service to a product.Not just having more but better data reduces developing costs and increases the value-add for the customer and user.The business value and the effort of a Digital Twin use case depend on the data driving the use cases.Therefore, the value of the use cases depends on the value of its data.The data value is not determined by the amount of data but by the importance and number of use cases driven by the data and the data's informational value of those use cases [7].To approach this interdependence of use cases and data, the second step in our methodology identifies the data sources that enable most of the impactful use cases and require the least effort for implementation.This value is fed back to the evaluation of the use cases.Besides data, infrastructure effort and scaling potential are considered in the use case evaluation.
No other methodology has yet been introduced that addresses these Digital Twin aspects.The methodology proposed in this article reduces uncertainty in developing Digital Twin applications by serving as a guideline for practitioners to determine the most promising Digital Twin use cases for their product.
In the following, we analyze existing use case and other prioritization methodologies that impacted the development of our methodology.We present in detail our methodology in its two steps, followed by a validation of the methodology on a mechatronic product development case study.We discuss and compare the methodology with methodologies from other fields, its standing in Digital Twin research, its limitations, and future steps.

II. RELATED WORK
This article is related to use case prioritization in the field of Digital Twin.Other use case prioritization methodologies in the field of Digital Twin were not found, which is why we describe use case prioritization methodologies from different fields and other supporting methods.These methodologies (Table 1) influenced the development of our use case prioritization methodology.
Use cases describe user requirements by placing them in a usage context.They consist of a sequence of events that create value for the user [15].Jacobson et al. introduced use cases in 1992 [16] as a tool to make software development more requirement-oriented.The term and concept have since received wide attention inside and outside software development.We use them in this article to describe Digital Twin applications and their requirements in a usage context.
According to Kundu and Samanta [9], use case prioritization follows a quality and business goal.When prioritizing use cases at an early development stage, more effort can be put into developing the most promising use cases, thus achieving higher quality results.Secondly, prioritizing the most promising use cases results in greater user satisfaction earlier, thus driving business.
Moisiadis [8] proposes a two-level use case and scenarios prioritization methodology for software development, considering business goals of the stakeholders, dependencies among the use cases, the satisfaction degree of each use case to the business restrictions and goals, and critical objects and actors per use case.The first level rates the use cases by their ability to satisfy the stakeholders' business and functional goals to reduce the number of use cases considered in the second level and focus only on the most important use cases from a stakeholder perspective.The second level prioritizes the steps within the important use cases by the involvement and usage of actors and objects in each step.The most important steps of the important use cases require special attention in the software development cycle.[9] present a three-step methodology for use case prioritization in software development.In contrast to Moisiadis [8], they design their approach to be free from any personal influence.Their three-step methodology converts use case scenarios into a system sequence diagram and then into scenario graphs, which are analyzed for the criticality of the scenario paths.The methodology's outcome is a ranking of use case scenarios achieved by sole computing.

Kundu and Samanta
Ulwick [10] proposes a tool to prioritize product features based on customer goal importance and outcome satisfaction.To develop innovative products, Ulwick emphasizes the importance of inquiring from customers about their desired outcomes, not solutions.An algorithm rates these outcomes by considering the importance of an outcome for the customer and how satisfied the customer is with the current solution.The outcomes with high importance and currently low satisfaction solutions receive prioritized development.
Haider [11] first applied the Innovation Think Tank (ITT) methodology in 2005.The methodology supports innovative product development by considering stakeholders through the entire development process.It consists of four main steps: Acquire mandate and plan, big picture analysis, co-creation on decision proposition, and deploy commercialization.The authors analyzed radiology departments' challenges and solutions [17], among others.
In engineering, identifying potential failure modes in manufacturing processes and determining the most critical ones is commonly assessed using the Failure Mode and Effects Analysis (FMEA).An FMEA identifies ways of potential failure of an item or process by systematically evaluating them and their effects on themselves and their environment and personnel.Considered factors are the probability of the failure mode, the severity of its effects, and the likelihood of its detection.For critical failure modes, remedies are developed, and their impact on these three factors is reevaluated until all critical failure modes are addressed sufficiently.The Process FMEA (PFMEA) methodology takes a process as a starting point, subdivides it into smaller steps, and determines potential failure modes along with these steps.The PFMEA was first applied to manufacturing but has since caught wider attention in other fields, such as healthcare, where it is used to analyze medical procedures [12].
Quality Function Deployment (QFD) is a method for translating customer wishes and requirements into a company's concrete services and functions of a product [13].In several steps, this method derives from a single customer requirement which product feature, function, or performance characteristic must be designed, modified, or improved to meet customer requirements.The method initially developed by Akao in Japan in 1966 [18] combines the customer requirements with the technological features in the House of Quality (HoQ), an interactive matrix.The output of this matrix are the most important technological features on which to focus from a customer satisfaction point of view.While the tool was initially developed for product design and quality management applications, the QFD has since found numerous other fields of application [13].
Stanula et al. [14] propose a methodology for efficient data source selection for machine learning applications in production.The approach translates business objectives into failure modes using the PFMEA and consults a cross-functional panel of experts to assess the data source correlation with the failure modes by applying the QFD.The outcome is a selection of data sources with a high likelihood to bear information regarding the business objective when used as an input for machine learning analyses.
The multinational professional services network Deloitte proposes a circular methodology to getting started with Digital Twin applications (Figure 1).The methodology describes how to start and scale up Digital Twin applications in six circular steps [2].
In its first step, ''Imagine,'' the goal is to ''Imagine and assess process opportunities for the digital twin.''Even though scenarios may differ for every application, two key characteristics are likely to play a major role in the scenario assessment.Firstly, the physical entity and feature of interest are valuable enough for a Digital Twin application.Secondly, potential value exists from outstanding, unexplained issues that could be leveraged for stakeholders.
The following ''Identify'' step determines the most suitable Digital Twin application out of all the potential opportunities assessed in step one.Parrott and Warshaw [2] suggest considering operational, business, and organizational change management factors while focusing on areas with the potential to scale across technologies, equipment, or sites.Furthermore, they advocate broad Digital Twin applications over deep ones, as they tend to drive most support and value.
In the following steps, Parrott and Warshaw [2] propose to pilot early value-creating Digital Twin applications, industrialize the Digital Twin development and deployment process, scale the Digital Twin application to connected and similar scenarios, and finally monitor and measure the impact and outcome of the Digital Twin application.
As shown in Figure 1, the process intends to be conducted circularly, identifying improvement potentials and new opportunities across application areas.Our proposed methodology supports the first two steps, ''Imagine'' and ''Identify,'' by systematically deriving potential Digital Twin applications, rating them by estimated value creation, and assessing their scaling potential and effort for implementation.The Digital Twin concept holds great potential across industries and product lifecycle stages.Despite the abundance of opportunities for Digital Twin applications, practitioners still struggle to identify useful use cases and derive the most promising use cases to start with.Even though methodologies for identifying aspects of interest exist in various fields, these methodologies do not consider the interdependencies of Digital Twin use cases and data sources and the implementation infrastructure with its scaling potential and efforts required.Our methodology addresses this need by starting from a customer-centric need and satisfaction evaluation.It identifies use cases where a Digital Twin is the most promising solution.It then evaluates potential data source and other infrastructure setups regarding their scalability and effort and finally determines the most promising Digital Twin use cases to start implementation with.

III. METHODOLOGY FOR DIGITAL TWIN USE CASE DEFINITION, PRIORITIZATION, AND IMPLEMENTATION
This section describes our proposed methodology, which supports the definition, prioritization, and implementation of Digital Twin use cases.The methodology combines software development, innovation, process engineering, and product development methods and adds the evaluation of efforts and data source interdependencies, which characterize Digital Twin use cases.
Our proposed methodology can be located in the imagine and identify phases of the Deloitte Digital Twin development cycle (see the top of Figure 2).Understanding the physical entity of interest and its application environments is essential to derive and evaluate digital twin use cases.It is mentioned as the initial step for the imagine and identify step.The overall methodology is then subdivided into two levels, A and B. The first level, A, is situated in the imagine phase.It derives the most promising use cases for applying the Digital Twin concept by considering market needs and the ability of use cases to address these.The second tier, B, is located in the identify phase.After an initial data source preselection, it further elaborates and evaluates the selected Digital Twin use cases by identifying the most impactful data sources and the efforts associated with a use case implementation.The outcome is a selection of use cases and data sources to start with in the pilot phase.
Figure 2 shows our general approach with the UCMEA (A) and House-of-DT (B) as center elements, placed within the Deloitte Digital Twin development cycle.
Following, we describe the methodology in theory, but we recommend taking a look at the example and figures in the validation case study section for a deeper understanding.

A. USE CASE MODE AND EFFECTS ANALYSIS (UCMEA)
Zborowski [19] mentions the unprofitable endeavor of creating a Digital Twin of an entire machine.General Electric's (GE) oil field services company Baker Hughes (BHGE) focuses on building high fidelity Digital Twin applications only of the parts which have a higher probability of failing than others [19].This example of predictive maintenance as the main application of Digital Twin use cases focuses on the greatest value-add for the stakeholder by considering the parts most likely to fail.Our methodology focuses on the greatest value-add for stakeholders in Digital Twin use cases, including predictive maintenance.
We propose the Use Case Mode and Effects Analysis (UCMEA) as a methodology to develop use cases and rate their business potential.A schematic overview of the six major steps is visualized in Figure 3.
the wider the scope of use cases and the higher the potential for detecting synergy effects and scaling potential.In the case of a product, processes can be considered along the entire product life cycle.

2) NEEDS & OPPORTUNITIES & STAKEHOLDER IMPORTANCE
After defining a process or workflow of interest, the next part of the UCMEA uses and takes inspiration from the ''Opportunity Scoring'' method developed by Ulwick in the 1990s [21].This next step in the UCMEA describes user needs and opportunities along the targeted process.Needs can be pain points that create discontent in the current process.Opportunities can be potential improvements that could create additional value in the current process.These needs and opportunities ideally reflect the viewpoint of as many stakeholders as possible to consider and evaluate use cases from different fields and identify scaling potentials.Alternatively, user needs and opportunities can also be considered separately for each workflow and stakeholder by conducting the method individually with the respective stakeholder group and merging the results later.To keep the solution space open to all kinds of solutions, the needs and opportunities should be defined solution unspecific.
As in Ulwick's [21] ''Opportunity Scoring'' method, the user needs and opportunities for specific stakeholders are rated by their importance for each stakeholder individually.The more often a need or opportunity presents itself within the respective process, or the greater the perceived gap in revenue or effort, the higher the importance rating (1-10) of a need or opportunity for a specific stakeholder.All scaling within this methodology should be defined equally for all workflows and stakeholders within one assessment.
The gap between importance and satisfaction is then calculated by subtracting the satisfaction value from the importance value.The gap value can never be less than zero to consider important use cases for future solutions, as discussed by Ulwick [21].

4) NEED/OPPORTUNITY SCORE
The overall Opportunity Score of a need or opportunity, as to Ulwick [21], is calculated by adding the importance and gap value.The more important a need or opportunity is for a stakeholder, and the greater the satisfaction deficit, the greater the opportunity.

5) USE CASE SOLUTIONS & SATISFACTION RATINGS
Following the need and opportunity analysis, use case solutions are ideated, which address the mentioned needs and opportunities.A preselection can be done by only ideating use case solutions for needs and opportunities with at least a certain Opportunity Score.More than one use case solution can address a need or opportunity, but each use case solution takes up a separate row.Every use case solution is described shortly.Digital Twin use cases can be described by their scope of the physical entity, the feature of interest, and the user-specific output/value created, as proposed by Newrzella et al. [1].Further specifics will be defined in the House-of-DT based on the infrastructure availability.
Next, we estimate the anticipated stakeholder satisfaction for addressing the need or opportunity with the ideated use case solution.Ideally, this estimation is verified with the stakeholders addressed.Pairwise comparison, repeat pairs techniques, and other methods can be used to support this step.The increase in satisfaction from the current solution to a potential use case solution is calculated by subtracting the status quo satisfaction value from the anticipated use case solution satisfaction value.

6) USE CASE IMPACT SCORE
Finally, we calculate the Use Case Impact Score by adding the Satisfaction Improvement to the stakeholder's importance value of the addressed need or opportunity.The Use Case Impact Score is higher the more important the addressed need or opportunity is for the stakeholder and the better suited the use case is for addressing it.Depending on their score, these need/opportunity-based and rated use cases receive prioritized development.Among the different solutions, Digital Twin use cases can be transcribed into the House-of-Digital Twin methodology (House-of-DT) for a scalability and effort analysis.
For the use case solutions using other technologies, techniques, or concepts, further use case elaboration, visualization, and evaluation can be conducted using other methods.

B. HOUSE-OF-DIGITAL-TWIN (HOUSE-OF-DT)
The House-of-DT's structure is based on the House of Quality, a part of the Quality function deployment (QFD) method.We use the interactive matrix approach of the House of Quality to quantify the interdependencies between Digital Twin use cases and data sources.
Furthermore, our methodology takes inspiration from the data source selection methodology for machine learning applications in production [14] and applies it to the cross-industry field of Digital Twin.Stanula et al. [14] apply the House of Quality approach to quantify the interdependencies between failure modes and data sources in production, with the aim to analyze issues using Machine Learning algorithms.We broaden the approach by considering all kinds of Digital Twin use cases, including failure modes, and include effort estimations to implement these use cases.The House-of-DT can be subdivided into four side parts and the center, conducted consecutively, as depicted in Figure 4.It can also be divided into two interconnected dimensions, the use cases, and the data sources, the ''what'' and the ''how.''Data sources drive use cases, and the value of data sources is determined by the use cases they enable.After being primarily rated in the UCMEA, Digital Twin use cases come in from the left and leave to the right.Data sources come in from the top and leave towards the bottom.Their interplay is evaluated in the center so that each dimension is rated by its ability to benefit from the other.

1) DIGITAL TWIN USE CASE INPUT
In the first step of the House-of-DT methodology, the minimal rate at which the individual use cases are updated is assessed.This rate refers to the lowest frequency at which value is still created for the stakeholder.

2) DATA SOURCE INPUT
Subsequently, data sources of interest for the Digital Twin use cases are introduced in step two.Preselection of data sources can be conducted to limit the total number of data sources to those related to the use cases.The Delphi method can be used to reduce the number of data sources to the most promising ones.
The data source dimension is defined by the scope of the physical entity of the Digital Twin.The broader the scope of the physical entity of the Digital Twin, the more local data sources can be considered.The data sources under consideration for the Digital Twin use cases are listed in the upper part of the House-of-DT.To consider data sources from different origins, we propose categorizing them into three categories ''Physical entity,'' ''On-premise,'' and ''Off-premise'' data sources.''Physical entity'' data sources refer to data sources located right on or in the physical entity under consideration for a Digital Twin.''On-premise'' data sources are located close to the physical entity, such as in the same local area network, and therefore provide low latency communication and can provide higher data security and privacy standards if kept on a local level.''Off-premise'' data sources are often connected via the internet and have higher latency communication and data security and privacy concerns.These data source clusters are not conclusive and intend to broaden the view on potential data sources.Not yet available data sources can be considered if the available data sources do not have sufficient informational value for the use cases of interest.
Above the data sources, interdependencies between the data sources are analyzed.Data sources that complement each other are marked as such, and redundant data sources are highlighted.This information is later considered in selecting data sources for specific use cases.
Each data source's maximum possible frequency achievable is noted in the row below the data sources.This frequency refers to the sources only, without, for example, connection to the next processing unit.

3) USE CASE-DATA SOURCE INTERDEPENDENCIES
In step three, in the grid in the center of the House-of-DT, Digital Twin use cases and data sources are linked by evaluating each data source by its informational value for each use case.The better a data source is suited for supporting a use case, the higher its informational value for that use case, and the higher its rating (1)(2)(3)(4)(5)(6)(7)(8)(9)(10).If a data source holds no informational value for a specific use case, no rating is done.

4) DATA SOURCE ASSESSMENT
Following, all data sources are evaluated by their potential to scale.This evaluation is achieved by considering the number of use cases a data source can drive, the informational value a data source holds for all use cases, and the opportunity score of each use case it can drive.The scaling potential value of a data source is calculated by the sum product of each use case Opportunity Score and the informational value of this data source regarding the individual use case.The Scaling Potential is higher the more use cases a data source can support, the higher the informational value it holds for all use cases, and the higher the opportunity score of all use cases a data source can drive.
In the next step, the data source implementation and data collection effort is evaluated.Data source implementation focuses on the effort needed to include a data source in or on the physical entity (rating from 1-10).Suppose a data source is not implemented in the current product, and extensive effort is required in redesigning the product and implementing the data source.In that case, the data source gets a high implementation effort rating.A data source already included and available in the current state of the physical entity receives a low effort rating.
Data collection effort emphasizes how much a data measurement process interferes with a workflow.The more negative impact a data collection process has on the workflows around the physical entity, the higher its data collection effort rating (1-10).
The total effort rating for a data source is calculated by adding both implementation and collection effort values.
Concluding the data source assessment, a data source's total data source rating is calculated by dividing its scaling potential by its total effort rating.The more scaling potential a data source has and the lower the effort for its implementation and data collection process, the higher its overall data source rating.The total data source rating supports decision-making for data source selection within the design stage of a Digital Twin-related product concerning future compatibility with Digital Twin use cases.

5) USE CASE EVALUATION
Before continuing with the use case evaluation on the right side of the House-of-DT, a selection of data sources for each use case is made.For each use case, a selection of data sources is made that could be used to drive the use case.Factors contributing to this selection can be informational value, data source interactions, scaling potential, and effort for implementation and data collection.The following steps are conducted only for each data source selection.If required, data source selections can be changed later.The right side of the House-of-DT then must be redone with the new selection.
First, in the use case evaluation, a data source selection is checked for achieving the minimum needed information frequency required by the use case.This step serves as a first feasibility check for the data source selection.Not every data source has to provide a use case's minimum needed information frequency.Still, the use case-specific data source selection must be able to provide the required information at the required frequency.
Following, the average detectability score of the data source selection is calculated.This score showcases the ability of a data source selection to describe the matter of a use case.
Afterward, the average scalability score of a data source selection is assessed.This assessment is done by calculating the average scalability score of all data sources in the selection for the individual use case.The more impactful use cases a selection of data sources can describe well, the higher its average scalability score.
To assure equal contribution to the overall assessment, the average scalability score of each data source selection is normalized to the scale from 0 to 10, with 10 being the maximum use case scalability average of all use cases.
The setup section asks fundamental questions based on the previous analysis to estimate the efforts needed for a Digital Twin use case.The data source selection and information frequency enable theoretical use case development.The following setup details are considered: Whether data from outside the physical entity is needed; Whether safety, security, or privacy concerns apply to the use case and its data; What kind of model is fed with the data; Whether the use case is updated in batch, semi-batch or real-time; Whether cloud or on-premise computing is considered for the use case.
Having the setup in mind, the effort section estimates the required effort for use case implementation and maintenance based on the data collection/integration layer, communication & data management layer, and information & functional layer.
The data collection/integration layer refers to the physical nodes in the physical entity, such as sensors and low-level interfaces for data communication.The communication & data management layer is responsible for node-to-processor coupling, local-to-cloud link, DT-to-DT link, and the respective contextualization and management of the data.The information & functional layer considers data modeling, DT services, and potential human-machine interfaces.
Some effort for implementation and maintenance is required once and does not have to be repeated with additional use cases.These efforts scale with use cases and are considered by their respective use case scaling ratings.A use case scaling rating of one refers to an effort only applying to one use case, two applies to two use cases, three to three use cases, and ten to ten and more use cases.The adjusted effort equals the effort estimation divided by the use case effort's scaling potential.
The total effort is calculated by summing up the adjusted effort values of all three layers.
The Use Case Applicability Score is determined by multiplying the Use Case Impact Score with the average use case detectability score and the normalized average scalability score of the use case's data source selection and dividing it by the total accumulated estimated effort of the use case.
For ease of comparison, the Use Case Applicability Score is normalized so that the highest value among all use cases is 10.The Normalized Use case Applicability Score is a comparative rating between use cases.Use cases with high scores among the analyzed use cases are the most recommendable use cases for implementation, with the relatively best ratio of high expected value created, high scalability potential, and low effort for implementation and maintenance.
The overall methodology gives the practitioner a tool at hand to define, prioritize, and implement Digital Twin use cases.The UCMEA defines general use cases for innovative product solutions along selected phases such as the entire product life cycle and determines the use cases with the highest impact on stakeholders.Selected Digital Twin use cases can be further elaborated and evaluated in the House-of-DT, considering impact, scalability, and effort for data sources and other infrastructure.Succeeding the detailed introduction of the methodology, we present a case study to validate its applicability.

IV. VALIDATION CASE STUDY
The proposed methodology was validated by a product development application in the field of mechatronics at Siemens Healthineers Innovation Think Tank.The methodology application on this product aims to increase its value for its stakeholder in its usage context by enriching its mechatronic functionalities with Digital Twin features.In this case, the product is a medical mechatronic product in its clinical application field.The methodology is conducted, and its suitability for Digital Twin use case definition, prioritization, and implementation is shown.

A. USE CASE MODE AND EFFECTS ANALYSIS (UCMEA)
As the first step of the UCMEA, processes of interest for the Digital Twin application were defined.Usage processes in a radiography workflow, device maintenance, and lifecycle integration were selected, and sub-steps were defined where applicable.This case study has taken into consideration numerous hospital visits with questionnaires and analyses by the ITT team over the last 15 years.Along the process substeps, stakeholder needs and opportunities were allocated, and the affected stakeholders were defined.Stakeholders were selected from the device's clinical usage and engineering development phase.Stakeholders considered were technologists, nurses, physicists, administrators, and device manufacturers.Other stakeholders have not been specified in this analysis.The stakeholder-specific importance of each need and opportunity was rated, the current solutions were described, and the stakeholders' satisfaction ratings with the solutions were quantified.Documented solution-unspecific quantitative pain points and recommended improvements from the questionnaire ratings were implemented as importance ratings in the UCMEA.Solution-specific ratings were attributed to the status-quo solution satisfaction of the stakeholders.After calculating the need/opportunity score of each need and opportunity, use cases for each need and opportunity were ideated and described.Use case solutions were proposed mainly from the field of Industry 4.0.
More than 30 use case solutions for needs and opportunities were found.The respective stakeholder's satisfaction with the use case solutions was estimated, and each use case's impact score was calculated.The Digital Twin use cases with the highest impact scores were selected for further analysis within the House-of-DT.Non-Digital Twin use case solutions were not considered further in this case study.Exemplary use cases and their solutions and ratings are displayed in Figure 5.

B. HOUSE-OF-DIGITAL-TWIN (HOUSE-OF-DT)
More than 10 Digital Twin use cases along the entire life cycle of two medical mechatronic machines were considered in the analysis.An exemplary House-of-DT with anonymized Digital Twin use cases and sources is shown in Figure 6.Device Y refers to a mechatronic subsystem of the entire medical system.Component X is a part of that subsystem that was analyzed in more depth separately.
The selected Digital Twin use cases and their impact scores from the UCMEA were placed in the left part of the House-of-DT, and the minimum needed information frequency of each use case was defined.
Data sources from the mechatronic systems of interest were derived from the product development documentation.A preselection was done by eliminating irrelevant data sources.The resulting selection of data sources was filled into the top part of the House-of-DT.Data sources were divided into physical entity, on-premise, and off-premise data sources.The maximum possible data amount/frequency was noted for each data source, and dependencies and redundancies between all data sources were assessed.
In the center matrix, we combined Digital Twin use cases with data sources.Each use case was matched with each data source that possibly holds informational value about the use case.The higher the informational value of a data source for a use case, the higher the detectability score.Within our example, the motor current data of component X holds great informational value on the state of component X and therefore gets a high rating for that use case.The motor current and motor timing also hold information about certain technologist workflows but only certain parts of it, so it receives a lower rating for that use case.Instead, the user input data holds great informational value about technologist behavior and device workflows and gets a high rating for those two use cases.
The potential to scale of each data source was calculated by combining use case impact scores and informational values of all use cases that a data source can describe.In the following step, the data source effort for each data source was estimated.The data source implementation and data collection efforts were rated, summed up, and normalized.By combining potential to scale and total normalized effort, each data source's total data source rating was calculated and normalized across all data sources.The user interface (UI) user input holds the greatest potential for our Digital Twin use cases selection in our example.It can be used for two out of the three exemplary use cases and needs little effort for implementation and data collection.The motor current is only mostly useful for one use case and is therefore rated lower.Making the UI user input data available for Digital Twin use case applications should receive higher prioritization than other data sources.
After the completed data source assessment, data source selections were made for each Digital Twin use case.Each selection considered the use case information and data source data frequencies, data source dependencies and redundancies, informational values, and data source ratings.These selections were used for further use case evaluations.In our example, for the DT of technologists for custom operator training with device Y, the UI user input data and the movement patterns of the radar sensor are selected.
A reality check was conducted concerning the required information frequency before starting the use case evaluation with specific data source selections.Data source selections that could not provide an information frequency equal to or higher than required by the use case were reconsidered until all data source selections fulfilled the information frequency requirements of the individual use cases.In the data collection/integration section, the average detectability score of each use case's data source selection was calculated.Furthermore, the average scalability score of each data source selection was determined, and the values were normalized across all use cases.In the section on setup considerations, questions were answered regarding data source location, safety, data security and privacy concerns, model type, analysis frequency, and computing location.These questions helped define each use case better and served as a basis for the following effort estimation.The effort estimation was conducted in three steps along the three elements mentioned above, with an effort and scaling potential estimation and an adjusted effort calculation for each element.After accumulating all elements' effort into the total effort, each use case's applicability score was determined.In our example, the custom operator training is most impactful, with good detectability ratings, great scalability, and above-average effort.Despite the higher effort, this use case has the highest Use Case Applicability Score among the exemplary use cases.It can therefore be recommended for starting the Digital Twin application implementation.
In this section, we showcased the validity of our methodology by applying it to a case of Digital Twin use case development of a medical mechatronic device.Exemplary use cases were derived and rated in the UCMEA, and selected Digital Twin use cases were further evaluated in interplay with anonymized data sources in the House-of-DT.As an outcome, selected data sources and Digital Twin use cases were recommended for prioritized development and implementation.

V. DISCUSSION
Our research found a need for a methodology that defines Digital Twin use cases and evaluates their efforts and benefits for prioritized implementation [2], [3], [22], [23].So far, no methodology has been developed to address this need for the cross-industry concept of a Digital Twin.This work proposed a methodology that helps the practitioner systematically define Digital Twin use cases and find the ones with high value for stakeholders, low effort for implementation and maintenance, and high scalability potential for future use cases.
Our methodology fits well into existing, more generic Digital Twin development and innovation methodologies.While some processes for Digital Twin deployment exist [19], [24]- [26], they do not consider the challenge of which use cases to start with, independent of the application.Parrott and Warshaw's [2] Digital Twin development cycle mentions the steps ''imagine'' and ''identify'' but does not provide specific methods of how to accomplish these steps.We propose the UCMEA to ''imagine'' use cases and both the UCMEA and House-of-DT to ''identify'' the most promising Digital Twin use cases to start implementation with.The outcomes of our methodology can be reused and updated in the following iterative cycles of Parrot and Warshaw's Digital Twin development cycle.Similarly, the ITT methodology does not provide specific methods for accomplishing its steps.Our methodology provides specific tools for the ''Acquire mandate and plan'' and the ''Big picture analysis'' steps.The UCMEA considers stakeholders' needs and opportunities, identifies the most pressing and promising ones, and acquires the mandate for profitable use cases.For example, the big picture is considered by looking at processes and stakeholders from different stages along the product life cycle.
In the following paragraphs, we compare the important aspects of our methodology with methods from other fields, highlighting the advantages and limitations.Within our two-step methodology, the UCMEA provides a structured approach for defining use cases and determining their value for stakeholders.The House-of-DT estimates the scaling potential and efforts to implement and maintain Digital Twin use cases.This two-step approach is also taken in Moisiadis' [8] use case prioritization methodology in software development.He proposes first filtering use cases based on stakeholder goals to control the granularity of the use case elicitation in the second step of the methodology.This challenge has also been mentioned in the field of Digital Twin [23], and we use Moisiadis' two-step approach in our methodology, applicable to all kinds of stakeholder-driven use cases.With this two-step approach, the UCMEA filters for the most value-bringing use cases for the stakeholders so that the House-of-DT only needs to further elicit a smaller number of Digital Twin use cases.Furthermore, the UCMEA also identifies use cases that can be addressed better by other technologies or concepts.It, therefore, only passes on the Digital Twin use cases to the House-of-DT, where a Digital Twin application is one of the most promising solutions to the need or opportunity.
In our methodology, we guide the practitioner through steps to break down the process into easier to assess portions of the entire process.As a result, experts can more accurately estimate those steps, leading to a better overall process estimation.That means experts' judgment strongly influences our methodology.Kundu and Samanta [9] deprecate the influence of analysts' judgment in Moisiadis [8] methodology and propose a purely analytical software use case prioritization methodology.The field of Digital Twin is a cross-industry and ubiquitous concept that requires multidisciplinary teams and input.The field is still in its early phase, where numerous development approaches and architectures are discussed, and common ground has yet to be found.Such a complex system that is subject to constant change is difficult to assess analytically.We suggest developing a more analytical approach to Digital Twin use case prioritization once the field has settled.
Within the UCMEA, we look for stakeholder needs and opportunities along processes of interest to not miss important use cases and then detect potential synergies later in the methodology.The challenge of not missing important use cases has also been mentioned by Moisiadis [8] and Kundu and Samanta [9] in the field of software development.Nevertheless, they do not use a guiding structure to achieve this goal.In manufacturing, the PFMEA takes manufacturing processes as a guiding structure for the experts to identify potential failure modes along these processes.We apply the same principle to all kinds of processes of interest to identify stakeholder needs and opportunities, failure modes included.This approach enables broad Digital Twin use cases more than deep ones and helps focus on areas with potential to scale, which Parrott and Warshaw [2] advocate.
Part of product management is defining the product vision down to determining product features.A cornerstone of a product strategy is setting the main audience for the product and understanding their needs and wishes to address them with the product [27].With Digital Twin applications being a product, we see the value of the use cases being defined by the stakeholders' goals.Ulwick [10], Moisiadis [8], and the PFMEA take a similar approach in the fields of innovation, software development, and manufacturing, respectively.We use Ulwick's ''Opportunity Scoring'' method by assessing stakeholder needs and opportunities and the satisfaction of the current solution.Moisiadis rates business goals by importance but does not consider the current solution satisfaction.We see the stakeholder satisfaction with the current solution as essential for identifying opportunities.
The PFMEA addresses potential failures but not opportunities for improvement.Every opportunity can be described by underlying pain points and every need by an improvement.The authors intended to address both negatively and positively connotated use case potentials and define one methodology to handle them.Nevertheless, occurrence, severity, and detection as rating characteristics of the PFMEA can all be used to define the importance rating of the UCMEA.This means that use cases commonly handled by a PFMEA can also be analyzed with our methodology.
Ulwick's ''Opportunity Scoring'' method stops at determining opportunities for innovation without considering existing solutions to those opportunities.We see the rating of potential solutions as essential for finding the right solution to a need or opportunity.Within our methodology, we rate the value of use case solutions.To achieve this, we ideate use case solutions along the needs and opportunities and estimate the use case solutions' stakeholder satisfaction.This process highlights the most promising use cases and allows identifying important needs and opportunities that can so far not be addressed by the proposed solutions.This approach is inspired by the remedy actions section in the PFMEA but uses Ulwick's stakeholder satisfaction to rate the use case solutions.Parrot and Warshaw (2017) [2] mention valuable processes and unexplained issues as indicators for good Digital Twin use cases.These indicators relate to the importance and satisfaction gap in our methodology.
The UCMEA defines use cases for many needs and opportunities which stakeholders express.Several use cases might be the same but address different needs and opportunities or stakeholders.To better manage the number of use cases, we recommend merging the same use cases that address different stakeholders' needs and opportunities and adding up their impact scores for further evaluation in the House-of-DT.
The House-of-DT uses the QFD method to combine use cases (customer requirements, the ''what'') with data sources (engineering characteristics, the ''how'').Similar to the House of Quality within the QFD, the House-of-DT interdependency analysis identifies the most promising and DT-irrelevant technical features (data sources) and most promising and non-addressable customer requirements (use cases).Unlike the QFD and the work of Stanula et al. [14], our methodology uses the rating of data sources again as input to evaluate use cases.This feedback closes the loop to having data source usability and scalability across use cases affect the prioritization of use cases.While in the QFD, the main output is the selection of technical features to focus on in development, the output of the House-of-DT is prioritized use cases to focus on in development and data sources to start the use case implementation with.
Stanula et al. concept of data source selection for machine learning algorithms (2018) [14] is embedded in our methodology as the option of Digital Twin use cases with databased models.Besides data-based models, our methodology is applicable to all kinds of Digital Twin models requiring physical entity data.Besides manufacturing, our methodology can be applied to Digital Twin development across industries, such as healthcare, construction, logistics, and many more.Furthermore, it considers data sources and further implementation and maintenance efforts for a use case evaluation.
There are several needs and challenges that have been brought up as points for the Digital Twin field.Here we outline how our approach addresses these issues.Redelinghuys et al. [28] mention the challenge of keeping the amount of data to the maximum possible at a low level.We address this challenge by considering data amount and frequency in the decision process of the data source selection of each use case.Additionally, choosing data sources with great scaling potential keeps the amount of data low in the future, as the data can be used for multiple use cases.Wanasinghe et al. [23] point out considerations for Digital Twin implementation setups in terms of cloud or on-premise processors with batch, semi-batch, or real-time analysis.We address this point by including the required and available data amount and frequency and potential safety, security, and privacy concerns with data sources.These preliminary analyses set the ground for better decision-making regarding the processing location and data analysis frequency.Further work can look into deepening these analyses and setup recommendations.
Our methodology contributes to the existing literature by closing the research gap for a methodology assessing and prioritizing Digital Twin use cases.The Digital Twin concept is still rather young, and clear definitions and characteristics have not yet been determined.We identify data as an essential value aspect in Digital Twin use cases.We use aspects from methods from other fields to build a Digital Twin use case definition and prioritization methodology, with data as a central element.
For practitioners, this implies reduced uncertainty and a higher probability of profitable Digital Twin applications.Digital Twin use cases are ideated along entire processes of interest to identify broad Digital Twin use cases, which bring a higher value than deep ones [2].Stakeholder needs and opportunities and their importance and satisfaction values give the practitioner an indication for opportunities for Digital Twin use cases.The use case ideation identifies solutions from all kinds of backgrounds.Their rating presents the practitioner with the Digital Twin use cases that are the preferred solution compared to other solutions.This rating reduces the probability of finding Digital Twin use cases for every need or opportunity, even though other solutions might be better suited for addressing them.By applying the House-of-DT, a practitioner is guided step-by-step through a data source and infrastructure evaluation for effort and scalability estimation.This evaluation helps the user come to a Digital Twin use case and data source prioritization for implementation, even if the Digital Twin concept is still new to the user.For further evaluation and visualization of the outcomes of the Houseof-DT, the most promising use cases can be clustered in a Value versus Complexity diagram.This clustering separates the quick wins from the impactful long-term use cases.
We demonstrated the influence established methods from other fields had on developing our methodology, compared these methods with our approach, and showed how it further adds value to the field of Digital Twin development.We discussed remarks made by other researchers in the field and how we implemented their points into our methodology.Limitations were showcased, and further improvements were recommended.

VI. CONCLUSION
With the Digital Twin concept receiving more and more attention across industries, practitioners are faced with the challenge of identifying the most valuable and least effortful Digital Twin use cases to start implementation with.We proposed the Innovation Think Tank Methodology for VOLUME 10, 2022 Digital Twin Use Case Definition, Prioritization, and Implementation.Our two-step methodology guides the definition and prioritization of Digital Twin use cases to support the implementation of Digital Twin applications.The methodology was validated on a product development example in the field of medical mechatronics at Siemens Healthineers Innovation Think Tank.It was shown that a broad field of use cases could be defined through the application of the UCMEA, and the most promising ones for stakeholders can be determined.An analysis of data source-use case interdependence and effort estimation through the House-of-DT brought out the most promising Digital Twin use cases regarding stakeholder satisfaction, scalability, and effort.
To the authors' knowledge, no research exists so far that aims to define and prioritize Digital Twin use cases.Our proposed methodology is guided and inspired by various existing methods from software development, innovation, process engineering, and product development.It was demonstrated how each step in our methodology took inspiration from methods from other fields.We discussed the advantages and disadvantages of these methods and why we implemented certain aspects at certain points in our methodology.Furthermore, we analyzed existing Digital Twin research and implemented aspects mentioned as needed in the Digital Twin development.
With our methodology, we give practitioners a tool at hand to define and assess Digital Twin use cases in any field of application.Based on stakeholder satisfaction, effort for implementation and maintenance, and use case scalability potential, practitioners can identify promising use cases and determine the ones to start implementation with.This approach reduces uncertainty and results in a higher probability of profitable Digital Twin applications.
As limitations, the methodology's dependency on experts' judgment and the young field of Digital Twin, which further develops and consolidates, were mentioned.We propose our methodology as a first step to structuring the Digital Twin development process but would suggest adapting and updating the methodology to emerging needs.A more analytical approach to Digital Twin use case prioritization can be developed in future work once the field has settled.

FIGURE 1 .
FIGURE 1. Deloitte Digital Twin development cycle, based on Parrott and Warshaw (2017) [2].Our methodology can be applied when starting the Deloitte Digital Twin development cycle, such as designing a new

FIGURE 2 .
FIGURE 2. Schematic of the Innovation Think Tank methodology for Digital Twin use case creation, prioritization, and implementation.

FIGURE 5 .
FIGURE 5. UCMEA validation example of a mechatronic medical device analysis at Siemens Healthineers Innovation Think Tank.

FIGURE 6 .
FIGURE 6. House-of-DT validation example of a mechatronic medical device analysis for Digital Twin use cases at Siemens Healthineers Innovation Think Tank.

TABLE 1 .
Overview of related work.