Cite as: Grieves, M., Virtually Intelligent Product Systems: Digital and Physical
Twins, in Complex Systems Engineering: Theory and Practice, S. Flumerfelt, et al.,
Editors. 2019, American Institute of Aeronautics and Astronautics. p. 175-200.
Virtually Intelligent Product Systems:
Digital and Physical Twins
Michael W. Grieves,1
1Florida Institute of Technology, Melbourne, FL USA
Abstract. The idea that the information about a physical object can be separated
from the object itself and then mirror or twin that object is a concept referred to
as the Digital Twin. The Digital Twin is receiving a great deal of interest from
manufacturers who make advanced products that have all the characteristics of
complex systems. While the Digital Twin concept is becoming better fleshed out
and understood, there is much more work to be accomplished. Specifically, the
characteristics of the physical product as these become smart, connected product
system (SCPS or Physical Twin) need to be defined and described. The success
of the Digital Twin model will rest on the value it creates for both the manufac-
turers and the users of their products. There will also be new issues, security
among the most important, that need to be surfaced and addressed.
Keywords: Digital Twin, Physical Twin, smart, connected product systems,
SCPS, Internet of Things, IoT
What is referred to commonly as smart, connected products
should be more accurately called Smart, Connected Product Systems
(SCPS). As shown in Figure 1, they are in an intersection of all
products and all systems. But all the items in this intersection are not
smart and connected. While the vast majority of items are smart, i.e.
having computing capability, there are many that are not connected,
i.e., lack communications capability. This is changing rapidly, as more
and more products acquire communication capability. The subset that
are in this region that are smart, connected, product systems are the
focus of this chapter. In this chapter, we will refer to this class of
artifacts as SCPSs.
, the Digital Twin, and system complexity are all
interrelated. SCPS and the Digital Twin are enabled by the advances in
computing and communication technology. While they have advanced
independently, they have a symbiotic relationship.
The advances in both these areas of computing and
communications have greatly improved the functionality and value of
today’s products, as diverse as phones and aircraft. However, these
same advances have led to a major increase in system complexity in
SCPS. The development of the Digital Twin is a response to this and is
intended to mitigate system complexity.
SCPS are enabled by the Internet of Things or IoT, which will
be discussed below. A SCPS, which is enabled by IoT, can also be
thought of as the Physical Twin. This chapter will use SCPS and
Physical Twin interchangeably.
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
The term “product” is a general one and can encompass any offering an organization offers to
its customers. It generally refers to offerings of a tangible nature, with services referring to
intangible offerings. Exceptions do abound, e.g., “financial products”. which are today intan-
gible. Referring to tangible artifacts such as machines, aircraft, automobiles, power generation
equipment etc. is also consistent with the terminology used in Product Lifecycle Management
(PLM). Cyber Physical Systems (CPS) was considered for use in this chapter, but discarded.
It does not provide the clarity and focus of referring to discrete products.
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.
The technological advances of the Physical Twin does result in
increased system complexity. Adding computing and communication
capability adds a vector of system complexity that does not exist in
mechanically or even electronically determined products. The
incorporation of a Digital Twin is intended to mitigate system
complexity by providing more and better information about the
2 Digital Twin
As shown in Figure 2, the Digital Twin is a model, which
asserts that all systems are dual in nature. There is the physical version
of the system and a digital/virtual version or the information version of
the system. The Physical Twin on the left of the figure is the SCPS with
the characteristics that are discussed below. The Digital Twin on the
right is the digital/virtual version of the SCPS.
The Digital Twin model was first introduced in 2002
concept for Product Lifecycle Management (PLM) without giving the
model a name (Grieves, 2002). The model was soon named, but the
name has changed over time. It was originally named the Mirrored
Spaces Model (MSM) (Grieves, 2005), but later changed to the
Information Mirroring Model (Grieves, 2006). The model was finally
referred to as the Digital Twin (Grieves, 2011), a name that John
Vickers of NASA had coined for the model. While the name has
changed over time, the concept and model has remained the same
I had previously attributed the introduction to a University of Michigan meeting in December
2002. I recently discovered my presentation at a Society of Manufacturing Engineering (SME)
Management Forum in October of 2002 which had the model. This would have been the first
introduction since it predates the University of Michigan meeting.
I will admit to a certain inconsistency in naming. I have also referred to the model as the Virtual
Twin and the virtual product as a “virtual doppelganger.” The names are not the important
aspect, but rather the concept and model are.
As shown, these two versions are linked together throughout the
lifecycle. There will be different types of Digital Twins, depending on
the phase of the system’s lifecycle (Grieves & Vickers, 2016). The
Digital Twin Prototype (DTP) is the design version with all its variants.
The Digital Twin Instance (DTI) is the Digital Twin of each individual
produced artifact. DTPs should exist for all sophisticated manufactured
products, while DTIs exist only for products where it is important to
have information about that product throughout its life. Airplanes,
rockets, manufacturing floor equipment, and even automobiles have or
will have DTIs. Paper clips will not.
Digital Twin Aggregates (DTAs) are the aggregation or
composite of all the DTIs. DTAs are both longitudinal and latitudinal
representations of behavior. Their longitudinal value is to correlate
previous state changes with subsequent behavioral outcomes
enables, for example, prediction of component failure when certain
sensor data occurs. Latitudinal value can occur via a learning process,
when a small group of DTIs learn from actions. That learning can be
conveyed to the rest of the DTIs. Figure 3 shows an example of DTI
and DTA use in interrogation, prediction, and learning.
A core tenet of statistics is that correlation is not causation ((Bernard, 1982)). From a pragmatic
perspective of determining that a product failure may occur and avoiding it, we do not need
to understand the causal relationship. We simply need to know that certain state changes pre-
cede certain failures.
As with all twins, there is a “first-born”. The first-born in this
model is the Digital Twin. The product idea, shape, functionality, and
plans for realizing those always precedes the actual realization of the
product in physical form.
First-borns almost always have an advantage over the later
arriving sibling (Young et al., 1985). In this case that advantage is that
the model is called the “Digital Twin” model and not the “Physical
Twin” model. However, the Physical Twin is part and an extremely
important part of the model. Without the Physical Twin realizing the
system in atoms, the Digital Twin is merely a digital fantasy. However,
the term that is commonly used is the “Digital Twin”, which refers to
both the Digital Twin and its sibling, the Physical Twin.
The Digital Twin model as shown in Figure 2 seems to imply
that the Digital Twin and Physical Twin reside in two distinct spaces,
Physical and Virtual space. We work in one space at a time in a single
mode fashion and then transfer data and information to the other space.
That, in practice, is how we have worked with the Digital Twin
model. We worked in virtual space and translated that information into
physical space to create actual products and systems. We manufactured
those products and systems in physical space and sent that data about
the actual product and system to virtual space to create Digital Twin
Instances of physical products.
This single mode of working with Digital Twins is evolving
into a mixed-mode of working with the advancements in Augmented
Reality (AR) technology. We are now able to overlay physical space
with virtual space to work in both spaces simultaneously. This leads to
new use cases that will be described later.
The Digital Twin model has been used by NASA for spacecraft
(Caruso, Dumbacher, & Grieves, 2010; Glaessgen & Stargel, 2012;
Piascik et al., 2010) and by the U.S. Air Force for jet fighters (Tuegel,
2012), and proposed for aircraft health in general (Warwick, 2014). The
Digital Twin has been proposed for robust deployment of IoT (Maher,
2018) and for factory production (Post, Groen, & Klaseboer, 2017).
The oil industry is exploring the use of Digital Twin for ocean-based
production platforms (Renzi, Maniar, McNeill, & Del Vecchio) .
Digital Twins of humans have even been recommended for improving
patient health in medicine (Torkamani, Andersen, Steinhubl, & Topol).
The Digital Twin has widespread use by product development /
product lifecycle software providers. All three of the main PLM
vendors, Dassault Systemes, PTC, and Siemens, currently use the
terminology, Digital Twin. General Electric has used the term
extensively (Economist, 2015), (Castellanos, 2017).
3 Physical Twin
In order to understand the evolution of the SCPS, i.e., the
Physical Twin, there needs to be an understanding of the Internet of
Things or, as it is commonly referred to, IoT.
Internet of Things or IoT
When we refer about the Internet of Things (IoT), what are we
really talking about? The Internet itself began as a method to allow
people to communicate digitally over large distances
. The original
Internet was a 10 character per second (CPS) teletype system, whereby
academic and government researchers could communicate with each
other over the telephone network. Over approximately 60 plus years
Technically, the transmission itself was analog. Modems converted the digital to analog at the
transmission end, sent over the telephone network, and reversed it at the receiving end.
that has evolved into the modern version of having computers in place,
accessible by people or other computers, that would contain
repositories of information that allow the populating and consuming of
information at megabyte or higher speeds.
The term Internet of Things, or IoT, is of relatively recent
origin. Gartner defines the Internet of Things as “the network of
physical objects that contain embedded technology to communicate and
sense or interact with their internal states or the external environment”
(Gartner, 2016). There are few references to IoT prior to 2009 (Li Da,
Wu, & Shancang, 2014), although there was an early Scientific
American article that captured a number of the concepts that are part of
IoT today (Gershenfeld, Krikorian, & Cohen, 2004).
IoT has recently been described as the “Next evolution of the
Internet” (Pretz, 2013). Unlike many technology related concepts that
are only of interest to technical specialties, IoT has also garnered the
attention of organizational executives as a strategic initiative for
business (Porter & Heppelmann, 2014, 2015).
In a literal interpretation, the Internet of Things replaces people
with things themselves that have communication abilities. These non-
human “things” can then populate and consume data and information.
The reality is that the Internet of Things is actually an addition to the
Internet, whereby both people and things populate and consume data
and information and rely on their ability to interpret and act on that data
in order to be useful
The Internet of Things or IoT has been garnering a great deal of
recent attention. IoT is projected to grow explosively over the coming
decade. Gartner, a well-respected technology research firm, is
projecting IoT to grow from 3.8 billion connected devices in 2014 to
over 25 billion connected devices by 2025 (Gartner, 2014). This growth
is projected across a wide variety of industries.
The corresponding economic impact is equally substantial. The
McKinsey Global Institute projects that IoT could account for between
$3.9 trillion to $11.1 trillion in economic impact by the same 2025 time
Cisco Systems, a major Internet communications equipment company, has promoted the more
accurate term of “Internet of Everything”, or “IoE”. However, that term shows no signs of
prevailing in common usage and replacing IoT.
frame. While the majority of this economic impact is in advanced
countries, developing countries would also benefit substantially.
(Manyika et al., 2015).
The Industrial Internet of Things (IIoT) is a subset of IoT. IIoT
refers to IoT used in an industrial setting, most commonly a
. Investment in IIoT by manufacturers is
predicted to be in the trillions of dollars (Columbus, 2016). IIoT is
defined as “a network of physical objects, systems, platforms and
applications that contain embedded technology to communicate and
share intelligence with each other, the external environment and with
people” (accenture, 2015).
IIoT is used to describe other industrial uses, such as smart
electric meters. The use of IIoT in this chapter will refer to using IoT
technology in a manufacturing production environment. The reference
to IoT in this chapter will also include IIoT, unless otherwise specified.
IoT/IIoT will emphasize that the discussion is about both IoT and IIoT.
To some, IoT may be the next evolution with respect to the
Internet and certainly adds to the argument for a “Second System Age”
(Brynjolfsson & McAfee, 2014). However, the concept of SCPS for
products themselves (IoT) or production facilities for those products
have been part of Product Lifecycle Management (PLM) for
more than a decade (Grieves, 2006).
This chapter will extend the models of PLM and its Digital
Twin and specifically integrate IoT/IIoT into those models in the form
of Physical Twins.
So, what is the characteristic of a “Thingee” in the Internet of
Things? As indicated above, IoT “things” are briefly described as smart
IIoT equipment is commonly referred to as Operational Technology (OT) to differentiate it
from Information Technology (IT). OT and IT work together.
I use the term “product” to keep consistency with Product Lifecycle Management. The “prod-
ucts” of Product Lifecycle Management are also systems as commonly defined. However,
sometimes it is more appropriate to refer to a “system”, especially in the context of the factory
floor. “System”, “product”, and “machines” are used relatively interchangeably here. The
“system” on the factory floor is the “product” of the system manufacturer. Both are systems.
connected systems. This chapter proposes that Physical Twin (IoT)
products have these six elements: sensing, comparing, reacting,
communicating, CAR (collection, assessment, and response), and
protecting. The first three characteristics apply to smart products, which
we have had for quite a while. The last three characteristics apply to
We have had smart products or systems for decades. “Smart”
means that a sensing of some condition occurs. That sense is evaluated
against some desired condition. Some change is then initiated to bring
the current condition to the desired condition. A substantial part of all
life consists of being “smart”: determining what our situation is,
comparing it against what we want our situation to be, and closing the
gap between the two. This is the basis for the classic feedback loop:
sense-compare-react. Examples of these smart products are automotive
cruise control, airplane autopilots, and pacemakers.
We did not have smart products until we had electronics in our
systems. While hardwired electronic circuits did provide this capability,
it was not until the advent of the microprocessor with computing,
programming, and storage capability that we could exponentially
increase the capability of smart systems.
The first characteristic of an Internet of Things (IoT) system is
the ability to sense its environment. The sensing takes place much in
the way we sense things as we go about our daily lives. However, for
IoT-based products, they have the ability to not only sense the things
that we do with our five senses, but can sense many other things that
we cannot. They can sense parts of the electromagnetic spectrum that
we are unable to sense, infrared for example.
“To sense” is to be aware of something. Prior to electronics in
products, mechanical products did not sense. They simple reacted to
forces being applied to them. A ship’s rudder did not sense a hand
moving it. It simply reacted to the force of the direction. Even a product
that appeared to sense, such as a mercury based thermostat sensing
temperature changes in order to call for heat, were simply reacting to
forces. In the thermostats case, a bimetallic spring simply expanded or
contracted with temperature changes. Knowledge was “frozen” into the
mechanical product (Boulding, 1966).
However, when we discuss sensing in the context of IoT, we are
making the product aware. We think of sensing as taking the physical
world condition and turning it into an electrical impulse capable of
being recorded and acted upon. The mechanical tiller did not sense and
act. It simply reacted to the forces without leaving a record in its wake.
Sensing is important because it may provide an advance
opportunity to react to the stimuli it becomes aware of in order to take
advantage of beneficial forces or mitigate/avoid malevolent forces.
Main categories of sensing are: time duration, identity, state
changes, physical orientation and geospatial location, physical
presence, and forces. Some of the phenomena sensed are a combination
of these categories. For example, air flow measures the presence of air
and its force in order to obtain air flow velocity.
There is a huge variety of things that need to be sensed by
• The system’s own identity
• The location of a system and/or its components
• The change in velocity and acceleration
• State changes, both discrete and continuous, from one
state to another, such as off to on, not-triggered to
triggered, heat gradients over time
• The forces that are acting on the system, such as heat, air
pressure, and gravitational forces
• Presence of sound, light, and a wide spectrum of electro-
• The presence of other objects and their mass, shape, and
relative speed and direction in relationship to our
At the product assembly or component level, such as a turbine,
we are interested in such things as fuel flow, fuel reserves, engine
temperature, blade speed, and air flow. We are interested in sensing
state changes. For example, we want an indicator in a metal stamping
machine that a foreign object, like a hand or foot, is in the way.
We then want to compare what we sense against a goal we wish
to obtain. In older systems, that goal was usually set by a human
operating the system and remained static. Cruise control was set by the
driver by pushing a button when his or her car reached the desired
speed. A pilot entered the desired heading, altitude, and airspeed into
the autopilot. A system operator set physical stops that limited the
distance a cutting head could travel. Newer systems may have more
dynamic ways of setting goals, such as adaptive cruise control in
Smart product systems then take some action with the data. This
is the “react” phase that follows comparing. Some action is taken in
order to close the gap between the comparison done between the actual
and the desired. This reaction might be as simple as raising an alert, for
example turning on a light on a factory system PLC. It may be more
complicated, such as directly controlling the operation of the device.
To use our example of cruise control, the speed of the vehicle is
compared to the set desired speed. If the actual speed is less, the engine
is sped up. If the speed is more, the engine is slowed. In the past, a
good deal of this reacting was done by mechanical means. However,
more and more reacting is being done electronically. For example,
planes have gone from being actuated by hydraulic methods to being
controlled electronically or fly-by-wire.
Smart, Connected Product Systems (SCPS)
The ability to connect these smart product systems added a
major dimension. It meant that no longer was the smart product system
isolated and self-contained, but that the smart product system could
obtain external data and information in order to extend its capabilities.
Additionally, the requirement to be in physical proximity to the system
in order to extract its information was eliminated. In a smart system, a
factory robot would shut down when it detected an anomaly. In a
SCPS, the robot would send out email and/or text alerts to factory
supervisors and communicate its unavailability to other systems that
were routing parts to that robot.
To be considered part of the Internet of Things, the ability to
communicate was added. The ability to communicate the sensing
information and the actions taken is a result of processing that sensing
information. That sensing information is then transmitted to the
Internet. This is the key feature of what we call the Internet of Things.
Instead of this smart product system simply being self-contained, we
can now communicate the state of the smart system and the action that
it is taking to the outside world. Likewise, this smart product system
can receive information from the outside world.
This communicating is essential for the SCPS’ Digital Twin, in
order to keep the physical twin and its digital twin synchronized. While
this synchronization need not happen in real time, it needs to occur
often enough that any use case always has current information about
the system’s state. A key element that will always be transmitted is its
identity, which is required to identify its Digital Twin Instance.
Collection, Assessment, Response (CAR)
IoT product systems presumes that, as the sender, there is a
receiver that has a use for the data that it is transmitting. While we will
explore a number of uses in the Use Case sections below, we can
discuss in general what this characteristic entails.
The CAR function consists of three sub-functions. First, we
must receive the data and collect it. Second, we need to examine the
data to assess it. Finally, we need to respond to the information that we
extract from the transmission.
The scale of time frames, both the interval between IoT
transmissions and the collection-to-assessment period, and the scope of
the data of these transmissions vary greatly. It can be a short
transmission and a small amount of data with an immediate CAR. The
robot stoppage above means that the robot detects an anomaly and a
short-burst transmission occurs. Factory supervisors can then dispatch
the right maintenance technician to evaluate the anomaly.
It can also be a long period of transmission with a large amount
of data and a long delay as the data is processed and responses are
formulated. An example of this is the interval transmission of jet engine
sensors during takeoff, flight, and landing. The data from thousands of
flights over thousands of hours is correlated with subsequent
component failures to provide leading indicators of future component
failures. When data from subsequent flights with those leading
indicators are received, the service organization is alerted to replace
that specific component as the plane transits through the maintenance
hub on its next periodic visit.
Regardless of whether the communication is between IoT
product systems or between the IoT product system and a control
center, the CAR characteristics need to exist and be driven by use
cases. Although, as will be discussed below, IoT product system to IoT
product system communications called machine-to-machine or M2M
need to be overseen and optionally controlled via Digital Twins.
What is often overlooked is now that SCPSs can start
communicating, the most basic characteristic of the SCPS is the
responsibility of protecting itself. If a SCPS communicates both ways,
meaning that not only does it transmit information to the Internet, but
also that it receives information from the Internet that it acts upon, then
we need to be greatly concerned about security.
Built into the basic features of a Physical Twin system must be
a sense of security so that the system does not take dangerous or even
inappropriate actions or allow itself to be taken over by unauthorized
agents. Many decades ago, Isaac Asimov, the famous science fiction
writer, proposed three laws of robotics that, paraphrased and tweaked,
would seem to be relevant today (Asimov, 1950). Paraphrasing those
three laws for SCPS
These three laws began as a tongue-in-cheek prescription at a PLM conference discussing IoT
security. It stems from my lifelong interest in science fiction. Isaac Asimov was a brilliant
futurist and one of my favorite authors growing up. However, the laws resonated well and has
much to recommend as a prescription. Whether and how we embed these laws in IoT devices
is an interesting application problem. At a minimum, these laws should be guiding design
Three Laws of SCPS or Physical Twin Systems
1. A SCPS may not injure a human being or, through
inaction, allow a human being to come to harm.
2. A SCPS must obey the orders given it by authorized
sources except where such orders would conflict with
the First Law.
3. A SCPS system must protect its own existence as long
as such protection does not conflict with the First or
If we are going to build SPCSs, then we need to build into those
SPCSs this basic ability of protecting their users and themselves and
not allowing their security to be compromised. A key characteristic for
these systems is a substantial degree of paranoia. Implied in this is the
requirement to fail safely. If it detects an anomalous condition, a SCPS
need to retreat to a safe condition, such as an industrial robot pulling in
its arms and retreating to its safe, dormant position.
While this protection obviously applies to taking actions as the
result of receiving data from the Internet, care must be taken to protect
data via encryption that is transmitted to the Internet from the SCPS.
Being able to listen in on a SCPS transmissions by unauthorized
entities could compromise the security of the SCPS. For example, a
clear transmission from a factory system could give an outside party
attempting to gain information on a competitor’s factory processes key
information on product system settings, production run rates, or product
Dumb, uncommunicative (DU) products
An obvious question is the Digital Twin possible for a product
that is dumb and/or uncommunicative. The answer is that it is possible
for there to be a Digital Twin of these kinds of products. However, it
means that there needs to be an intelligent agent, which will usually be
a human, to observe the DU product and to update the Digital Twin
This introduces a time lag between the actions of the DU
products and the update of the Digital Twin. It also relies on the
intelligent agent being able to sense changes in the DU product. The
possibility of errors in the intelligent agent observing and accurately
reflecting the changes in the physical twin are a real concern. The
granularity and amount of information would also be a limitation.
In essence, informational twins have long existed for products,
albeit they have existed in paper and were not digital. Logbooks and
other paper records of changes to products have long existed. Airplane
logbooks have long detailed the operating conditions, maintenance
issues, and repairs to its respective airplane. Certainly, these can be
digitized to provide a Digital Twin.
However, this type of Digital Twin is actually only a change in
media, from paper to digital bits. The real value of the Digital Twin is
to take the intelligent agent out of the middle and have the product
assess itself and its environment and communicate with its Digital
Twin. The remainder of this chapter will assume that the products are
Integral Digital Twin
The Digital Twin is integral to the Physical Twin for a number
of reasons. First, there are two things we need to consider:
• A Physical Twin communicating with humans through
the Digital Twin who are, in essence, looking to control
the system, and
• A Physical Twin communicating with other systems,
which is often called machine-to-machine (M2M)
In the first situation, a Physical Twin communicating with a
human, the human needs to know the status of the system at any point
in time. Since we are talking about communicating over the Internet,
the human will not necessarily be in physical proximity to the Physical
Twin itself. Therefore, for a human to accurately know how to control
the physical system, the human needs to be aware of all the information
the system is sensing. That information is transmitted to and is
available in the product system’s individual DTI.
In machine to machine interactions (M2M), the Digital Twin is
imperative in understanding what is happening with two or more IoT
product systems communicating with each other. If we simply let the
systems communicate with each other and make decisions, they could
easily cascade out of control by making decisions that were
unexpected. By having a Digital Twin that shows the state of these
systems at any point time, there at least is an opportunity for
intervention if these systems start to cascade out of control.
At a minimum, in this out-of-control situation, we would have a
history of what had occurred with these systems in order to diagnose
the cause and make the necessary changes so that it did not occur again.
As shown in the Digital Twin model, the physical systems would be in
constant communications with their Digital Twin.
The Digital Twin would have the updated information about
how its physical counterpart is sensing and responding to external
stimuli. As shown in the Digital Twin model, the data would be
communicated to its Digital Twin that resides on the Internet. That
Digital Twin would have the ability to transmit information and
commands to the physical system in order to help the physical system
make decisions or allow a human interacting with the Digital Twin to
intervene if there were unexpected issues.
4 Digital Twins, Physical Twins, and System Complexity
There is disagreement on what “complexity” means (Nature,
2008), so unsurprisingly there is not agreement on what “system
complexity” means. Complex systems are claimed to be unpredictable
(Holt, Callopy, & Deturris, 2015), which could very well be the case
where inputs to the system involve human behavior or randomness.
Systems that are product artifacts, such as airplanes, space craft,
power generation systems, may not be theoretically unpredictable, but
they could be computationally unpredictable because of the
combination and permutations of outputs from possible inputs. These
systems have large network of components, many-to-many
communication channels, and sophisticated information processing that
makes prediction of system states difficult (Mitchell, 2009).
Using Grieves and Vickers Categories of Systems Behavior
model (Grieves & Vickers, 2016), (Figure 4), we can predict that
Physical Twins, i.e., SCPS, increase system complexity. There are far
more behavioral option outcomes when systems have computing and
communications capability. This is the Predicted Desirable functions
However, all the other categories will also increase. We would
expect a commensurate increase in Predicted Undesirable (PU) and
Unpredicted Undesirable (UU). While we also may obtain Unpredicted
Desirable (UD), this desirable outcome is offset by the fact that we are
not as knowledgeable about the system as we think we are.
The Digital Twin has the ability to mitigate system complexity.
In the create phase of the product lifecycle, the ability to model and
simulate system performance can allow us to reduce the unpredicted
behaviors by identifying them and moving them into predicted
behaviors. The PU behaviors can then be addressed.
In the operational phase of the lifecycle, we can drive our
Digital Twin simulations with actual data from product performance.
This would allow us to identify and address UUs before they actually
5 Digital Twin Manufacturing Use Cases
As shown in Figure 5, there will need to be considerations of
Digital Twins in the four phases of the product lifecycle: create, build,
use/sustain, and dispose. For Digital Twins to be successful, it will
have to create value for the users of these systems and devices (Ehret &
Wirtz, 2017). This value described as “use cases” outlines a specific
use that creates value.
While use cases exists for all phases of the product lifecycle,
this chapter will concentrate on use cases for the build or
manufacturing phase and the operations or sustainment phase. Build
use cases, often collected under the heading of Factory of the Future
(FoF), are of major concern to manufacturing firms looking to produce
lower cost and higher quality products. In particular, aerospace
companies are developing comprehensive visions of the Factory of the
Future (Airbus, 2015).
Digital Twin enabled product systems will have a role in configuration
management on the factory floor in two aspects: providing information
to its own Digital Twin as to its actions and performance on the factory
floor and creating the Digital Twin Instance of the products that the Phys-
ical Twin factory systems produce.
The first aspect will allow the factory systems to be fully monitored
and controlled. While there are numerous reasons to have configuration
and performance data from factory floor systems, this will be critical
when system-to-system communications take place that adjust manufac-
turing processes on the fly in real time.
The second aspect is creating a product’s Digital Twin so it can be
tracked throughout its life. This is a basic PLM requirement and requires
that the product’s as-built contains all the required information including
the parts and processes used and the details of how those processes were
performed. Smart systems down to smart hand tools can record the spe-
cific locations where things were done and the forces that were em-
ployed. Smart inspection stations can affirm that the product has met its
required specifications. An example is whether welds were completed
properly or that fasteners were installed correctly.
Many aerospace manufacturing companies have a procedure whereby
the people doing a particular work process “sell” the sign off. Smart sys-
tems and tools would objectively verify the correctness of the completed
Prognostics is the ability to look at the sensor data of all of the
same Digital Twin SCPSs and correlate those with SCPSs having
similar sensor data, and which then incurred a problem. By doing so,
we could predict when a certain part or component was on a path to
failure. We then could take action to repair or replace that part or
component prior to its actual failure. By having Digital Twins of all
like systems, we can correlate the history of all the systems with
subsequent failures and use that to predict future failures when we start
to see the same data of SCPSs that have not yet failed.
Factory disruption due to equipment failure is one of the
costliest events for manufacturers. Preventive maintenance is currently
driven by macro statistics developing periodic maintenance
requirements. This means that equipment that may not need costly
maintenance has it performed anyway and equipment that fails early is
not detected. Being able to predict future failures at the individual
machine level would lead to improved equipment uptime at lower
Cobotics is a recent neologism that combines “robotics” with
“cooperation.” This concept describes how robots will work in
cooperation with humans to perform tasks. There are two models of
this cooperation: working alongside a human and augmenting a human.
In working alongside a human, safety is critical. If robots are to
come out of fenced-in areas and work alongside humans, then they will
need to sense human presence and avoid jeopardizing human safety.
The Three Laws of Physical Twins suggested above will need to be
built in and inviolable for these robots.
The other role is to augment a human. This would entail a
human using augmented/virtual reality glasses to see through the
robot’s eyes. The robot would mimic the human gestures. This would
allow humans to augment their natural constraints at both ends of the
spectrum. At the macro end, they could lift and position large items. At
the micro end, they could do very fine detail work.
System augmentation is another useful case. Because the
factory system is sensored and feeds information to its Digital Twin,
analysis would be done on the historical performance data and then
modifications could be then developed for the software within that
system. That software then could be updated on the physical machines
with the Digital Twin tracking the system changes of the system
augmentation that is taking place.
Not only would it improve the equipment, but the detailed
record of the changes and why they were made would reside in the
Digital Twin for audit purposes. In addition, that data can be
aggregated over all like equipment to make determinations as to when
the systems as a whole were not performing up to specifications. This
would trigger a notice that changes would be needed to update software
in all the systems. Based on collecting the data and being able to
aggregate and make decisions about equipment changes, the Physical
Twin and PLM’s Digital Twin work hand-in-hand in enhancing the
system over its life.
As equipment ages, software changes could be made that might
compensate for inefficiencies creeping into the Physical Twin
components due to wear and tear. These inefficiencies could be
addressed before the system lost performance over time. By being
proactive with these changes, Digital Twin systems could maintain the
efficiencies that this equipment had when they were first installed on
the factory floor.
Factory Replication/Front Running Simulation (FRS)
Digital factory visual simulations have existed for more than a
decade. Their purpose has been to simulate the operation of a factory
from the work cell, to the manufacturing line, and finally to the entire
factory. The simulations are driven by assumptions of how the
equipment and labor is to operate. However, once the decision of how
the factory should be organized and built, these factory simulations
have usually been put aside.
Factory Replication proposes to repurpose these factory
simulations and make them factory replications by driving them, not
from assumptions, but from real time information from Digital Twin
factory floor equipment (Grieves, 2015). This Digital Twin of the
factory and its equipment is a real-time window into the factory floor
that would be available to anyone anywhere.
The next step after replication would be to run a simulation in
front of actual production from real-time data for a selected period of
time, i.e., seconds, minutes, hours, etc., to predict potential problems.
This is called Front Running Simulation (FRS) (Grieves, 2017). FRS
would be based on up to the minute conditions on the factory floor. For
example, FRS would predict a robotic clash that was assumed could not
happen but would now because of a momentary delay by one of the
4 Digital Twin Service Use Cases
The operation/sustainment phase of the product’s lifecycle is
often the longest phase, with some products lasting a half century or
longer. It is this phase that value is created for the product’s user in
better functionality or lower cost of ownership.
In this particular use case, the product would identify any new
parts that had been placed on the product and would update its Digital
Twin to show the configuration of any point in time. This could be used
for such things as product recall or a product update, ensuring that the
latest version of software existed within that product.
This would be the simplest of the Digital Twin use cases in that
it would simply have the state of the product at any point in time. So,
no matter where the product was in the world, information about the
product state could be collected and monitored for performance that
had been specified as the product requirement. Simple monitoring
exists for major items such as airplanes so that we would know where
each airplane is in the world. Although as we have seen from the
Malaysia Airlines Flight 370 disaster, not having this information
means that we are unable to determine the location of the airplane, let
alone the cause of the disappearance of that plane.
Next on the spectrum of Digital Twin value is the ability to not
only simply monitor the product it but to also assesses its condition. In
many cases we would be able to repair a malfunction by having the
software adjust for performance that was inferior or nonexistent. This
assessment requires access to the desired performance of the product
and to a constant comparison from the performance of the actual
product to that which is desired or required. In the event that there is
deterioration in the product performance or some sort of fail condition,
action can be taken in order to compensate for the problem, fail
gracefully, or, at a minimum, send notice to a service provider that the
product needs to be repaired.
This is the ability of being able to look at the data of all of the
same Digital Twin Instances, i.e., the Digital Twin Aggregate, and
correlate those with products that had similar sensor reading patterns
and then incurred a problem. By doing so, we could predict when a
certain part or component was on a path to failure. We then could take
action to repair or replace that part or component prior to its actual
failure. By having Digital Twins of all like products, we can correlate
the history of all the products with subsequent failures and use that to
predict future failures when we start to see the data of products that
have not yet failed.
With FRS described in the previous section, we can take this a
step farther. By running a Digital Twin simulation using real-time data
from its Physical Twin, we may be able to “see” minutes, hours, or
even days into the future. This would give us the opportunity to be
proactive about potential problems instead of being reactive. Running a
simulation of an oil rig from actual data might allow us to predict that
what looks like an innocent anomaly is actually the early stage of a well
blowout (Graaham et al., 2011; Mufson & Fahrenthold, 2010).
The Digital Twin model has had the implication that we worked
with the Digital Twin or the Physical Twin at any point in time.
Augmented Reality (AR) changes that by allowing work to be done
with both, simultaneously. In AR, the usage would be in a dynamic
fashion. The idea behind this is that a human who is working with a
physical system could use information that was being captured from the
physical system and transmitted to the Digital Twin which would then
process the data, massage it, and feed it back to that human.
An example of this might be a mechanic who is looking at an
airplane engine. That mechanic might be very interested in the
temperatures, airflow, and fuel flow that occurred within that engine.
The Physical Twin version of this product would be that sensors
located throughout the engine would be measuring such things as
temperature, airflow, and fuel flow and transmitting that data to its
Digital Twin. The Digital Twin would then be aggregating that
information, processing, and correlating that information, such that it
would provide meaningful information to the mechanic.
The mechanic would be equipped with glasses or contact lenses
so that when he or she looked at a particular part of the engine, the
Digital Twin would feed the mechanic information about what he or
she was looking at. If the mechanic was looking at the air intake area,
the Digital Twin would display on the mechanic’s glasses the airflow at
the exact point in time that the mechanic was looking at it. The Digital
Twin, when requested, could display a graph of airflow over the period
of time that the mechanic was interested in.
As the mechanic glanced at various parts of the engine, the
sensors that were reading temperatures would be displayed so that the
mechanic could see the various temperature readings. The Digital Twin
might also process and display the data such that the engine
components appeared color-coded depending on the temperature
gradients that were occurring in the engine. So the mechanic, when
looking at the engine, would see red, yellow, or orange colors to
indicate relative temperatures compared to the design temperatures that
had been predicted from that engine component.
This capture of information transferred to the Digital Twin from
the Physical Twin sensors, the Digital Twin manipulating that data, and
then feeding it back as various kinds of visual information, would be an
extremely useful use case of the Digital Twin with its Physical Twin.
Augmented Reality evolves the Digital Twin model from a sequential
single mode model into an integrated multi-mode model.
Product augmentation is another useful case. Because the
Physical Twin is sensored and is feeding information to its Digital
Twin, analysis could be done on the data and modifications suggested
to the software within that product. That software than could be
updated on the physical product, with the Digital Twin tracking the
product changes in the product augmentation that is taking place.
Not only would the product be improved, but the detailed record
of the changes that were made and why they were made would reside in
the Digital Twin for audit purposes. In addition, that data can be
aggregated over all the products to make determinations as to when the
products as a whole were not performing up to specifications and that
changes would be needed to update software in all the products. Based
on collecting the data and being able to aggregate and make decisions
about product changes, the Physical and Digital Twins work hand-in-
hand in enhancing the product over its life.
As products age, software changes might compensate for
inefficiencies creeping in to the physical product components due to
wear and tear. These inefficiencies could be addressed before the
product lost performance over time. By being proactive with these
changes, SCPSs could maintain the efficiencies that they had when they
left the factory floor.
The Digital Twin would prevent parts from being introduced
into the product that were not authorized for that product. By requiring
that, at a minimum, product components have RFID (Radio-Frequency
IDentification) capability, when that component was introduced into
the product itself, the information from its RFID could be interrogated
and transmitted to the Digital Twin. The Digital Twin would then run a
check with its authorized parts database to ensure that this new part
really was an authorized part and not a counterfeit.
RFID is an integral part of IoT technology and therefore
requiring critical or even non-critical parts to possess RFID hardware
could dramatically reduce the issues of counterfeiting that is found in
all types of products (Grow, Tschang et al. 2008) (Kim, 2009). This
counterfeiting is especially a problem in products that need to have
only authorized components because there are safety issues involved.
Generally industrial counterfeit components are counterfeit
because the producer of these kinds of components are skimping on the
quality or functionality that the component was designed to have.
Counterfeit products for the most part are not equal or better than the
authorized component, because that would put their costs on par with
that authorized product. Counterfeiting is generally done in order to
reap unusually large profits by having the counterfeit component be
inferior and cheaper than the authorized product.
Product performance feedback
The final Digital Twin service use case is product performance
feedback. Currently the state-of-the-art is that we do a pretty good job
in testing the product to ensure that the functionality of the product is
equal to what has been the designed requirement for that product. We
also do a fairly good job in the manufacturing phase in assessing that
the product meets the design specifications and that the appropriate
tolerances are maintained.
Where we do not do a very good job is in collecting the data
from the usage of the product to determine whether or not the product
actually performs to the design requirements. We attempt to get a proxy
for that by looking at either warranty costs or by servicing the product
at specific intervals to look for product degradation, but this is done on
a very inefficient basis, with large gaps in this knowledge base
With SCPSs, we can collect the appropriate sensor information
and feed that information constantly to its Digital Twin to determine
whether that product is indeed meeting its performance requirements.
In automobiles, this might be fuel efficiency. In jet engines, it might be
the appropriate amount of thrust in a specified period of time.
As mentioned before, the data from individual units can be
aggregated to show a profile of all units in order to understand the
spread of performance in the population of products. If the deviation is
large, this may say something about the design and the variability that
has been built in to the product. It is only by capturing this information
that we can actually understand whether the product performs as the
designers envisioned it.
There are many, many examples of products that have problems
uncovered in their usage stage only to have the next generation of
product have that exact same problem. This is because the designers
and engineers have not been made aware of how the product performed
in actual use, so they make the same design mistakes over and over.
6 Digital Twin Issues
There are a number of critical issues related to the Digital Twin
concept, which should be addressed before wide scale deployment.
While there are many more issues than discussed here, the more
important and higher visibility issues are:
Cyberphysical security is probably the largest and most
important issue on this list. It is critical because, if the information
coming from the Digital Twin/Physical Twin is not secure or the
system is not protected from intrusions, then the Digital Twin is a
liability. Even if the Digital Twin is only involved in monitoring, the
inability of a system to protect its data from outside acquisition is not
only problematic, it can put the system owner/user at risk.
As proposed in the Three Laws of Physical Twin Systems
above, one of the main characteristics of a smart connected device is
that it protects itself. If it cannot protect itself, then it is subject to all
types of problems from either the passive acquisition of data to the
active modification of its program that could be disastrous.
In the monitoring case, commercial spies could steal system
settings information to determine how specialized processes are
performed. In many curing processes, specific temperature settings and
durations are the critical factors that determine material formation
success. Outside agents can potentially hack Digital Twin systems for
their protected trade secrets. Even more benign “data leakage”, where
data inadvertently is leaked to outside systems, needs to be protected
against (Ulltveit-Moe, Nergaard, Erdodi, Gjosaeter, & Kolstad, 2016).
When we have the ability of two-way interaction between the
Physical Twin and its Digital Twin, we dramatically increase the
opportunity for malfeasance. We have already seen an instance of a
computer virus being weaponized to destroy industrial equipment
(Zetter, 2014). “Air-gapping” the systems, that is not having the
physical system be connected to the outside Internet, did not protect
industrial equipment from harm.
A malevolent outside force that gains control of factory systems
could cause those systems to not recognize their sensoring data
properly leading to massive and fatal accidents. It is one thing for a
personal computer that sits on a desk to be infected. It is quite another
thing for an industrial robot weighing thousands of pounds to be
infected and corrupted.
Within that realm of possibility is the threat of ransomware. The
office computer version is bad enough, with a company’s computers
data being encrypted until the victim pays a ransom for the encryption
key. Being informed that unless a company deposits $100,000 of
Bitcoins in the next hour that then the factory equipment will go
chaotic increases the danger and damage exponentially.
Massive data, limited information
Taken to its logical conclusion, the proliferation of the Digital
Twin indicates there can be massive amounts of data that would be
coming in from not only the system itself, but from components of that
system. The more Digital Twin sensors, the more data that would be
collected and transmitted. The key ability here will be to take these
massive amounts of data and translate it into useful information.
The tendency, at least early on, will be to collect all the data we
can simply because we can. We need to give serious thought as to how
can we turn data into information that is useful in making quality
decisions about the system and its use. We may design some of these
systems to collect that data, but before we start to aggregate and
transfer it, we need to make very, very sure that we have significant
uses for the information derived from this data.
With the rise of the Digital Twin, there may be many different
representations of its data, depending on the system manufacturer. This
may lead to even components within the same system having
incompatible formats and incompatible information because the
different manufacturers have not focused on working together.
Compounding that, there is a multitude of available and different
technologies up and down the Digital Twin technology stack, and even
different views of what that stack consists of (Li Da et al., 2014),
(Gubbi, Buyya, Marusic, & Palaniswami, 2013). It is highly
conceivable that a system with different components done by different
manufacturers would make different choices.
While in a fast-moving technological-based concept such as
Digital Twin, it will be difficult to produce standards in a timely
fashion. What users of the Digital Twin systems should strive for is to
push the various manufacturers to harmonize their systems so that
components in the same system will have, if not identical formats, at
least formats that adhere to harmonized rules. XML has been promoted
for a long time as the enabler of this kind of capability, but its high
overhead has diminished its usefulness. As computing capability
progresses, as predicted by Moore's Law, this XML issue will also
Machine to Machine (M2M) Escapes
Because systems do not possess common sense, they will do
whatever it is they are instructed to do, no matter how absurd those
instructions are. When we have humans interacting with systems,
humans can use common sense in understanding when the data is
flawed and unreliable. Humans can then decide when it is appropriate
to ignore the data.
Even with humans, common sense is often not so common.
There are many stories of people driving off roads into serious trouble
as they slavishly followed a GPS system. There have even been a few
fatalities (Clark, 2011). However, when systems are communicating
with other systems, this opportunity for following instructions that lead
to disasters is much, much higher. This is one of the critical reasons
why a Physical Twin needs to have a Digital Twin. If systems are
simply communicating among themselves, with no ability to have
visibility of their interactions, then these machine-to-machine systems
could cascade out of control without any human either knowing about it
or being able to intervene.
If, as proposed, we require that these SCPSs have Digital
Twins, then we would, at a minimum, have visibility into their
workings and understand when they start to act in an inappropriate or
even dangerous fashion. The requirement for the Digital Twin is that
SCPS-to-SCPS only communications should be banned as potentially
dangerous. The SCPS should require that the data collected and
transmitted between SCPSs also is collected in their Digital Twins. We
then have at least the opportunity to intercede in the event of a
While Digital Twin is about things or devices attached to the
Internet, it is also about people interacting with these “things.” Smart
product systems have been around for decades, but SCPSs are
relatively new. The characteristics of SCPSs are relatively straight
forward. However, the importance of a Digital Twin system protecting
itself cannot be underestimated. While some may think science fiction
might be a strange resource for approaching security, there is an
elegance of Asimov’s Three Laws of Robotics that could be
paraphrased and applied to Digital Twin systems.
Even with these kinds of rules or laws being built into Digital
Twin devices, the Physical Twin needs its Digital Twin to provide
oversight and control. This will be especially important in machine-to-
machine (M2M) interactions, where the potential for unforeseen
consequences and cascading failures increases dramatically. The
Digital Twin provides an opportunity for visibility and intervention.
The Digital Twin concept like all technologies need to be driven
by use cases that provide value to system users. The use cases here are
presented as a suggested beginning. It is by no means being asserted
that this is an exhaustive list. In fact, the expectation is that new use
cases will be discovered as Digital Twin technology advances. The
same can be said of the issues. This chapter explores some of the
largest ones, but there are others that will surface and will need to be
addressed. The Physical Twin (the physical system itself), the lifecycle
of the product, and the Digital Twin are closely interconnected. This
chapter is a first approach at tying these concepts together.
accenture. (2015). Winning with the Industrial Internet of Things. Retrieved from
Airbus (Producer). (2015). Airbus Factory Future. Retrieved from
Asimov, I. (1950). I, Robot (6th ed.). Greenwich, Conn: Fawcett Publications.
Bernard, G. A. (1982). Causation. In Encyclopedia of Statistics Science (Vol. 1, pp. 387-389).
New York: John Wiley.
Boulding, K. E. (1966). The Economics of Knowledge and the Knowledge of Economics. The
American Economic Review, 56(1/2), 1-13.
Brynjolfsson, E., & McAfee, A. (2014). The second machine age : work, progress, and prosperity
in a time of brilliant technologies (First edition. ed.). New York: W. W. Norton &
Caruso, P., Dumbacher, D., & Grieves, M. (2010). Product Lifecycle Management and the Quest
for Sustainable Space Explorations. Paper presented at the AIAA SPACE 2010
Conference & Exposition, Anaheim, CA.
Castellanos, S. (2017, March 21, 2017). GE’s Digital Replicas, Which Monitor Machines, Gain
a Voice. Wall Street Journal. Retrieved from http://blogs.wsj.com/cio/2017/03/21/ges-
Clark, K. (Writer). (2011). The GPS: A Fatally Misleading Travel Companion [Radio]. In NPR
Columbus, L. (2016). Roundup Of Internet Of Things Forecasts And Market Estimates, 2016.
Economist, T. (Producer). (2015, September 30, 2015). The digital twin. GE Lookahead. [Blog]
Retrieved from http://gelookahead.economist.com/digital-twin/
Ehret, M., & Wirtz, J. (2017). Unlocking value from machines: business models and the industrial
internet of things. Journal of Marketing Management, 33(1-2), 111-130.
Gartner. (2014). Gartner Says 4.9 Billion Connected "Things" Will Be in Use in 2015 [Press
release]. Retrieved from http://www.gartner.com/newsroom/id/2905717
Gartner. (2016). IT Glossary. Retrieved from http://www.gartner.com/it-glossary/internet-of-
Gershenfeld, N., Krikorian, R., & Cohen, D. (2004). The Internet of things. Scientific American,
Glaessgen, E. H., & Stargel, D. (2012). The digital twin paradigm for future nasa and us air force
vehicles. Paper presented at the AAIA 53rd Structures, Structural Dynamics, and
Materials Conference, Honolulu, Hawaii.
Graaham, B., Reilly, W., Beinecke, F., Boesch, D., Garcia, T., Murray, C., & Ulmer, F. (2011).
Deep Water: The Gulf Oil Disaster and the Future of Offshore Drilling. National
Commission on the BP Deepwater Horizon Oil Spill
Offshore Drilling - GPO.
Grieves, M. (2002, December 3, 2002). PLM Initiatives [Powerpoint Slides]. Paper presented at
the Product Lifecycle Management Special Meeting, University of Michigan Lurie
Grieves, M. (2005). Product Lifecycle Management: the new paradigm for enterprises. Int. J.
Product Development, 2(Nos. 1/2), 71-84.
Grieves, M. (2006). Product Lifecycle Management: Driving the Next Generation of Lean
Thinking. New York: McGraw-Hill.
Grieves, M. (2011). Virtually Perfect : Driving Innovative and Lean Products through Product
Lifecycle Management. Cocoa Beach, FL: Space Coast Press.
Grieves, M. (2015). Virtual Factory Replication. Effecient Manufacturing, 6, 5.
Grieves, M. (2017). White Paper: Driving Digital Continuity in Manufacturing. Retrieved from
Grieves, M., & Vickers, J. (2016). Digital Twin: Mitigating Unpredictable, Undesirable
Emergent Behavior in Complex Systems. In F.-J. Kahlen, S. Flumerfelt, & A. Alves
(Eds.), Trans-Disciplinary Perspectives on System Complexity (pp. 85-114).
Gubbi, J., Buyya, R., Marusic, S., & Palaniswami, M. (2013). Internet of Things (IoT): A vision,
architectural elements, and future directions. Future Generation Computer Systems,
29(7), 1645-1660. doi:http://dx.doi.org/10.1016/j.future.2013.01.010
Holt, S., Callopy, P., & Deturris, D. (2015). So it’s complex, why do I care? In F.-J. Kahlen, S.
Flumerfelt, & A. Alves (Eds.), Trans-Disciplinary Perspectives on System Complexity:
Kim, E. K. (2009, March 6, 2009). Suspect parts pester NASA. Florida Today. Retrieved from
Li Da, X., Wu, H., & Shancang, L. (2014). Internet of Things in Industries: A Survey. Industrial
Informatics, IEEE Transactions on, 10(4), 2233-2243. doi:10.1109/TII.2014.2300753
Maher, D. P. (2018). On Software Standards and Solutions for a Trusted Internet of Things. Paper
presented at the 51st Hawaii International Conference on System Sciences (HICSS-
Manyika, J., Chui, M., Bisson, P., Woetzel, J., Dobbs, R., Bughin, J., & Aharon, D. (2015). The
Internet of Things: Mapping the value beyond the hype. Retrieved from
Mitchell, M. (2009). Complexity : a guided tour. Oxford England ; New York: Oxford University
Mufson, S., & Fahrenthold. (2010, May 13). Oil spill investigators find critical problems in
blowout preventer. The Washington Post.
Nature. (2008). Language: Disputed Definitions. Nature, 455, 1023-1028.
Piascik, R., Vickers, J., Lowry, D., Scotti, S., Stewart., J., & Calomino, A. (2010). Technology
Area 12: Materials, Structures, Mechanical Systems, and Manufacturing Road Map.
NASA Office of Chief Technologist.
Porter, M. E., & Heppelmann, J. E. (2014). How Smart, Connected Products Are Transforming
Competition. Harvard Business Review, 92(11), 64-88.
Porter, M. E., & Heppelmann, J. E. (2015). How Smart, Connected Products Are Transforming
Companies. Harvard Business Review(October).
Post, J., Groen, M., & Klaseboer, G. (2017). Physical Model-based Digital Twins in
Manufacturing Processes. Paper presented at the Forming Technology Forum 2017,
Enschede, The Netherlands.
Pretz, K. (2013, 01/31/2016). The Next Evolution of the Internet. Retrieved from
Renzi, D., Maniar, D., McNeill, S., & Del Vecchio, C. Developing a Digital Twin for Floating
Production Systems Integrity Management. Paper presented at the Offshore
Technology Conference, Rio de Janeiro.
Torkamani, A., Andersen, K. G., Steinhubl, S. R., & Topol, E. J. High-Definition Medicine. Cell,
170(5), 828-843. doi:10.1016/j.cell.2017.08.007
Tuegel, E. (2012). The Airframe Digital Twin: Some Challenges to Realization. In 53rd
AIAA/ASME/ASCE/AHS/ASC Structures, Structural Dynamics and Materials
Conference: American Institute of Aeronautics and Astronautics.
Ulltveit-Moe, N., Nergaard, H., Erdodi, L., Gjosaeter, T., & Kolstad, E. (2016). Secure
Information Sharing in an Industrial Internet of Things.
Warwick, G. (2014, August 11/18). Digital Twin Would Track Aircraft Health Through Its Life.
Aviation Week & Space Technology.
Young, B. K., Suidan, J., Antoine, C., Silverman, F., Lustig, I., & Wasserman, J. (1985).
Differences in twins: The importance of birth order. American Journal of Obstetrics
and Gynecology, 151(7), 915-921. doi:https://doi.org/10.1016/0002-9378(85)90670-2
Zetter, K. (2014). Countdown to Zero Day : Stuxnet and the launch of the world's first digital
weapon (First edition. ed.). New York: Crown Publishers.