A Requirements Driven Digital Twin Framework: Specification and Opportunities

Among the tenets of Smart Manufacturing (SM) or Industry 4.0 (I4.0), digital twin (DT), which represents the capabilities of virtual representations of components and systems, has been cited as the biggest technology trend disrupting engineering and design today. DTs have been in use for years in areas such as model-based process control and predictive maintenance, however moving forward a framework is needed that will support the expected pervasiveness of DT technology in the evolution of SM or I4.0. A set of requirements for a DT framework has been derived from analysis of DT definitions, DTs in use today, expected DT applications in the near future, and longer-term DT trends and the DT vision in SM. These requirements include elements of re-usability, interoperability, interchangeability, maintainability, extensibility, and autonomy across the entire DT lifecycle. A baseline framework for DT technology has been developed that addresses many aspects of these requirements and enables the addressing of the requirements more fully through additional specification. The baseline framework includes a definition of a DT and an object-oriented (O-O) architecture for DTs that defines generalization, aggregation and instantiation of DT classes. Case studies using and extending the baseline framework illustrate its advantages in supporting DT solutions and trends in SM.


I. INTRODUCTION
The evolution of manufacturing during the new smart manufacturing (SM) or Industrie 4.0 era is really part of a continuum that has existed for many decades punctuated by greater integration, vertically and horizontally, across the manufacturing ecosystem; big data trends in the ''5 'V' areas of volume, velocity, veracity (data quality), variety (data merging), and value (including better and better use of analytical techniques); more distributed and coordinated intelligence especially using internet technology; and improvements in capabilities and use of virtual representations of components and systems [1]- [5]. The terms ''smart manufacturing'' and ''Industrie (Industry) 4.0'' are often used interchangeably. In this paper we will refer to these concepts collectively The associate editor coordinating the review of this manuscript and approving it for publication was Liang-Bi Chen .
as smart manufacturing. The capabilities provided by SM solutions are commonly organized as tenets of SM, with one of many depictions shown in Figure 1 [6]. Among the tenets, digital twin (DT), which represents the capabilities of virtual representations of components and systems, has been cited as the biggest technology trend disrupting engineering and design in 2020 [7]. DTs are defined in [8] as software representations of components, assets, systems, and processes that are used to understand, predict, and optimize performance in order to achieve improved business outcomes. Considering this DT definition it can be argued that solutions in use today such as model-based process control (MBPC) and predictive maintenance (PdM) use DT technology [9]- [12], with the DT clients or users of the DT capability ranging from low level equipment, components and processes up through high level manufacturing execution systems (MESs) and enterprise resource planning (ERP) systems. VOLUME 8, 2020 This work is licensed under a Creative Commons Attribution 4.0 License. For more information, see https://creativecommons.org/licenses/by/4.0/ FIGURE 1. One depiction of the tenets of smart manufacturing [6].
The state-of-the-art of DTs provides insight into definitions and solutions in the DT space, but also places requirements on a future DT framework that should incorporate these existing solutions. Moving forward, the importance of DT technology will continue to grow, driven by needs such as tighter objectives of throughput, yield and cost reduction, mass personalization in manufacturing, faster and smarter verification and validation of systems, higher levels of reconfigurability, and tighter integration across the entire manufacturing eco-system including the consumer space [13]- [15]. Over the longer-term, aspects of the vision for DT have been defined for specific industries (e.g., microelectronics [1], [16]) and future greenfield manufacturing environments [4], as part of an overall SM vision.
It is clear from an analysis of these trends and vision aspects that DTs will play an increasingly important role in manufacturing with a flexible DT infrastructure being an integral part of all manufacturing systems. Unfortunately, lack of consistent definitions of capability, structure, and form prevents us from being able to easily re-use, scale, extend, verify, validate, integrate, interchange, and maintain DT technology, approaches and solutions. Also, it does not allow us to develop a clear roadmap for achieving a DT vision. A framework for DT creation through operation and maintenance is needed that supports re-usability, extensibility, interoperation and interchangeability today and greater levels of autonomy in the future. This paper proposes a baseline framework for DT technology that leverages the knowledge gained from the development of existing DT solutions and incorporates the requirements placed on DT technology by SM trends and the ultimate DT vision. The framework includes a definition of an object-oriented (O-O) architecture for DTs that incorporates the bottom-up knowledge gained from practical development and implementation of today's DT classes, while addressing requirements such as re-usability, extensibility, interoperability, interchangeability and autonomy incurred by SM trends and the ultimate SM vision. Specifically, following this introduction and a list of acronyms used throughout the paper (Table 1), background information is provided on DT definitions, existing DT capabilities in manufacturing, and DT trends and vision. This is followed by an analysis of the issues preventing the realization of the DT continuum, from today's solutions through the ultimate DT vision. DT framework requirements are then derived, and a baseline DT framework is proposed, consisting of a concise DT definition and an O-O architecture that meets these requirements. A summary analysis of these requirements and framework attributes is then provided, and gaps that remain are identified; building on the baseline specification that fills these gaps would provide a roadmap for realizing a next generation practically usable DT framework. Case studies and framework extension examples are also provided summarizing previous works by the authors and detailing a case study solution for semiconductor manufacturing and a framework extension for maximizing DT benefit. This paper concludes with a summary of the contributions, an overview of the current state of DT technology with respect to the baseline framework, and a discussion of key challenges that must be addressed to realize a practical DT framework that supports current solutions through the ultimate DT vision.
Since then, the ''digital twin'' concept has been defined in many ways in academia and industry. Qamsane, et al. provides a literature search of common DT definitions and associated efforts [19]. These include contributions from NASA and the US Air Force Research Laboratory [20], General Electric (GE) [8], the Industrial Internet Consortium [21], and a number of academic sources [22]- [25].
To date, no consensus has been reached on a DT definition in manufacturing. The DT label is often applied to any capability that replicates some aspect of a system, e.g., simulation of anything in manufacturing. It is the opinion of the authors that most DT definitions either implicitly or explicitly state the following properties of a DT: • It is some level of replica of a real thing. • It exists in the cyber world, i.e., it is a software entity. • It has a purpose of impacting an aspect of the environment in which its real counterpart exists, in a positive way, usually by serving one or more DT clients. This purpose can be broad or very refined and the impact mechanism can vary widely.
• It uses models to achieve its purpose.
• It incorporates some level of subject-matter-expertise (SME, which will also be used to refer to ''subjectmatter-expert'' in this paper) in the solution. This could be as simple as defining the problem, or as complex as being an integral part of the model solution. Some efforts illustrate that the combination of SME and data provides more effective, robust and usable solutions in many manufacturing domains, than purely data-driven solutions [6], [9].
• It uses data to maintain some type of synchronization with its real counterpart. In most definitions, this data is collected in an operation environment.

B. DT USES TODAY AND CURRENT TRENDS
DT technology has been implemented in several ways in industry. Oftentimes the technology is not referred to as ''digital twin'', and, in many cases, it has existed long before the term ''digital twin'' was coined. For example, Model-Based Process Control (MBPC), virtual metrology, virtual sensing, sensor fusion, and model-based PdM are technologies commonly used in manufacturing today that align with most of the DT properties listed above to achieve an objective such as increase availability and efficiency of equipment, extend useful life, and reduce life cycle cost [11], [26]- [30]. DTs are used today in many industrial areas such as product design, production, and health monitoring [31]- [41]. A summary review of many of these efforts is provided in [19]. DT development processes and implementations today are usually not highly coordinated (e.g., as in a group of MBPCs implemented across a set of similar process chambers in semiconductor manufacturing [42], [43]); however, aspects of reusability of DT components are being explored such as model forms and development and implementation procedures. Additionally, examples have begun to appear in the literature exploring the benefits of combining DTs and developing DT frameworks. For instance, Plattform Industrie 4.0 released a specification report about Asset Administration Shells (AAS) [13], [14], which are virtual digital representations of SM components. The report provides the AAS specifications and structure that ensures interoperability and exchange of information about SM components in a meaningful way between partners in the SM value chain. Additionally, some of the works of the authors have been focused on extending the baseline framework developed in this paper to practical implementations; an overview of some of these efforts is provided in Section VI.A.
A common element of most DT solutions today is the use of a wide variety of models and analytics. These are chosen based on the purpose that drives the creation of the DTs, and the availability of both SME and analytical resources and tools. The modeling approaches for DTs in and outside of manufacturing, while wide-ranging, can be thought of as providing intelligence so that each DT can perform its intended function in a satisfactory manner in a specified environment over an acceptable period of time. A review of DT intelligence in solutions as it is available and used today provides many insights. The first is that analytics and SME both provide contributions to the solution, and the complementary use of these is key to the quality and robustness of the DT solution [6]. While the relative contributions of each vary from DT type to type and application to application, both are always required.
The second insight is that a domain of applicability must be defined for a DT to be effective. This is often specified with a set of context such as ''equipment 'X', process 'Y', for product 'Z', under conditions (a 1 -a n )''. This context is usually determined using a combination of SME and analytics information, and the applicability of the solution is limited to the domain indicated by the context definition. This has an impact on both the human and cyber intelligence in that they may be limited or only applicable in that context-defined area. As an example, if the cyber intelligence is artificial intelligence (AI), which we use here to refer in general to virtual systems that perform tasks using some level of analytics such as machine learning (ML), the solution would generally fall into the narrow AI rather than Artificial General Intelligence (AGI) category [44], [45]. In other words, the developed solutions provide directed intelligence of a specific type in a specific context area utilizing specific data and behavior.
A third insight is that effective DT implementation must include a mechanism to maintain a level of intelligence in the solutions so that the desired benefit can continue to be provided. This usually means that a method of DT maintenance must be part of the solution, and this method must support an update of the DT intelligence to understand and adapt to changes in the application environment [46], [47].
In summary we can thus make the following statements on the state-of-the-art and trends for DTs in manufacturing: • Many manufacturing industries are already successfully employing DT components, though these components have not been referred to as DTs until very recently.
• Most of the DTs in use in factory operation are dedicated DTs, each with a specific purpose such as predicting remaining useful life or optimizing product quality. A specific class or type of DT commonly has a specific objective (e.g., process optimization), pre-definition of operation environment (e.g., equipment, process, and other context), and defined methods or guidelines for development and deployment.
• DTs such as general equipment and software simulators are also available, with their purpose less directed (i.e., the capability being improved is not as succinctly specified, is not directly considered in the design of the simulator, or the capability is one of many to which the simulator can be configured to address), and capability boundaries usually not as well-defined [48]. These DTs are generally not used during actual manufacturing (e.g., they might be used for off-line analysis or planning); however, DTs that are more dedicated to a specific purpose, as described above, might be built from specific configurations using the general simulators and then applied during manufacturing.
• The quality, throughput and cost pressures in some industries have led to DT advancements and a requirement that DTs be an integral part of factory solutions in many areas.
• There is often little coordination of DT technology between the DT application areas. As an example, model-based process control (MBPC) and model-based PdM literature bases rarely overlap.
• Manufacturing is beginning to explore and benefit from abstracting and combining DT solutions [49], [50]. A review of the state-of-the-art and trends also points to clear gaps in technology that, if filled, could lead to more effective solutions. One important gap is that most DT approaches today lack mechanisms that convey elements of prediction quality, such as prediction uncertainty and model accuracy, with respect to the application environment. There are exceptions including virtual metrology solutions that use a prediction accuracy metric such as reliance index to optimize MBPC gain or metrology sampling rates, and prediction confidence in maintenance prediction [51], [52], or PdM solutions that incorporate the cost of false and missed positives into the optimization of the prediction threshold at which action is taken [53]; these solutions illustrate the importance of incorporating prediction uncertainty aspects into the application environment. Another important gap is the lack of commonality of structure and behavior among DT types. Providing this commonality would lead to improved opportunities for combining DT capabilities and integrating them into manufacturing systems.
Moving forward we can say that the industry is already successfully deploying DT components, but there is a need to leverage this base of important research and develop-ment through a unified framework that supports DT creation, extension, exchange, reuse, and integration, while allowing for maximizing of DT intelligence.

C. THE DT LIFECYCLE
Regardless of the DT type and implementation area, effective implementation requires good practices for solution design, development, verification, validation, deployment and maintenance. As a consequence, effective DT technologies today either implicitly or explicitly support a DT lifecycle in order to provide a level of guaranteed capability over a time period in a defined environment. A high-level view of a common DT lifecycle is shown in Figure 2 illustrating steps in the lifecycle process and key decision points. Additional description of the steps and transitions in the lifecycle is provided in the Appendix. Practical examples can be found in [6], [11], [19], [21], [30], [54]. The lifecycle can usually be broken down into two main phases: off-line development and on-line deployment and maintenance.
In the off-line development phase, data, analytics and SME are usually brought together to envision, design, develop, and verify and validate (V&V) DT solutions prior to deploying on-line. The off-line data (often called ''data at rest'') is usually historical data, which is used along with SME and analytics to understand the application environment (e.g., data quality, ability to merge data, and level of supervision or the degree to which ''output'' data is available to relate to input data of the data set), determine the feasibility of building a DT that can provide benefit (noting that it can be determined at this phase that building a usable DT is not feasible, e.g., due to poor data quality), develop candidate solutions, and quantitatively V&V these solutions. Verification is the process of determining whether a design meets a set of requirements, specifications, and regulations, whereas validation is the process of determining whether a design meets the needs of the user [55]. In the context of DT, verification could include verifying base capabilities against standards and specifications, quantifying metrics on domain of applicability, with validation including validating the quality of DT output across this domain, determining the expected benefit such as financial benefit of applying the solution, and determining the robustness of the solution across methods for solution maintenance [6].
In the on-line deployment and maintenance phase, the qualified off-line solution is deployed, used, continuously evaluated, and maintained (the maintenance phase of the DT lifecycle is also referred to as ''service'' in the literature). The deployment includes the integration of the DT capability into the existing system, including DT data, interfaces, services and behavior, so that the DT capability is effectively used by DT clients. Once deployed, the DT uses select run-time data from its operation environment (often called ''data in motion'') to assess the state or condition of aspects of the environment and make recommendations, thereby fulfilling its intended purpose. Continued effective use of the DT requires maintenance of the DT capability. This often  Table 3 for further description of steps and transitions.
includes continuous evaluation of the DT to determine if and when the DT should be updated. The updates could be implemented on-line (e.g., with model tuning) or might require the DT to be taken off-line (e.g., for model rebuilding). DT model maintenance is an often underappreciated and weak area in the DT lifecycle [21], [30], [46], [56], [57].

D. DTS OF THE FUTURE: NEAR-TERM AND LONGER-TERM
The DT roadmap and vision in manufacturing are often chronicled as part of the larger SM or I4.0 vision. One common aspect of the SM vision in which DTs play an important role is the movement from reactive to predictive to prescriptive operations in manufacturing application environments [4], [58], [59]. DTs will contribute to providing the indications, predictions, and prescriptions, respectively, in these environments. Thus, many DTs are expected to evolve from providing reactive type capabilities, such as anomaly detection, to providing more predictive capabilities, such as PdM, and eventually prescriptive contributions, such as recommendations for downtime avoidance. Note that while this general trend will be ongoing in SM, there will always be a need for reactive and predictive DT capabilities. For example, there will always be a need to detect anomalies that cannot be (accurately) predicted or avoided, and there will be a need for reactive systems to reduce false negatives of predictive systems [50].
Longer term, an aspect of the DT vision in manufacturing is that DTs exist for all real items, including physical systems, processes, and parts, as a dynamic representation of those items with real-time synchronization (see [1] for a depiction of this vision with respect to systems and processes). This covers not only the ability of the DT to predict the future state of the item, but also to extend the current representation of that item (e.g., user interface visualization) in such a way that the representation in the past and present can be extended into the future [16].
Utilizing DTs to provide recommendations for existing and newly developed manufacturing systems is an aspect of the vision for DTs. Approaches for designing production lines utilizing DTs for optimizing system performance are proposed in the literature [19], [32], [39], [40], [60], [61]. Similarly, the perspective of simulation for current and future DTs is discussed in [48].
From the DT intelligence perspective, DT technology will continue to leverage advancements in analytics to maximize DT intelligence. This will include improving existing analytics capabilities, but also embracing new capabilities such as what happened with the emergence of deep learning solutions in big data environments over the past decade [62], [63]. Even with these analytics improvements, it is expected that SME will continue to play an important role in DT solutions, with improved methods for AI-SME interaction and integration, and a movement towards a ''no knowledge left behind'' DT vision aspect [1], [6].
In summary, DT roadmaps and vision generally point to an increased proliferation of and reliance on DT technology. The DTs will be more integrated (vertically and horizontally), will eventually need to be dynamically created, configured, and verified and validated, and operate in an integrated environment that extends beyond the ''four-walls'' to the entire ecosystem [1], [4], [5]. The DTs will take advantage of advancements in analytics, data, and understanding to provide higher quality and more expansive capabilities. They will continue to use but will better integrate SME. The DTs and their capabilities in future environments will be much more coordinated with additional benefits arising from the integration of DT information and capabilities vertically and horizontally [40], [49], [50], [58], [59], [64]- [66]. These requirements of support for proliferation, integration, coordination, flexibility and adaptation suggests the need for a DT framework to support typical roll-out software capabilities such as re-use, interoperability and interchangeability, but also more advanced and futuristic software ideas such as automatic DT creation, validation, maintenance and learning [59], [67].

III. DIGITAL TWIN FRAMEWORK REQUIREMENTS
DT framework requirements must be derived from and satisfy the general understanding of the definition of DTs, DTs in use today, near-term trends in DTs, and DTs of the future including the ultimate vision of DT frameworks in SM. The framework requirements from these sources are presented in the remainder of this section and summarized in Table 2. Note that in this section the term ''class'' is used to define a type of DT, with an ''instance'' being a single occurrence of that class. These terms will be more formally defined and used in Section IV.

A. DT FRAMEWORK REQUIREMENTS DERIVED FROM A GENERAL DT DEFINITION
The most basic requirement of a DT that can be derived from its definition in manufacturing is that it must be a digital replica of something, where that something could be a physical asset (e.g., machine, component or production part), process (e.g., a drilling process), or a system (e.g., a production system for a part). It is also clear that the DT must have at least one purpose in the manufacturing system, developed or configured in order to provide information that can be used by one or more DT clients to realize some type of improvement in the system. Further, in serving its purpose it must detect, predict or prescribe something. Another key requirement is that, in order to maintain its ''twin'' status it must be dynamic, responding to changes in its physical counterpart so that it can continue to represent that physical counterpart with some degree of accuracy. This is often stated as a requirement that the DT be synchronized with its physical counterpart, with the level of synchronization (frequency and accuracy) being a function of the purpose of the DT in its environment.

B. DT FRAMEWORK REQUIREMENTS DERIVED FROM DTS IN USE TODAY
As noted in Section II, there are many examples of DTs operating in manufacturing today. These DT capabilities are modular with boundaries or the relationship between the DT and the system with which it interacts clearly defined. The DTs adhere to a DT lifecycle that includes envision, design, develop, V&V, deploy, use, evaluate and maintain steps. The DTs generally use some type of narrow DT intelligence capability, usually determined by context, to provide a specific function when provided with a specific type of information. This process can be purely statistical or data-driven, however the application of the DT usually requires the marrying of analytics with SME [6], [30], [54]. As these solutions must be part of any DT framework, that framework must support the evolution of these capabilities as opposed to providing a revolutionary, disruptive approach to DT organization. Also, while the DT classes in use are quite disparate, one key requirement is that each provides a quantifiable net value-add to some aspect of the manufacturing system. In other words, the benefit of DT correct operation (whether detection, prediction, or prescription) must outweigh the cost of incorrect operation.

C. DT FRAMEWORK REQUIREMENTS DERIVED FROM DT APPLICATIONS IN THE NEAR FUTURE AND CURRENT TRENDS
As noted in Sections I and II, DT proliferation will continue to increase, and the cost of development, validation, integration and maintenance of DTs will rapidly become intractable unless certain requirements are met in a DT framework. DT classes must become increasingly capable and accurate, leveraging big data 'V' improvements (see Section I and [1]) such as improved analytical approaches. Solution spaces will emerge that require the integration of DTs with other instances, with different DT classes, and with non-DT capabilities. Further, as the SM concepts proliferate beyond the ''four-walls'' of the manufacturing facility to the entire ecosystem, DT solutions must follow. These trends of proliferation and integration place requirement attributes on a DT framework that are common to many manufacturing advancements such as field-bus networks and reconfigurable manufacturing systems [68], [69]. Many of these ''ility'' requirement attributes (such as modularity, interoperability, interchangeability, flexibility, scalability, re-usability, and diagnosability) are applied to the DT framework resulting in the following requirements: DT re-usability: DT solutions must become more portable and re-usable so that the ''develop once use many'' approach can be better leveraged. This also results in improved scalability of the DT solution. While the re-usability concept can quickly become quite complex with the degree of re-usability definable, techniques such as non-threaded MBPC and analytical clustering can be leveraged to determine if model development efforts in different context environments can be leveraged [10], [46], [70], [71].
DT interoperability: DT solutions must be able to interoperate with other DT instances, DT classes, and non-DT capabilities such as DT clients. As an example, DT fleet solutions, which leverage interoperability among DT instances, have been proposed for a range of applications including process matching [42], [66], integration across different levels of the manufacturing hierarchy [10], [49], [67], and augmentation of performance monitoring and anomaly detection methods [9], [11], [72].
DT Interchangeability: The proliferation of DTs requires that they be modular so that they can be more easily assessed, updated, or even replaced. This interchangeability can be realized with standardized definitions of DT structure, baseline abilities, quantifiable capabilities metrics, services provided, interfaces, and behavior exhibited [1], [15], [73]. DT V&V capability: As DTs will increasingly be an integral part of the critical manufacturing processes, their capability must be verified and validated prior to accepting them for use in application environments. Today the V&V process is largely ad hoc, and heavily dependent on the type of DT. For example, MBPC and PdM DT instances are often verified and validated individually on historical data sets. In the future, more standardized, reusable and quantifiable V&V processes must be part of the DT technology capability.
DT maintainability: An often-under-estimated requirement of DTs is that they be maintainable over a useful period of time. As an example, robust predictive measurement techniques are usually part of an overall measurement strategy that includes an actual physical measurement capability. VOLUME 8, 2020 The physical measurement is done infrequently with the data used to update or ''tune'' the predictive measurement model in an on-line fashion [26]. If the error between prediction and actual is too large or persistent, maintaining the prediction model in the DT may require off-line rebuilding of that model [46], [74]. Identifying when to maintain a DT is an aspect of diagnosability.
DT capability and accuracy: DTs will have to become increasingly capable and accurate as part of SM evolution. This requires that the DTs be able to best use the evolving analytical capabilities, whether they be improvements in existing techniques due to big data advancements, or emergence of new techniques, such as the appearance of deep learning [9], [62], [63]. Note that this analytics evolution does not imply that the importance of the SME will be lessened, but rather that the analytics-to-SME integration will become more structured and automated [6].
DT extensibility: The SM trend towards integration across the entire ecosystem will require that DTs be extensible across that ecosystem. This means that DT capabilities operating within the ''four-walls'' of the factory today might in the future incorporate data outside the facility. A good example here is the extension of MBPC or yield prediction beyond the four-walls where the control is to field-yield targets rather than just process targets or even factory-wide yield targets [6], [75]. Unfortunately, this extensibility requirement is associated with many challenges, the most significant of which is maintaining data partitioning and IP security throughout the manufacturing ecosystem [76]. Techniques such as block-chain have been proposed to address aspects of this challenge; however, the scope of the issue will require innovative data partitioning, traceability and translation techniques combined with multi-industry cooperation, standardization and best practices [77]- [80]. While the requirement of ecosystem security is included as a DT technology requirement, it is not addressed in detail in this paper.
Sustaining a DT technology community: The increasing and more stringent requirements on DT technology will only be realizable if there is more cooperation between the various DT application areas and the technology community in general. An effective DT framework thus must provide a common taxonomy and other mechanisms that allow the community to collaborate on DT technology, from DT fundamental research through applied research, development, deployment, and maintenance.

D. DT FRAMEWORK REQUIREMENTS DERIVED FROM DT APPLICATION NEEDS OVER THE LONGER TERM
As noted in Section II, while there are several aspects of the DT vision being proposed including DT solutions in futuristic greenfield environments, common themes exist that can be used to distill DT framework requirements [1], [4]. The first is that there will be a virtual counterpart to the entire SM ecosystem, used for detection, prediction, prescription, and analysis of all aspects of operation. The requirements of a DT framework to address this theme include those identified in the previous sub-section, namely re-usability, interoperability, and interchangeability. However, this proliferation theme also places requirements on the automation of the DT creation, validation and integration process. More broadly, the majority of the DT lifecycle process from creation through maintenance (see Figure 2) must become fully automated, with manual DT efforts limited to envisioning, innovation, and responding to unforeseen situations.
Another theme that is postulated is that DTs will trend away from narrow intelligence (e.g., narrow AI) towards general intelligence (e.g., AGI [44], [45]) as the analytics' fields advance. It is the opinion of the authors that this is not a revolution but rather a general evolution towards less narrow intelligence solutions, and the framework must support this evolution.

IV. APPLYING THE REQUIREMENTS TO REALIZE A DIGITAL TWIN FRAMEWORK
In this section the requirements summarized in Table 2 are applied to distill baseline minimum required attributes of a digital twin framework. This baseline DT framework includes a definition of a DT and a method for the generalization and combination of DTs under a class structure using O-O constructs. The baseline framework derivation will be followed with a summary of how these framework constructs address requirements identified in Table 2, and a discussion of remaining gaps that must be addressed to realize a practical framework. We will then provide case studies and extensions in Section VI to illustrate the importance and practical use of these framework constructs.
While this framework does not address all the requirements in Table 2, it provides a baseline framework that can be extended in a manner suitable for individual application environments so that all requirements can be achieved through additional specification. For example, Qamsane, et al. provides a methodology for realizing a practical framework from this baseline framework [67]. Additional a recently proposed framework that leverages the DT concept to ensure interoperability and exchange of information about SM components is the Asset Administration Shell (AAS) [13]. In this framework each AAS is structured to enable communication with other AASs and to allow for generalization and aggregation of AASs. While the AAS framework meets some of the requirements put forth in Table 2, there are still extensions to AAS components that must be developed to realize all the requirements proposed herein. A good approach to realizing a practical DT framework then would be to use the baseline framework presented in this section and extend that framework to address practical issues of the specific application environment.

A. DIGITAL TWIN DEFINITION PROPOSAL
We define a DT as a purpose-driven dynamic digital replica of a physical asset, process, system, or product. A DT is driven by a need for improvement of the manufacturing environment (e.g., reduce unscheduled downtime, generate a production plan, improve quality, etc.). A DT is a digital replica of an aspect of a manufacturing system; it is usually not a complete replica of an entire system or component. It provides a capability in terms of detection, prediction and/or prescription so that it can deliver on its intended purpose and provide a value-add capability to a DT information client in the SM ecosystem. It is limited in scope, applicability and capability to its intended purpose and defined application environment. This application environment is usually defined by context. An example might be MBPC where the purpose is to improve process quality, and the application environment is the production operation associated with a particular part at a specific process. The DT provides its capability by combining a modeling resource with a computational engine, as shown in Figure 3. The modeling resource is used to emulate some aspect or aspects of the physical ''twin''. The modeling resource can consist of one or more models. As noted above, these models generally use analytics technology to define behavior within a particular environment defined by context. The model type can range from completely physical through phenomenological to purely statistical (data-driven) with an important goal of DT modeling and intelligence gathering approach being that it supports the incorporation of data and SME in solutions to strive for a ''no knowledge left behind'' solution [6].
The DT computational engine is used to support the model in terms of accuracy and alignment with its real counterpart, and provide the required output (i.e., deliver on the DT purpose) to the DT client. The alignment requires that the computational engine addresses the management of updating the model with new data from the physical system, and maintaining the model so that it continues to provide information of necessary quality to support the DT delivering on its intended purpose. The synchronization level (e.g., rate and quality) of the DT with its physical counterpart is a function of the DT's intended purpose and the application environment. This is referred to as ''time critical'' in this paper to indicate that the timing is a function of the application environment. ''Realtime'' is not used here as the term is vague and may be misleading. Synchronization requirement examples include ''every X <timeperiod>'', and ''within <timeperiod-1> following the occurrence of an event 'a' and <timeperiod-2> thereafter until the occurrence of event 'b'''.
The computational engine provides the necessary computational resources so that the DT can deliver on its intended DT capability (as shown in Figure 3). These resources include coordinating the use of one or more models and ensuring that the models have the necessary data and context to maintain synchronization with the physical counterpart, as described above. The DT capability is delivered by the DT producing the following information in a manner suitable for the DT client: • One or more metrics that quantify the DT output as it relates to the DT purpose in the application environment for the DT client. The metrics could vary greatly and could include a binary indication of an event (e.g., fault), a continuous parameter related to prediction of a future event (e.g., RUL), a recommendation for reconfiguration (e.g, a new product route), or a prescription for future avoidance of an event (e.g., a change in machine operational parameter ranges). The metric is usually related to some aspect of the desired performance such as a keyperformance-indicator (KPI).
• One or more metrics that quantify the quality or believability of the DT output (detection, prediction or prescription) as it relates to the intended purpose for the DT client. The DT utilizes data to estimate or predict some aspects of its real counterpart. The quality of the output metrics might relate to the quality of the detection, prediction, or prescription of an event (e.g., probability that the event has/will/can be prevented from occurred/occur/from occurring), and the quality of the prediction horizon (e.g., a confidence interval on the predicted occurrence of a future event and the profile of the indicator leading up to that predicted event). Other quality-of-output metrics might relate aspects of ''how'', ''where'', ''when'', ''why'' or ''to what extent'' associated with the output. Some aspects of the quality of the DT output can be expressed with a receiver-operating-characteristic (ROC) curve, which is created by plotting the true positive (detection/prediction/prescription) rate against the false positive/alarm rate [84]. Model quality can be ascertained in-part from the shape of the ROC including the area under the curve, while confidence intervals can also be displayed on the plot.
The DT is required to deliver a net value add in its application environment (see Table 2, requirement 1h). This means that the DT output and output quality information must be utilized effectively to determine the net value add of the implementation of the capability.

B. BASELINE DIGITAL TWIN OBJECT-ORIENTED FRAMEWORK
Many of the DT framework requirements summarized in Table 2, such as re-usability, extensibility, interoperability and interchangeability, are common to manufacturing disciplines (e.g., reconfigurable manufacturing systems [69]) and other areas ranging from software to network control systems (e.g., [68]), equipment representations and even social sciences. Researchers in these areas generally turn to some form of ''object-oriented (O-O) technology'' as an aid to define structure, behavior, and relationships between types of ''things''. Booch et al., [85], is often cited as the essential reference for O-O technology though there is a large volume of literature covering definitions, taxonomy, languages (such as Unified Modeling Language-UML), etc. of O-O [86], [87]. While there is some variability in O-O technology and concepts, we will follow a common approach specified in [86]. In the remainder of this sub-section, we will provide an overview of important constructs that we will use in this taxonomy, apply the DT requirements to realize a baseline O-O framework, and provide a brief example to illustrate how the constructs work together.

1) INTRODUCTION: O-O CONSTRUCTS AND TERMINOLOGY
The following is a summary of the main O-O concepts that will be used in this section to present the DT O-O framework. Please refer to [85], [87] for a comprehensive treatment of these concepts.
• Object: A concept, abstraction or thing with crisp boundaries and meaning for the problem at hand.
• Class: A description of a set of objects that share the same attributes, operations, relationships, and semantics.
• Instance: A concrete manifestation of an abstraction; an entity to which a set of operations can be applied and that has a state that stores the effects of the operations.
• Inheritance: The mechanism by which more-specific elements incorporate the structure and behavior of more-general elements.
• Generalization hierarchy (IS-A): A specialization/ generalization relationship in which objects of the specialized element (the child) are substitutable for objects of the generalized element (the parent).

• Aggregation hierarchy (HAS-A):
A ''has-a'' relationship, meaning that an object of the whole has objects of the part. Aggregation is used to model a ''whole/part'' relationship, in which one class represents a larger thing (the ''whole''), which consists of smaller things (the ''parts'').

2) INTRODUCTION: TOWARDS A BASELINE DT O-O FRAMEWORK
As noted earlier, an ultimate DT O-O framework will incorporate information requirements from many sources including practical applications, industry-specific needs, and standards [1], [14], [67], [88], [89]. In this paper only a baseline of minimum framework specifications is presented, to address the requirements summarized in Table 2. Complete and more practically deployable frameworks would be based on this proposed baseline specification and provide a more restrictive set of specifications in order to better address aspects of the DT requirements.

3) DT OBJECT CLASS
A DT class is a type of DT that delivers a specific capability for the DT client. The scope of this capability is defined by the DT output purpose metric, thus all DTs belonging to the same class must share at least one common output metric. An example is RUL. DTs belonging to the same class might utilize different numbers and types of modeling approaches and might report additional output purpose metrics. DTs belonging to the same class might utilize and report different quality-of-output metrics. DTs belonging to the same class must have the same general defined scope of applicability. This scope might be very broad as in ''all rotating equipment'' or might be very focused as in ''pumps of brand 'X', model 'Y', operating in an environment with parameter ranges 'Z'''. The scope might be defined qualitatively or quantitatively. The scope is usually defined and refined using contextual information about the equipment, components, process, people, environment, etc. Some refinement might occur at the instance level. For example, the scope of the class might be all pumps of brand 'X', model 'Y', but the instance might further refine the application environment to process 'A'.
DTs belonging to the same class must have common defined behavior. This behavior should include a method (e.g., defined service) for reporting the output metric(s), quality-of-output metric(s), and any other behavior required for the DT to deliver on its intended purpose. This behavior also includes specifications and any restrictions on ability to instantiate off of the class, which will be discussed later in this section. DTs belonging to a class might have additional specifications on behavior, but these specifications cannot conflict with the common defined behavior. An example of this type of additional specification is a Harel hierarchical state-chart that defines common behavior in superstates with additional behavior defined in substates [90]. Common DT class behavior is highly dependent on the purpose that the DT has and the capability it is expected to deliver, as described in the DT definition.
Note that the naming of a class should provide some indication of purpose and scope of applicability. An example might be ''RUL for rotating equipment''. There are no requirements provided here for class naming as existing implementations, trends, expertise, analytics, etc. will likely lead to colloquial naming of many application classes such as ''PdM'' or ''MBPC''.

4) GENERALIZATION HIERARCHY AND INHERITANCE
A DT hierarchy defines how the DT structure, the services it provides, and the behavior it exhibits, can be re-used, combined, shared, or otherwise aggregated or inherited between DT classes or instances. As noted above, generalization allows for the extrapolation of capabilities usually from general to specific.
In a DT hierarchy, sub-classes of a DT class must provide the DT output metric or metrics defined as required in the super-class. Sub-classes of a DT class must also comply with the common behavior in the super-class. The scope of applicability of a sub-class must fall within the scope of the superclass, but it does not have to be the same as the superclass. In fact, in many application environments the main purpose of sub-classing will be to refine or constrict the application environment, e.g., from ''all rotating equipment'' to ''rotating pumps''.
Note that in many implementations sub-classing can be used to further define output and quality-of-output metrics or further define behavior. However, this is not a requirement of sub-classing.

5) AGGREGATION HIERARCHY
Aggregation is a specification that allows for the combination of DT object instances. The combination is associated with some physical relationship between the application environments of the individual instances and is often associated with some aspect of common purpose among the DT object instances. A practical example of aggregation is the combination of DTs that have the same specific purpose and output metric (e.g., RUL), where the DTs relate to the individual components in a larger system (e.g., to express the RUL of that system). The relationship between the components might be more tenuous as in ''a count of all DT event indications on the plant floor''. Regardless of the relationship between DT components in an aggregation, a requirement of any DT aggregation is that membership in the aggregation must be specified in terms of purpose and scope. Examples include ''must belong to a PdM class providing a RUL output metric for one or more components or sub-systems of 'X''', or ''must be a DT instance that delivers a capability for factory 'Y'''.
In some aggregations, the existence of the component DTs is dependent on the existence of the parent aggregate, or the existence of the parent aggregate requires the existence of some or all of the child components. A requirement of the aggregation is the need for existence of the parent and child DTs in the aggregation be specified. This requirement could be different for different components in the aggregate, e.g., ''RUL DT for the fan must exist while RUL DTs for the heating elements are optional''.
As the aggregate itself is a DT, it must comply with the DT and DT class definition. Thus, a DT aggregate must have a defined common output metric, scope of applicability, and common behavior. Note that these specifications might or might not be the same as one or all of the DTs in the aggregate. As an example, the aggregate DT might report RUL of a machine by using its computational engine to analyze the component RUL information reported by the DTs in the aggregate and determine the RUL of the machine. A scheduling DT might use an aggregate of these same PdM-RUL DTs and provide an output metric of optimized schedule by incorporating downtime horizons in an optimization algorithm. Supporting an aggregation of DTs requires that they communicate in some way to exchange information ranging from internal parameters (e.g., modeling outputs) to performance and quality outputs. This is often accomplished in a formalized way using associations between DTs as objects or between objects within a DT [86].

6) INSTANTIATION AND IMPLEMENTATION
Using the DT definition and requirements specified above, a wide variety of DT object hierarchies can be realized incorporating both generalization and aggregation. Depending on how these hierarchies are realized, instantiation of actual DT implementations could be specified as being allowed to occur at any place in the hierarchy or restricted to be below a certain level in the generalization portion of the hierarchy such as ''only in the leaves of the generalization hierarchy''. For example an approach to generalization for additive manufacturing (AM), i.e., 3-D printing, which includes fused deposition modeling (FDM) and selective laser sintering (SLS) approaches, is shown in Figure 4. This example illustrates that a common approach to DT instantiation in a generalization hierarchy might be instantiation off the sub-class if it is specified, with instantiation off the super-class if the sub-class is not specified. A good example of this approach being used in industry today is the Common and Specific Device Models (CDM and SDMs respectively) specified in the semiconductor standard for network devices [68]. The requirements and restrictions for instantiations within a defined DT hierarchy must be specified. If instantiation of a superclass is allowed, then instantiation of all subclasses of that superclass must also be allowed as this is an aspect of class behavior.

C. EXAMPLES
With the baseline of minimum attributes of a DT framework defined, many examples can be realized that illustrate the opportunities for re-use, integration and interoperability and interchangeability. An example that might be representative of a DT solution for an assembly operation, combining both generalization and aggregation, is provided in Figure 5. The aggregation and generalization subclassing paths (e.g., from machine general type (Robot), to specific type (6 degree VOLUME 8, 2020 A more detailed treatise of an extended DT O-O framework implementation that uses this baseline is provided in [67]. In this implementation, additional DT hierarchy specifications are provided that support a specific implementation; these illustrate how the basic specifications presented herein can be used as a template to realize practical DT implementations that better meet the requirements summarized in Table 2.

V. MAPPING OF REQUIREMENTS TO BASELINE DT FRAMEWORK CAPABILITIES: GAPS AND OPPORTUNITIES
The DT baseline framework specification presented in Section IV addresses important aspects of most of the requirements presented in Table 2. Importantly, the framework does not invalidate or prevent the attainment of any of the requirements.
An analysis of the framework specification also reveals gaps in meeting some of the requirements; these gaps might be met with additional specifications, standards, implementation best practices, etc., to realize practical solutions, but are associated with specification choices that might not be unique to realizing an effective solution [1], [13], [15], [67].
The gaps that could be filled with additional specifications or research and development include: • Improving integrability, interoperability and interchangeability of objects within the DT through definition of the interaction between models and with the computational engine in the DT object. This could include a framework for DT models [91], 92]. The specification would likely have to support a variety of different modeling and computation approaches, but could probably be much more refined for specific DT classes and application environments.
• Improving interoperability, interchangeability, reusability, etc. of DTs throughout the entire DT lifecycle with detailed specifications for support of the DT at each stage of the lifecycle and its transition between these stages. The specifications should be divided into off-line or ''data at rest'' components to support model development, V&V, and on-line or ''data in motion'' components to support model deployment, use and maintenance [6]. The framework presented herein is focused on the DT operation and maintenance during the on-line portion of the lifecycle. Structured methods for off-line DT development and V&V have been proposed, which could be added to the framework [9], [11], [30].
• Improving interoperability between DT and non-DT components with specifications that define the interaction between the DT service and clients to deliver the DT capability in an increasingly flexible environment. These could be defined in terms of the DT data structures, interfaces, services and behavior that are exposed to DT clients [1], [73]. The support for interaction could include definition of a language, data structures, interfaces, services and behavior of both DT and non-DT components. These specifications could be added at any part of the DT hierarchy.
• Facilitating and improving DT V&V lifecycle component capabilities with specifications that govern V&V approaches and quantify V&V results. V&V are critical steps in the DT lifecycle and will become more important and require automation as DTs proliferate (see below).
• Improving the maintainability component of the DT lifecycle with methods and specifications for DT maintenance as part of lifecycle on-line (e.g., model tuning), as well as off-line (e.g., model rebuilding) activities [30], [46]. Generally speaking, automation of the on-line maintenance capability should be supported today, while automation of the off-line capability is a longer-term objective (see below).
• Improving consistency, understanding and assessment of DT benefit through agreed upon metrics for communicating the DT capabilities as well as the aspects of the accuracy of the DT [51]. This might be achieved via a standardization process.
• Improving the DT quantified benefit and the understanding of that benefit with extensions to the methods for calculation and optimization of financial net valueadd, to address items such as sensitivity analysis and opportunity cost. An example of how this can be done is provided in the next section.
• Facilitating more structured, automated and optimized methods for integration of analytics and SME throughout the DT lifecycle process (Figure 2) [4], [6], [9]. This improvement will leverage advancements in analytics that allow them to proactively ask for and use SME information, optimally balance analytics and SME information, and be able to assimilate SME information when provided asynchronously. Also, best practices for DT-to-analytics integration at various stages in the DT lifecycle could be specified at different points in the DT generalization hierarchy.
• Addressing security of DT data and intellectual property with standards as well as technology advancements. As DTs will often be employed in a very heterogeneous environment in terms of applications and users throughout the manufacturing ecosystem, security of DT data, models, computational approaches and output will all have an inherent element of propriety that will have to be managed. As noted earlier, this topic is outside the scope of this paper, however efforts are underway to address issues of this type [1], [76], [82], [93].
• Providing a platform for research and technology advancement by extending the baseline specification to agree on standard DT terminology, classes, areas, etc., that would support collaboration. Standards and other specifications derived from a combination of technology assessment, deployment information and consensus building could provide a framework for better coordination and proliferation of technology advancement.
• Extending the DT O-O specification to the entire SM ecosystem. The boundaries of manufacturing will become increasingly blurred with new manufacturing paradigms incorporating optimization throughout the SM ecosystem from raw material production all the way through the end customer experience [4], [5]. DT technology will provide benefits throughout this ecosystem, with many of these arising from the coordination of DT instances (see Section VI for examples). While the framework presented herein facilitates this extension and coordination, much more specification will be required to realize a practical framework across the entire ecosystem.
• Automating all aspects of the DT lifecycle. The proliferation of and increased reliance on DTs across the entire manufacturing ecosystem eventually will require automation across most stages of the DT lifecycle, from design through maintenance. Many of the lifecycle steps such as evaluation and on-line maintenance are already automated in some applications, however automation of other stages, such as design, development, V&V and off-line rebuilding represent ongoing technical challenges. Additionally, automation of SME-to-analytics interaction in the various stages of the DT lifecycle will be required [4], [6].
• Accommodating analytical trends in DT technology. The analytics frontier is dynamic and unpredictable. Evolutionary and revolutionary (disruptive) technologies must be accommodated, or, at minimum, any DT framework should not prevent the use of these technologies. Expected directions in this space include the move towards less narrow context-restricted solutions (e.g., AGI), and more automation of the role of analytics throughout the DT lifecycle.

VI. CASE STUDIES AND EXTENSIONS
Using the baseline DT framework to address practical manufacturing problems is explored in this section. A literature review of previous works of the authors that provide DT application case studies and framework extensions related to the baseline framework developed in this paper is presented in Section VI.A, with references to more in-depth descriptions. A case study of process-capability aware scheduling and dispatch is then presented illustrating the combination of DTs at different levels in the manufacturing hierarchy. This section concludes with a description of a framework extension that supports optimization of DT benefits (e.g., financial) in a defined application environment.

A. DT FRAMEWORK CASE STUDIES AND EXTENSIONS
There have been several other previous works of the authors that illustrate the utility of a DT baseline framework by providing extensions and case studies of use. A reconfiguring scenario utilizing multiple DTs of a manufacturing cell to optimize cell throughput is presented in [94]. A system-level reconfiguration scenario utilizing a DT framework within a VOLUME 8, 2020 software-defined control (SDC) architecture [81] to understand the current system state and optimize system metrics between throughput and quality is presented in [95]. An aggregation and generalization scheme for a system-level DT in a DT framework is presented in [65]. An SDC architecture utilizing a DT framework for fleets of additive manufacturing machines (AM fleet) to perform anomaly detection and reconfiguration is presented in [66], [96], and to perform fleet-process matching using MBPC is presented in [42], [43]. Following this line of work, a reference architecture for the implementation of DTs for AM with implementations on off-the-shelf systems is presented in [97]. Additionally, DT-based run-to-run controllers with a case study on system-level chamber matching utilizing a DT framework for semiconductor manufacturing is illustrated in [66]. In [4] the long-term vision on the role of DTs in a greenfield manufacturing environment of the future is presented. This includes a discussion of the use of agent-based decentralized approaches [83], [98] in conjunction with existing and new centralized approaches for a futuristic DT framework that would continuously extend and improve itself to address the manufacturing needs of the factory of the future.

B. CASE STUDY: PROCESS-CAPABILITY AWARE REAL-TIME SCHEDULING AND DISPATCH
This case study in the manufacturing domain of semiconductor wafer fabrication highlights the need to incorporate instances of different DT classes to provide benefits above and beyond what is provided by the individual DTs [49]. Each of the DTs in this case study complies with aspects of the DT definition, and their collaboration can be facilitated by the DT O-O framework presented herein. An overview of some of the major tasks in the lifecycle process for the DTs in this case study is provided in the Appendix.
In the semiconductor (also referred to as ''microelectronics'') manufacturing environments, semiconductor ''wafers'' are processed in a fabrication facility or ''fab'' using complex combinations of process steps such as deposition, lithography patterning and etch to create precise repeated patterns called ''die'' on each wafer [99]. These ''front-end'' processes are often required to produce angstrom-level precision pattering with yields > 99% while operating at near 100% capacity. Maintaining these stringent operating conditions requires augmenting precise equipment and process design and configuration with adaptive cyber or software mechanisms to optimize operation. At the lower levels, a communication protocol called SEMI Equipment Communication Standard (SECS) is used to provide standardized data collection and actuation across production and metrology equipment in order to understand equipment, process and product context, state and quality [71], [73], [100]. A form of MBPC called ''run-to-run (R2R) control'', which is implemented widely in fabs, uses this communication environment to tune and maximize process capability or ''C pk '' at each process [101]. C pk is a common metric used in manufacturing to convey process capability. It is a quantitative indication of the closeness to process target as well as variability of the process output [102]. At higher levels a suite of fully automated systems work together using a combination of SEMI standardized and proprietary protocols to maximize the production capability of the fab. ERP systems coordinate and prioritize production orders, MESs determine production flows, bill-of-materials, etc. to execute orders, while real-time scheduling/dispatching (S/D) systems consolidate data from fab MES and ERP systems to understand production needs (e.g., orders, priorities, deadlines) and capabilities. This understanding is then used to dynamically route groups of wafers called ''lots'' in order to optimize production according to a cost/profit function in the face of ever-changing production capability information such as queue lengths, equipment cycle times, and unexpected downtime.
It has been argued that if more information from the wafer fabs was used in S/D systems, better decisions could be made in determining production schedules [103]- [105]. For instance, the incorporation of process capability in S/D would help align high-value, high-precision products with high-capacity tools to minimize scrap and improve profit.
In this case study, an approach to S/D is deployed that uses information from multiple sources, including process capability estimates from process control DTs, to enable a S/D DT to propose optimal production schedules, updated dynamically in a time-critical fashion, for a lithography bay of twelve processes from which to select (lithography is often a bottleneck process in semiconductor manufacturing [105]). The solution is illustrated in Figure 6. It employs a rule-based S/D DT to make appropriate S/D plans (production schedules) and updates these plans in response to events in the fab. In this case study, a product called RTD R 1 is used to provide this rule-based configurable ''real-time'' S/D decision-making capability for a single process type [104]. A model of the fab layout defines process flow and opportunities for S/D decisions. The S/D DT then evaluates various production capabilities using a weighted normalized cost function to make decisions to determine which equipment instance, among a bank of possibilities, to select for a particular wafer process.
The cost c of equipment j is defined as: where f ij are the factors taken into consideration, gathered from applications at the MES and ERP levels, and w i are their respective weights. The S/D optimization process consists of the following steps which are executed by the S/D system after every service request by wafer lots: 1) Determine set of candidate tools, defined as operational tools that can perform the required task. 2) Remove candidate tools whose queues exceed a user-defined limit (e.g., do not consider tools with more than ten lots in queue). 3) Compute a score for each candidate tool following equation (1). 4) Choose tools with the lowest cost for processing by solving an integer programming problem. As shown in Figure 7, the factor values f ij in (1) can be determined by individual DTs and then aggregated by the S/D DT solution to determine a production schedule that provides an optimal throughput strategy. This figure only shows the aggregation portion of the O-O hierarchy. The O-O structure for these DT classes is based on the baseline framework. Extensions such as specific class definitions and divisions between DT capabilities would depend on how the solutions are realized in the DT lifecycle. For example, the tool process control DT is derived from a baseline process control DT class, and the bay quality DT, which is derived from a baseline quality DT class, incorporates an aggregate of process control DT class outputs. In an alternate extension of the baseline framework, the bay S/D DT class might incorporate these outputs directly, circumventing the need for a baseline quality DT class.
The solution does not usually incorporate process quality in the S/D DT because that information is not readily available at the MES and ERP levels. However at lower levels in the fab, control infrastructure equipment process control DTs use MBPC models and methods and provide two outputs to support the DT purpose: (1) process setting recommendations (called ''recipes'') prior to each wafer production ''run'', and (2) quantitative estimates of process capability reported the C pk metric. Note that DT output quality metrics are not provided in this solution. In this case study, the S/D DT is augmented to incorporate process capability information from the process control DTs by including these process control DTs in the aggregation (see dashed lines in Figure 7) and adding the C pk information to the S/D DT cost function model (1) and Figure 6. The results are shown in Figure 8. In this experiment, the output of the S/D DT is evaluated in a simulated fab operation environment. In this environment it is assumed that there are (1) three products of different production value being produced, (2) factors of cycle time, queuing time and C pk impacting profit from the perspective of S/D, and (3) C pk estimates are accurate. Standard six sigma conversion tables are used to determine wafer die scrap. Scrap for product 2 is shown in the figure due to its high value. Scrap calculations assume 600 die per wafer [49]. The results illustrate the impact of different weights of the C pk factor on the overall profit of the fab. A typical S/D DT implementation that does not incorporate the process control DT information would produce a production schedule recommendation equivalent to a C pk weight of zero. As the C pk factor is increased, the fab profit increases and then decreases illustrating the tradeoff of throughput and quality. From this analysis an S/D DT production schedule output can be calculated that is optimized to the fab profit.   This solution illustrates the benefit of the DT framework from the perspectives of consistent DT definition and structure (e.g., for incorporating information from a bank of similar process control DTs into a single S/D DT), collaboration between DTs, and quantification of DT output. The framework also points to areas for improvement in this case study solution including the need for quantification of the quality of the C pk estimates provided by the process control DTs as well as the decisions made by the S/D DT.

C. EXTENSION: METHOD FOR OPTIMIZING DT BENEFIT IN A DEFINED APPLICATION ENVIRONMENT
A DT is required to deliver a net value add in its application environment, and the benefit must be ascertainable and quantifiable (see Table 2, requirements 1h and 1i). This net value add is often expressed as a financial benefit. A good example is the case study just presented where optimal benefit is expressed as a balance between throughput and yield ( Figure 8). In most DT environments, determining and optimizing this financial benefit also requires understanding the quality of the DT detection, prediction, or prescription output, and the corresponding application environment cost of acting on correct and incorrect detection, prediction or prescription information provided by the DT. A practical DT framework thus might use an extension that provides for optimization of the DT benefit in the application environment. An example of such an extension is shown in Figure 9.
Here the ROC for a DT detection, prediction or prevention capability is used to determine an operating point for acting on the DT output (e.g., determining a parameter value ''limit'' at which to act on the prediction of a failure event). The ratio of the cost of a false positive (alarm) and missed positive in the application environment is also indicated (as a straight line). For example, the cost of a false positive might be the total cost of a scheduled (but unneeded) downtime while the cost of a missed positive might be the cost of an unscheduled downtime minus the cost of a scheduled downtime. The point where the ROC has the same slope as the cost ratio is the ideal operating point for acting on the DT event indication, with difference between cost and benefit at that operating point being the net value add that the DT should be expected to provide in this application environment [9], [53].

VII. SUMMARY
Digital twin technology, which is an integral part of the evolution of smart manufacturing evolution, has actually been in use for decades in manufacturing. Solutions such as MBPC, PdM and virtual sensing/metrology all fit the general DT definition as they utilize virtual representations of some aspect of a system to provide quantifiable benefit. As we move forward in DT technology evolution we must embrace these existing knowledge, technology and solution bases while accommodating near-term DT requirements such as re-usability, interoperability, interchangeability, V&V, maintainability, and extensibility, along with longer-term and visionary requirements such as automatic creation, V&V, integration, and proliferation across the entire ecosystem. Further we must provide an environment for a sustainable DT technology community that supports common definitions, taxonomy and other mechanisms for collaboration.
While there have been many important efforts focused on providing DT definitions and frameworks, this paper uses a requirements-based approach to derive baseline components of a framework upon which practical frameworks and solutions can be built. This baseline framework includes a DT definition and O-O specification that addresses important aspects of requirements of DT solutions in operation today, in the near future, and over the longer-term including the DT vision. Key attributes of this framework include (1) a DT definition as a purpose-driven dynamic digital replica of a physical asset, process, system or product; (2) a DT structure that includes one or more modeling resources coordinated via a computational engine; (3) a DT output that includes metric(s) that quantify the DT output as it relates to the DT purpose, and metric(s) that quantify the quality or believability of the DT output; and (4) a DT O-O structure that supports both generalization and aggregation subclassing structures to facilitate reusability, interoperability, interchangeability, maintainability, and extensibility. Extending this baseline framework to practical solutions requires addressing gaps identified in fully addressing the derived requirements. Key among these include (1) providing specifications for interaction between components within DTs, between DTs, and between DTs and non-DTs, across the entire DT lifecycle; (2) providing better mechanisms for facilitating analytics-to-SME interaction; and (3) providing mechanisms for automation of all aspects of the DT lifecycle including DT creation and V&V. Addressing these gaps will require making (perhaps capability limiting) choices instituted via standards, best practices and other specifications.
Moving forward will require a focus on consolidation of DT research, development and implementation. Bringing these great bodies of DT research and development together will require advancements in technology, but also development of standards and other specifications that will serve to align DT efforts without compromising capability or creativity. Specific deficiencies in DT technology today that will have to be addressed to realize longer-term solutions include providing more robust and automated solutions for DT maintenance, automating DT creation, V&V, and analytics-to-SME incorporation processes, providing solutions for data sharing that preserve content to support DT operation while protecting intellectual property, and realizing DT solutions more collaboratively vertically and horizontally across the entire manufacturing ecosystem.

APPENDIX DT LIFECYCLE STEP AND TRANSITION DESCRIPTION
A high-level view of the DT lifecycle is provided in Figure 2. Additional detail on the lifecycle steps and transitions is provided in Table 3, columns one through three. Note that step descriptions can vary widely depending on the DT purpose and application environment. Column four provides additional detail on the case study of Section VI.B illustrating some of the major tasks that might be executed at each step in the lifecycle.