In this section, we will explore the Digital Twin concept's origins and intent by the original creators as we define the Digital Twin for this book and identify its key characteristics. The initial goal of a Digital Twin is to provide the same or better information than could be obtained by being in physical possession of the physical twin, in contrast to simulation and modeling to predict behavior based on "what-if scenarios."

Origin of the Digital Twin concept

The concept of a Digital Twin was first described by Dr Michael Grieves of the University of Michigan in a presentation to the Society of Manufacturing Engineering in October 2002. Grieves originally named it the Mirrored Spaces Model (MSM), but the name evolved, and he ascribed the term "Digital Twin" to John Vickers of NASA, who worked with Grieves on product life cycle management for complex systems.

Grieves and Vickers observed that technological advances in physical products and assets made systems more complex. New technologies also brought new capabilities, such as communication and computing, that could not be represented in the physical (mechanical and electronic) space. These capabilities increased the complexity of systems and required a mechanism to mitigate system complexity by providing improved information about the physical product or entity:

Figure 1.1 – Physical and virtual products combined to create a Digital Twin

MSM provides some insight into Grieves' approach to having a Digital Twin "mirror" a Physical Twin through the flow of data, from the physical product to the digital instance, and then how this information was exchanged and sent back to the physical one:

"The Digital Twin is the information construct of the Physical Twin. The intent of the Digital Twin is that it can provide the same or better information than could be obtained by being in physical possession of the Physical Twin. The key assumption is that the type, granularity, and amount of information contained in the Digital Twin is driven by use cases."

Grieves, Michael. (2019). Virtually Intelligent Product Systems: Digital and Physical Twins. 10.2514/5.9781624105654.0175.0200.

Three key concepts characterized these early Digital Twins. Digital Twin Prototype (DTP) is the "type" or model representation of the physical twin. It was also described as the "design version with all its variants." The DTP of a centrifugal pump, for example, is a single description and information model for the specific model of a pump. There is only one DTP or model, but multiple pumps may use that same model description. This brings us to the instance of a Digital Twin.

The Digital Twin Instance (DTI) is each instance of every physical entity, based on the DTP. We may have 150 pumps in the centrifugal pump example, and each pump may represent a unique instance, all of which is based on the common DTP for that specific model of the pump. It is possible to have only one instance based on a single model. A building is a typical example of such a configuration. There is only one building (DTI) and only one model of DTP. It is worth noting that any changes to the DTP will require the DTI to be updated to maintain the fidelity of the instance to the prototype.

Physical entities such as buildings and other complex products can often not be described by a single DTI. It is generally more of a collection or composition of different instances to make up the overall building definition. Grieves and Vickers addressed this challenge by introducing aggregation of instances. The following diagram illustrates the progression from a DTP model based on a physical entity, and how this is instantiated as a DTIs for individual physical entities that conform to the same Digital Twin Prototype:

Figure 1.2 – Relationships between Digital Twin concepts

It also shows how multiple DTIs can be combined to create a Digital Twin Aggregate, which we will introduce next.

A Digital Twin Aggregate (DTA) is an aggregate collection of DTIs and other DTAs, and the mechanisms to query them. DTIs can exist independently of other instances, but DTAs cannot. The DPI of a single centrifugal pump can exist in isolation, whereas the aggregate of a grouping of pumps are dependent on a collection of instances. A DTA can provide additional insight into the behavior of the aggregate, which cannot be achieved at the instance level. For example, we could monitor the pressure difference across the slurry pumps for a specific processing area, which will give us a different insight into the overall operation of this part of the mining process plant versus the information that we can gather from the DTI of a single pump.

It is important to note that DTPs and their corresponding DTIs are different from Computer-Aided Drawing (CAD) files. A CAD file can describe the physical dimensions of a component, but it lacks the file structure to capture, store, and maintain the properties of all the components based on the CAD file. DTPs and DTIs are typically based on file structures such as JavaScript Object Notation (JSON) or Extensible Markup Language (XML) to manage the extended metadata of a Digital Twin.

Many descriptions and definitions emerged from vendors, analysts, and research organizations over the years based on this initial work by Grieves and Vickers, but they are outside the scope of this book.

In 2012, NASA described a Digital Twin as a multiphysics, multiscale, probabilistic, ultra-high fidelity simulation that reflects the state of a corresponding twin based on historical data, real-time sensor data, and a physical model.

What is a Digital Twin?

There are numerous vendor and analyst definitions of Digital Twins, each describing features that reflect the capabilities or interests of the authors. The Digital Twin Consortium's definition provides a vendor- and technology-agnostic definition that describes the what, when, why, and how of Digital Twins at a high level:

"A Digital Twin is a virtual representation of real-world entities and processes, synchronized at a specified frequency and fidelity.

Digital Twins can represent the past and present and simulate predicted futures.

Digital Twin Systems transform business by accelerating holistic understanding, optimal decision-making, and effective action.

Digital Twins are motivated by outcomes, tailored to use cases, powered by integration, built on data, and implemented in IT/OT systems."

We propose a more focused definition of a Digital Twin for this book that relates to the process that we will describe to help you build your first Digital Twin. It contains the necessary elements and common understanding for your initial Digital Twin:

"A Digital Twin is a synchronized instance of a digital template or model representing an entity in its life cycle and is sufficient to meet the requirements of a set of use cases."

Our definition addresses the critical elements of a Digital Twin that we will require in the remaining chapters as we demonstrate how to create our first Digital Twin. It highlights the requirement for a prototype or template model of a physical entity. It recognizes that there may be multiple instances that represent multiple assets of the same type. It also highlights the requirement that the Digital Twin should address specific business challenges or use cases and that they could be at any stage of the entity's life cycle.

Important Note

We differentiate between the life cycle of the entity and the life cycle of the Digital Twin. This distinction will be described later in this chapter.

Entities are not limited to physical assets, and we prefer the description of an entity from the ISO organization:

"entity is an item that has recognizably distinct existence, e.g., a person, an organization, a device, a subsystem, or a group of such items."

International Organization for Standardization (ISO) 24760-1:2011

In addition to the conventional physical asset view of a Digital Twin, this description of an entity allows us to include Digital Twins of processes, supply chains, organizations, and governments, among others. It can also be used in extreme examples, such as a hurricane or bushfire, in an emergency response use case. We will cover more examples in the Industry use of Digital Twins section.

A vital element of the Grieves and Vickers approach was that Digital Twins synchronized with a physical entity. This means that a digital model that only provides a simulation with no input from a physical asset does not qualify as a Digital Twin. It can be used to start the process of creating a Digital Twin as it may represent the DTP or DTA, but it requires the instance and the data to be synchronized to qualify as a Digital Twin. Examples of these digital models include 2D and 3D CAD design drawings, Building Information Management (BIM) models, planning simulation models, and AR visualizations based on design parameters.

Entity life cycle and Digital Twin development life cycle

Physical entities, products, and assets have life cycles, from planning and design through manufacturing or construction, operations, maintenance, and, finally, retirement or disposal. The asset life cycle represents the phases of physical twin development and use. The twin's digital version is a software-based digitalization that includes models, data, connectivity, analytics, and actions. The twin's digital version requires a software engineering approach, whereas the physical twin is based on engineering management practices such as product life cycle management (PLM).

It is important to note that we distinguish between the asset life cycle/Physical Twin and the Digital Twin development life cycle, as shown in the following diagram. We will be referring to both life cycles throughout this book, so this differentiation is important to keep in mind:

Figure 1.3 – Digital Twin and product life cycle relationship

Developing Digital Twins requires both traditional engineering as well as software development practices so that they work in harmony. This convergence of Operational Technology (OT) and Information Technology (IT) is a positive development for Digital Twins as it creates a shared understanding of both the physical and the digital requirements.

It is not the aim of this book to provide guidance on PLM for the physical twin. The digital development life cycle will be addressed in the remaining chapters as we build our first DTP. Also, it is not this book's aim to provide guidance on the digital development methodology that an organization should follow.

Our preference is an agile-based approach for our initial minimum viable Digital Twin in this book, but other software engineering approaches, such as the V-Model and Waterfall, can be used if you are more familiar with these methodologies. The V-Model approach is popular for designing and manufacturing complex systems in aviation and the military, but that is beyond the scope of this book.

Types of Digital Twins

The types of Digital Twins that we'll describe here are not a full taxonomy of a Digital Twin or a formal classification system. Still, this will highlight that different use cases have different types of Digital Twins.

Discrete versus composite

The scope and scale of a Digital Twin will vary based on the use case or problem that it is addressing. A key consideration when choosing your first Digital Twin is the level of complexity that your use case will require. More complex Digital Twins are typically composed by assembling different discrete or standalone Digital Twins:

Figure 1.4 – Discrete and composite Digital Twin relationship

The preceding diagram shows the relationship between a discrete Digital Twin and a composite Digital Twin.

A discrete Digital Twin is the lowest level of abstraction that is sufficient to meet the requirements of a specific use case. It is often a single or atomic entity where no value would be added by breaking it down into components or parts, such as the gearbox or motor for a ball mill in mining. It doesn't need to be broken down into its component parts as its status and monitoring processes are reported at this entity level.

A composite Digital Twin is a combination of discrete Digital Twins that represent an entity comprising multiple individual components or parts. A composite Digital Twin can be an Assembly Twin, such as a ball mill in mining, or a System Twin that comprises multiple Assembly Twins, such as processing and refinement plants. A Composite Digital Twin is a system of systems with a more complex life cycle management challenge.

A discrete Digital Twin is typically a standalone component or asset that can function on its own to address a specific use case. An electrically driven centrifugal pump and its electric drive is a typical example of a discrete Digital Twin as monitoring and reporting is done at this level. An example of the discrete pump Digital Twin use case would be to predict pump failures based on a predictive analytics model.

A composite Digital Twin is an assembly of several discrete Digital Twins to create a new functional, composite asset. Combining several discrete pump Digital Twins with discrete autoclave Digital Twins creates a composite Digital Twin of a gold processing plant, which is used for production optimization.

A predictive maintenance use case example for a composite plant Digital Twin is more extensive than the predictive maintenance use case of the discrete pump Digital Twin, even though the pump is used in the plant use case.

The DTP that we will design and develop in this book will follow the Discrete Digital Twin pattern. The difference between the pump and the gold recovery plant leads to the second type of classification we need for Digital Twins.

Product versus facility

Industrial Digital Twins based on physical entities can broadly be applied to two prominent use cases. The first is a Digital Twin representing a manufactured product such as a pump, electric motor, hand drill, X-ray machine, automobile, or any other asset-based entity. The primary objective of the Digital Twin is to monitor the use of this specific entity, which may include indications of failures or sub-optimal operation.

The second type of industrial Digital Twin use case is around manufacturing or production facilities, which generally consist of a composition of individual assets. The Digital Twin is used to provide insight into the operations of the facility. The facility Digital Twin will consist of an assembly of unique product twins.

The discrete product Digital Twin can be used in two different ways in the composite facility Digital Twin; for example, where the product is part of the facility, such as a robotic arm on an assembly line.

The second use case is where the Digital Twin is part of the manufactured product, for example, an electric motor, a jet engine, or wind turbine, in the manufacturing facility.

A smart manufacturing use case, for example, uses a combination of product and facility Digital Twins. The product Digital Twin is used on the manufacturing line to determine the machine setup, tooling, and parts requirements.

Product Digital Twins are currently predominantly used in manufacturing scenarios, and manufacturers have no visibility of the use of the product once it has been shipped. As the adoption of Digital Twins increases, this scenario will likely change.

Product manufacturers are keen to extend access to the Digital Twin of the product beyond the point of the manufacture. Manufacturers provide Digital Twin solutions that allow them to collect operations and usage data that will be used for product improvements and new service-based products.

The Digital Twin can provide insights into how products are used, and this can be fed back into the product's design for improvements. These insights will enable manufacturers to develop and manufacture products that are more fit for purpose and at higher quality levels.

The real opportunity for many manufacturers is to provide not only the product but also the maintenance services around the product. Access to the operating product's Digital Twin will provide the necessary insight to predict when failures are likely to happen, or when the product is due for servicing or replacement. This opens up a new business model for many manufacturers with new revenue streams, which wasn't possible without the Digital Twin technology.

Simulation versus operational

During the early stages of the product or asset life cycle, the Digital Twin use cases focus more on simulation scenarios. In contrast, use cases in the later stages of the product tend to focus more on operational and maintenance challenges.

We can broadly classify Digital Twins into simulation and operations twins. This does not mean to say that simulation cannot be used in operations, but the predominant application is to manage operations. During the design phase, the principal use cases simulate different scenarios to determine the product or facility's ideal design:

Figure 1.5 – Simulation and operational Digital Twin types

Simulations also tend to be more project-based, whereas operational use cases are continuous over the operations and maintenance life cycle of the entity. The infinity loop model best describes this, as shown in the preceding diagram. The plan, design, build, and commissioning phases are typically project-based simulations for Digital Twins with very slow synchronization or twinning rates.

The operate, maintain, and improve phases are continuous and often real-time applications of Digital Twins. Recommendations from the improve phase may require us to make modifications to the product that would lead back into the planning and project-based designing manufacturing cycle. It is important to note that this is not a qualifying criterion for classification but rather a typical pattern when using industrial Digital Twins.

Analytics versus physics-based

The digital models that represent the entity can be based on analytics and physics-based algorithms. These algorithms can use historical and real-time data to enable simulation and predictions of the current and future state or behavior:

• Analytics-based algorithms are statistical or mathematical techniques that are used to predict entity behavior based on historical data. These models are most often based on AI or machine learning techniques. Predicting the remaining useful life of equipment such as a centrifugal pump using a regression model is an example of an analytics-based application.
• Physics-based algorithms are based on the physical laws of using engineering equations of state and material properties to provide insight into the current or predicted state of a product. A Computational Fluid Dynamic (CFD) could use design parameters or real-time data to provide insights into a centrifugal pump's behavior under specific conditions. Finite element analysis is another example of a physics-based algorithm that's used to provide insights into a product's structural integrity under simulated or real-time conditions.

Simulation and operational twins can use both analytics and physics-based models for simulation or operational analysis and predictions.

Characteristics of a Digital Twin

The characteristics described in this book are focused on the key elements that will be required when you develop your first DTP. There may be additional characteristics in other more complex use cases, but these provide a great starting point for Digital Twin evaluation:

Figure 1.6 – Digital Twin characteristics

The preceding diagram provides a visual representation of the characteristics of a Digital Twin that are based on the Digital Twin definition:

Figure 1.7 – Key characteristics

Digital Twin fidelity is not necessarily a characteristic and more of a result of the model's sophistication and twinning rate. We are seeing an increase in Digital Twin fidelity as the computing capabilities in the virtual environment continue to expand exponentially according to Moore's law.

Metrology is also an essential requirement for twinning as it involves accurately measuring the state parameters. It is not a characteristic, but it is essential to ensure accurate representations of the physical state.

As we start building the first DTP in this book, we will continue to refer to these characteristics. It is useful to document the specific aspects of your Digital Twin in this table format when you choose your ideal candidate. It will provide an initial test to help determine if a particular use case or scenario would qualify as a Digital Twin.

Models and data

Virtual twins exist in virtual environments in a digitized format and rely on different data sources and models to turn data into information. There is a wide variety of data sources and models that provide virtual twin data capabilities. For this book, we have simplified them into six main categories:

1. Temporal or Time Series Data: This data provides time-stamped, real-time synchronization of physical state data through sensors, automation, and control and IoT systems. It is stored and accessed from time series databases, historians, and IoT platforms.
2. Master Data: Master data is generally slow-changing contextual data that's stored in systems. It is used to describe assets or entities such as enterprise asset management systems (EAM) and enterprise resource management systems (ERP), as well as in Digital Twin services such as Azure Digital Twins.
3. Transactional Data: Operational, transactional data such as production records, maintenance records, supply chain information, and other business records related to the Digital Twin are generally stored in ERP, Computerized Maintenance Management Systems (CMMS), Manufacturing Execution Systems (MES), Business Process Management (BPM), and production systems.
4. Physics-Based Models: Physics-based and engineering calculations use real-time, transactional, and master data to describe or predict the physical entity's state. Examples include finite element methods (FEM) and computational fluid dynamics (CFD), as well as other laws of nature, such as the laws of thermodynamics.
5. Analytical Models: These are mathematical and statistical models in the virtual environment that use the same data sources described previously to predict the current and future state of the physical twin and its environment. This includes AI and machine learning for predictive maintenance and operations use cases.
6. Visual Models: These are digitalized visualization modeling capabilities such as Computer Aided Design (CAD), Augmented Reality (AR), Virtual Reality (VR), Building Information Modeling (BIM), Geographic Information System (GIS), and geophysics models. These models are often used to reduce system complexity and provide a visual analysis of the different data sources.

The heterogeneous nature of all these different data sources contributes to the fact that integration remains a significant challenge when creating Digital Twins. We will refer to this point when we start building the DTP in the technical chapters of this book. Integration and interoperability can consume a large part of the resources in a Digital Twin project. It is essential to understand the data requirements, as well as what physics and analytical models will be required to address the specific business problem that the Digital Twin set out to solve.

Digital Thread

Digital Thread is a term that gained popularity at the same time as Digital Twins. It is sometimes confused or associated with Digital Twins. The Digital Thread can exist without formal Digital Twins, but Digital Twins are built on Digital Thread information.

The Digital Thread evolved from PLM, which captured the process from design to manufacture for physical products. The Digital Thread creates a traceable, unique birth record with the actual data for each composite entity or product assembly and all its components. It captures all its interactions and transactions throughout its life cycle through to retirement. It extends the life cycle record beyond the PLM's focus into operations, maintenance, and disposal.

The Digital Twin's focus on the life cycle phase is to address specific use cases, whereas the Digital Thread is the data aggregator across all life cycle phases. The Digital Thread provides component traceability regarding its design iterations, manufacturing processes, testing, and quality measures. It often includes environmental metadata such as manufacturer information, storage temperature, and humidity for specific components. The Digital Thread may also include information on the relationship between components, including Bill of Material (BOM) structures and maintenance records.

Some Digital Twins may extend beyond a single phase or blend phases, such as operate and maintain, but it is unlikely to extend across the full life cycle. Digital Twin components such as models, analytics, and real-time sensor data may be reused, but there is generally not a single Digital Twin that spans all of the asset life cycle phases.

Digital Threads integrate data from multiple design, manufacturing, and operational data sources. They may not replicate the information from CAD, MES, EAM, and ERP systems, but they maintain references to the source data for the "birth record to death certificate" for products and components.

The Digital Twin of an aircraft fleet, for example, may be used to prioritize maintenance for individual aircraft, where the Digital Thread for the aircraft will assist in Failure Mode and Effect Analysis (FMEA) and Root Cause Analysis (RCA) in the event of a component failure. It can provide insight into the design, manufacture, and maintenance of the component. A Digital Twin can also assist in identifying aircraft that may have the same faulty component:

Figure 1.8 – Digital Twin versus Digital Thread

The preceding diagram shows the development of the Digital Thread across the overall life cycle of the entity, where the Digital Twin use cases address specific challenges within one or possibly two life cycle phases. How this is used in practice will be explained in the next section.

Throughout this book, you will learn how to create your first industrial Digital Twin. Before we get started, though, it is essential to understand who the key stakeholders are that have an interest in the value of Digital Twins, as well as some of the high-level applications in different industries.

Digital Twin stakeholders

Let's distinguish two different high-level scenarios when using Digital Twins in industrial applications. The first scenario is where the asset that is twinned is a standalone product that's used by an end user. The specific model of an electric vehicle (EV), such as a Tesla Model 3, might be the product, while the consumer is the end user. The vehicle manufacturer will be the Original Equipment Manufacturer (OEM).

The second scenario is a manufacturing asset such as a smart factory, where the EV is produced. The Digital Twin is the factory itself and has different use cases and applications during the smart factory's life cycle phases. This production facility could also be a gold mine, an oil platform, a power distribution micro-grid, or a nuclear power plant.

For this scenario, the stakeholders include the owner/operator that commissions Engineering, Procurement, Construction, and Manufacture (EPCM) contractors to design and build these production facilities. OEMs provide equipment for facilities, and Operations and Maintenance service providers are often used by owners/operators to operate and maintain these facilities on their behalf.

Traditionally, OEMs did not have access to their products and their usage data after they left their factories, but OEMs are increasingly supplying their product Digital Twins with physical assets and, in process, aim to get access to real-time usage data. We are starting to see the reach of OEM Digital Twins extend beyond their own factories' boundaries.

Service providers for Digital Twins aim to extend their capabilities across the full life cycle of the product and facility's Digital Twins. This includes connectivity, compute, storage, integration, modeling, analytics, visualization, and workflows.

The following diagram shows the typical roles of stakeholders during the asset life cycle phases:

Figure 1.9 – Key stakeholders during the life cycle of an entity

All of these stakeholders have had a vested interest in Digital Twins at some stage during the product or facility's life cycle. Information or Digital Twin sharing between stakeholders increases as Digital Twin use cases start to span multiple stakeholders across multiple phases. It significantly increases the Digital Twins' business value, but it also increases complexity and leads to interoperability challenges. Some of these challenges will be addressed later in the book.

Industrial Digital Twin applications

Digital Twins exist across the whole life cycle of assets and products, as we saw earlier in this chapter. Let's look at a few examples of industrial Digital Twin use cases in different industries. This is not an exhaustive list, but it does provide examples that highlight some of the challenges that can be addressed by Digital Twins. This can help you decide on the type of Digital Twin you would like to build as your prototype.

Discrete manufacturing

• Optimize Overall Equipment Effectiveness (OEE) in real time during operations.
• Predictive quality improvement during operations to reduce the scrap rate and rework.
• Enhance product designs with insights from operations and maintenance data.

Process manufacturing

• Manage batch-based processes to "golden batch" in real time to improve product quality and process optimization.
• Predict equipment failure with machine learning models based on real-time operational data and models built on historical failure data.
• Monitor real-time compliance with safety and regulatory requirements for classified equipment during operations.

Energy (power)

• Predict the energy demand per consumer through dynamic machine learning models in an operations-planning Digital Twin.
• Improve grid distribution and management by utilizing simulation models based on real-time data input for Distributed Energy Resources (DERs).
• Improve solar array maintenance by detecting anomalous behavior that indicates dirty panels, for example.
• Predictive maintenance for wind farms to improve the "first-time fix rate" and reduce truck rolls and the spares inventory that's carried by the field service teams.

Oil and gas

• Perform real-time Finite Element Method (FEM) analytics to determine offshore oil platforms' structural integrity based on weather and oceanic data.
• Update subsurface reservoir models with drilling and exploration data to support investment decisions.
• Monitor rotating equipment (such as pumps and compressors) in real time to improve equipment availability and asset performance. This includes condition-based and predictive maintenance.

Mining and metals

• Improved recovery yields on mineral processing plants during operations such as gold recovery or coal washing.
• Monitor mine tailings and other environmental waste in real time and provide recommendations based on expert business rules.
• Provide real-time casting guidance to blast furnace operators based on real-time process parameters and metallurgical (physics) models.

Automotive

• The Digital Twins of vehicles provide feedback to manufacturers with usage data that is incorporated in design improvements.
• Real-time telemetry in the Digital Twin of a car enables manufacturers and their service agents to offer maintenance services based on condition monitoring and predictive analytics.
• The Digital Twins of autonomous vehicles opens up new business models for service providers, such as ride-share operators.

Life sciences and medical

• Reduce the risk of critical stock and logistics challenges with a real-time Digital Twin of the end-to-end supply chain.
• Reduce downtime on expensive High-Performance Liquid Chromatography (HPLC) systems with real-time conditioning monitoring and failure prediction.
• The Digital Twin of a patient providing a holistic view to improve the quality and efficacy of medical treatment (though this is currently challenged by privacy and security concerns).

Infrastructure

• Enable off-site and on-site pre-fabrication by updating the dimensional and structural data in design Digital Twins, through to additive manufacturing during the construction and delivery phases.
• Provide real-time insights and situational awareness during natural disasters and severe weather events.
• Provide real-time insights into foot traffic in retail infrastructures such as malls and shopping centers.

Aerospace

• Track and Trace Digital Twins provide insights into real-time material and supply chain management in aviation manufacturing.
• The predictive Digital Twin of aircraft landing gear extends the life of components and reduces maintenance costs.
• Airport Digital Twins with real-time aircraft movement improve bay utilization and cycle times, thereby increasing revenue.

Defense

• Improved equipment reliability and maintainability of complex military equipment with condition monitoring and predictive maintenance Digital Twins.
• Strategic warfare Digital Twins based on real-time situational data provide planning scenarios to tactical command and leadership.
• A Spatial Digital Twin with a single, dynamic dataset that represents the physical world with sufficient resolution to act as the reference point for all systems requiring mission data.

Other

The Digital Twin concept is increasingly used to model and manage less tangible entities. Some of these include the following:

• Digital Twin of the Earth
• Digital Twin of organizations
• Digital Twin of bushfires

These different examples show a diverse range of Digital Twin applications. There are many more that have not been included in this list. The range of potential applications is only limited by the imagination of those who are actively building these Digital Twins.

A key element of all these examples is that they have clear and measurable value to the stakeholders of the Physical Twin or entity.

Digital Twin systems transform businesses by accelerating holistic understanding, optimal decision-making, and effective action.

Reduce complexity to improve understanding

Grieves and Vickers' initial objective was to manage assets and systems that were becoming increasingly complex with simpler, but representative, virtual instances. Digital Twins that are synchronized with physical entities provide situational awareness and other operational insights tailored to specific problems you are trying to address.

Better insights into real-time and simulated behavior support making better decisions faster. Insights from Digital Twins are often more reliable than traditional approaches of searching for data in multiple enterprise systems. The consolidated data integration approach of a Digital Twin provides more reliable, comprehensive insights that improve the quality of the decisions that are made on that data. The structured information approach of a Digital Twin also lends itself to decision automation rather than just decision support.

Having this improved understanding and better insights provides value in two key operational perspectives. We will look at these in the following subsections.

Improved situational awareness

Businesses are increasingly forced to work in real time or near real time. Every day, companies are exposed to more and more internal and external events that need to be responded to in real time. These events can come from a multitude of sources:

• The actions of people in a business
• The actions of competitors, customers, legislators, or suppliers and supply chains.
• Equipment breakdowns, process failures, and weather events
• Real-time intelligence from business applications, and near real-time data from web services
• More recently, the influx of information from IoT with sensor-based or smart device machine-borne data in IoT platforms

Real-time situational awareness is a concept that came from the US Air Force when training fighter pilots to anticipate the actions of an enemy fighter. It is based on gathering information on the current state and environment of the situation, determining what the information means, and projecting the future state to create a corresponding action. It was described in military terms as the Observe – Orient – Decide – Act (OODA) loop.

Digital Twins might not require the same millisecond response times as a military jet fighter, but the real-time synchronization of a Digital Twin representing a physical asset provides critical situational awareness that drives critical decisions. The supporting information for decisions can be augmented with predictive models, physics, and/or analytics-based data to provide operators with comprehensive decision support. Combining rules with decision information creates an opportunity for Digital Twins to become prescriptive and take autonomous action through decision automation.

Both decision support and decision automation focus on delivering better business outcomes based on the situational awareness that's gained through the Digital Twin.

Improved business outcomes

Digital Twins improve business outcomes in various ways, but we will focus on the impact of an industrial Digital Twin that represents a physical asset or entity such as a motor drive, a production plant, or a factory.

The business impact of Digital Twins can be measured based on four major impact categories, as shown in the following table:

Figure 1.10 – The business impact of Digital Twins

Each category represents a business value driver where a Digital Twin can act as a lever to influence overall business outcomes.

Transformational value

The transformational value of Digital Twins in industrial applications focuses primarily on the impact on digital business transformation, as well as the development of new or improved products based on the transformation of Digital Twins.

Business transformation through digital transformation

A Digital Twin is a change agent for formal digital transformation. A Digital Twin typically represents a specific initiative or use case around a business goal. Due to the digital nature of a Digital Twin, the particular use case or initiative is generally the project that drives specific digital transformation toward the business goal or outcome:

Figure 1.11 – Digital transformation versus digitalization

Digital Twins can affect business transformation by either improving efficiency through digitalization or providing added value by enabling new business models. The four quadrants in the preceding diagram show the impact of different Digital Twin initiatives that improve business process efficiency with digitalization and real-time data. Alternatively, it can monetize and leverage real-time data to change an organization's operating business model. The top right-hand quadrant represents opportunities where businesses can, for example, sell new services based on their equipment, such as support contracts and consumable replenishment, based on the real-time data from their products and customers.

Many organizations start with digitalization projects that improve efficiency. As they gain maturity when using Digital Twins, they move to the top right quadrant and look for ways to monetize these new digital assets.

New or improved products

There are different ways to monetize these new digital assets, including selling operational and maintenance intelligence to operators and users. Equipment manufacturers can also use this information to provide ongoing services based on conditions or predictions gathered from real-time data.

Original Equipment Manufacturers (OEMs) can also use information about the use and performance of their equipment in the field to provide feedback to help improve the design of their products and services. The actual use of assets in an industrial environment provides a wealth of information for Design Digital Twins, which can now use this information for better simulation, specifically in physics-based models.

Value at stake

The World Economic Forum value at stake framework provides an alternative perspective on assessing the impact of digital transformation with technology-based approaches such as Digital Twins.

The "value at stake" framework assesses the value in terms of the economics for the industry or the business and the impact on society. It has a simple representation, especially when communicating value to business executives and other stakeholders, who have a limited interest in the technical aspects of the Digital Twin but need to make the decisions to invest in Digital Twin technology.

The digital value to the industry is based on two elements:

• Value migration, which represents how revenue can shift between stakeholders such as competitors, customers, and other industry players. This aligns with the business model innovation opportunity described earlier in this chapter.
• Value addition, which represents the regular business operational opportunities, such as increased revenue and reduced cost.

The digital value to society focuses on three impact points:

• The traditional economic measures for customers and employees in terms of cost, time saving, and efficiency improvements.
• The societal impact in terms of job creation, new skills development, reduced traffic congestion, and safer working environments.
• The environmental impact can be described by reducing CO2 emissions or improving the management of tailings in mining:

Figure 1.12 – Example of a value at stake analysis for a Digital Twin

Note

The preceding diagram has been adapted from https://reports.weforum.org/digital-transformation/introducing-value-at-stake-a-new-analytical-tool-for-understanding-digitalization/.

The single-page view of the value at stake for a Digital Twin, shown in the preceding diagram, provides a simple yet powerful way to describe a Digital Twin's value proposition.

Now that we can describe the value of a Digital Twin, the next key step is identifying ideal candidates for Digital Twins in your business.

Digital Twins focus on addressing specific business challenges or exploiting new opportunities, as we saw in the value at stake description of Digital Twin applications. These challenges and opportunities provide guidance for identifying opportunities for Digital Twins in industrial applications. This will be covered in more detail in Chapter 4, Getting Started with Our First Digital Twin.

The remainder of this book will focus on selecting and building your first Digital Twin, but let's provide a summary of the high-level guiding principles that can be used to identify a potential pilot from a pool of candidates.

For Digital Twins that focus on improving asset performance, reducing downtime, and increasing production or throughput, the ideal starting point is to identify current "bad actors." This approach is based on using current failure data, production loss information, or failure mode analysis on previous downtime incidents. Applying the 80/20 Pareto principle will help you identify the initial shortlist of entities that cause the bulk of the downtime.

Important Note

The Pareto principle states that for many outcomes, roughly 80% of consequences come from 20% of the causes (the "vital few"). Other names for this principle are the 80/20 rule, the law of the vital few, and the principle of factor sparsity: https://bit.ly/DTPareto8020.

Digital Twins that focus on exploiting new revenue opportunities are generally more strategic and have well-described business cases. The technical feasibility of these opportunities is typically also a factor when designing the new service. Real-time data access, sensor information, and other functions of the Digital Twin are built from the start.

The next step for both scenarios is to rank the business impact against the Digital Twin's technical feasibility. Technical feasibility is generally a factor of infrastructure, connectivity, data access, appetite for change, and organizational maturity.

It is a high-level ranking that can easily be done in Excel, and a template is available at https://bit.ly/DTPriority:

Figure 1.13 – Business impact and technical feasibility assessment

In this example, the following technical assessment criteria are being used:

• OT complexity
• IT complexity
• Analytics
• System complexity
• Project readiness

The technical assessment criteria can be adjusted to fit the business's requirements, but for this example, the criteria are for a typical industrial installation:

Figure 1.14 – Digital Twin prioritization matrix

This order of magnitude is visually represented in a bubble chart, with the business impact and technical readiness scores as the two significant measures. The weighted average values of each of these measures are placed on the graph, which is divided into four quadrants. The value of the economic impact determines the size of the bubble. The four quadrants represent the business readiness for each of the Digital Twin scenarios. The Do Minimum Viable Product (MVP) quadrant represents a high business impact and a high level of technical readiness.

The opportunities on the quadrant's far right-hand side, with the biggest bubble size, often represent Digital Twin projects with the highest likelihood of success for all stakeholders.

This is a very simple approach to ranking possible candidates for your first Digital Twin; the next chapter will provide more guidance on planning your Digital Twin project.

In this chapter, we started by taking a brief look at the history of Digital Twins and the original intent behind the concept. We discussed the difference between discrete and composite Digital Twins, and then we identified the elements required for something to qualify as a Digital Twin. We introduced several typical use cases across the life cycle of a Digital Twin, discussed the difference between a Digital Twin and a Digital Thread, and provided guidance on describing the value proposition of a Digital Twin. Our Digital Twin prioritization matrix provides a framework to perform a high-level assessment of the use cases for your first DTP.

You now have an understanding of what a Digital Twin is, its key characteristics, the value of a Digital Twin, and assessing where a Digital Twin may apply in your business.

The remaining chapters will guide you through building your first Digital Twin, beginning with planning your Digital Twin, identifying the right candidate for your first Digital Twin, and then providing guidance on setting up, building, deploying, and validating the outcomes of your DTP.