Received: 8 April 2020 Revised: 9 July 2020 Accepted: 7 September 2020
Operationalizing digital twins through model-based systems
Jason Bickford Douglas L. Van Bossuyt Paul Beery Anthony Pollman
Systems Engineering Department, Naval
Postgraduate School, Monterey, CA, USA
Department, Naval PostgraduateSchool,
In recent years there has been increased demand for readiness and availability metrics
across many industries and especially in national defense to enable data-driven deci-
sion making at all levels of planning, maintenance, and operations, and in leveraging
integrated models that inform stakeholders of current operational system health and
performance metrics. The digital twin (DT) has been identified as a promising approach
for deploying these models to fielded systems although several challenges exist in wide
adoption and implementation. Two challenges examined in this article are that the
nature of DT development is a system-specific endeavor, and the development is usu-
ally an additional effort that begins after initial system fielding. A fundamental chal-
lenge with DT development, which sets it apart from traditional models, is the DT itself
is treated as a separate system, and therefore the physical asset/DT construct becomes
a system-of-systems problem. This article explores how objectives in DT development
align with those of model-based systems engineering (MBSE), and how the MBSE pro-
cess can answer questions necessary to define the DT. The key benefits to the approach
are leveraging work already being performed during system synthesis and DT develop-
ment is pushed earlier in a system’s lifecycle. This article contributes to the definition
and development processes for DTs by proposing a DT development model and path, a
method for scoping and defining requirements for a DT, and an approach to integrate
DT and system development. An example case study of a Naval unmanned system is
presented to illustrate the contributions.
autonomy, digital twin, health monitoring, model-based systems engineering, prognostics, sys-
tems engineering, unmanned surface vessel
Today there is a significant investment into making systems and sys-
tems of systems smarter to better aid stakeholders in the operations of
equipment to improve performance or readiness. In industry, the inter-
net of things (IOT), and user intuitive displays make system interaction
and decision making far better than in the past. Today, early in a sys-
tem’s acquisition, stakeholders invest in models that aid in communi-
Published 2020. This article is a U.S. Government work and is in the public domain in the USA.
cation across stakeholders; many acquisition programs undergo some
form of model-based systems engineering (MBSE) to aid in the system
One of the primary tenets of MBSE is the concept of system reuse
throughout the system’s lifecycle. Today the emergence of the digi-
tal twin (DT) as an analytics framework provides new opportunities
to operationalize early investments in system models to perform anal-
ysis on the physical asset once fielded. Additionally, by leveraging
Systems Engineering. 2020;1–27. wileyonlinelibrary.com/journal/sys 1
2BICKFORD ET AL.
FIGURE 1 DoD digital engineering
strategy—integration of models1
early MBSE efforts to define the DT, analytic processes used to ver-
ify system requirements and early conceptual designs can aid in the
verification that fielded assets continue to meet mission objectives,
or trigger user intervention when the DT predicts the system will
not. In effect, an integrated modeling environment using MBSE can
become the DT of the asset if that type of performance analysis is
As a result DTs can be fielded much earlier in a program’s lifecycle,
which may have a larger net improvement on readiness, while simul-
taneously reducing the DT’s development cost by taking advantage of
modeling and stakeholder insights that define the physical asset itself.
This concept ties in well with the digital transformation efforts many
companies and government agencies are currently pursuing, notably
by arming stakeholders across all aspects of the development, opera-
tions, and support with intuitive and common data sets to drive better
One final thought for consideration, is by pursuing a robust systems
engineering approach to developing a DT, that twin itself is treated
as a separate system, and therefore the physical asset/DT construct
becomes a system of systems problem. This opens up a new paradigm
of integrated system design and modeling.
1.1 Digital transformation
Both the Department of the Navy (DoN) and industry are making sig-
nificant investments in digital transformations to better incorporate
data-driven decisions into every aspect of business operations and sys-
tem lifecycles. In 2018, the Department of Defense (DoD) released the
DoD Digital Engineering Strategy with objectives including formaliz-
ing the development, integration, and use of models to inform enter-
prise and program decision making.1One critical element in the DoD
Digital Engineering Strategy is the leveraging of various system mod-
els throughout the lifecycle, shown in Figure 1, to aid in better decision
making. For the DoN, the emergence of MBSE and model-based prod-
uct support (MBPS) provide a technical framework of integrated mod-
els to achieve these goals. The current focus on digital transformation is
a key concept for this article—everything stated as objectives in digital
transformation publications are also key objectives in the use of MBSE
to generate DTs. This article, and its contributions to the use of MBSE to
drive DT development to enable condition-based maintenance (CBM),
directly support the DoD Digital Engineering Strategy.
One significant improvement to the operations and sustainment of
fielded systems is the application of CBM—a strategy strengthened
by modern electronics and computing systems and which will sup-
port the aforementioned DoD Digital Engineering Strategy. There are
strong motivations to transition from time-based maintenance (TBM)
to CBM2–4 and leverage system modeling to drive data-driven deci-
sions throughout a product’s lifecycle. DTs are widely discussed as
a natural framework for tracking and reporting a system’s physical
condition, and employing predictive analytics, prognostics and health
management (PHM), and performance analysis tools for a deployed
asset.5–7 This article will explore alignment with the systems engineer-
ing requirements decomposition process and the implementation of a
DT to inform stakeholders of the physical asset’s health and perfor-
mance metrics, and drive a CBM strategy.
BICKFORD ET AL.3
FIGURE 2 Digital twin concept of operations (CONOPS)
1.3 DT overview
DTs are getting significant attention in both academia and industry.
Gartner has identified the DT as a top 10 strategic technology for
2017,82018,9and 2019.10 In the 2018 report, Gartner states: “A [DT]
refers to the digital representation of a real-world entity or system.”
The National Aeronautics and Space Administration (NASA) provides
a more detailed and technical definition. In 2012, NASA defined a DT
as an “integrated multiphysics, multiscale, probabilistic simulation of an
as-built vehicle or system that uses the best available physical models,
sensor updates, fleet history, etc.”11 Since a DT is the virtual represen-
tation of a physical asset, it makes sense that there are varying defini-
tions, because different stakeholders have different interests in their
DT. A reliability engineer may prioritize reliability tracking. A naval offi-
cer may care about performance predictions. An acquisition program
manager may care about cost and financial insights from the DT. To put
it simply, the authors propose that in general terms, a DT is a model
that helps stakeholders answer specific questions by providing a read-
ily available rapidly testable digital analog to the system of interest.
In 2018, Gartner stated: “Organizations will implement DTs sim-
ply at first. They will evolve them over time, improving their ability
to collect and visualize the right data, apply the right analytics and
rules, and respond effectively to business objectives.” The second point
that DTs will be simple at first but will incrementally evolve is a natu-
ral approach given two primary considerations: (1) the cost and com-
plexity of designing and implementing a DT can be cumbersome5and
expensive, which limits their development, and (2) stakeholders may
not know exactly what answers they will need from their DT. Develop-
ing a DT for a fielded system requires vision, expertise, and a systems
There are many types of DTs outlined in Section 2.5 but for this
article, the authors will emphasize one of the more complicated use
cases: leveraging DTs for prognostics and health monitoring. The gen-
eralized concept of operations (CONOPS) for a PHM-centric DT can
be found in Figure 2. The DT is connected and operates in parallel to
the physical asset. The physical asset provides sensor data, usage data,
and environmental data to the DT which then assists with maintenance
planning, provides tactical decision aids, and generates health and
reliability metrics. The outputs of this DT are leveraged by MBPS to
deploy proactive parts supply and training to resolve issues due to the
actual systems condition.
1.4 Today’s maintenance problem
Today, many assets are maintained via TBM practices.12 In the Navy,
preventive maintenance is often employed using a reliability-centered
maintenance (RCM) philosophy per the Reliability-Centered Mainte-
nance Handbook.2The problem with planning and scheduling main-
tenance based on clock or calendar time is it is inherently inefficient.
There are environmental and operational factors that influence the
required maintenance periodicity and when maintenance is performed
4BICKFORD ET AL.
purely off calendar time, those factors are not taken into account and
maintenance may not be performed when actually needed. Addition-
ally, preventive maintenance periodicity is often defined by recommen-
dations from the system designer and this practice is not applicable
when stakeholder’s primary objective is minimizing cost or maximizing
performance.13 This is not a new challenge; one study of machinery in
an automobile factory found that overall system effectivenesscan be as
low as 55% due to maintenance cycles.14 This demonstrates clear value
in optimizing maintenance periodicity. A poorly balanced maintenance
frequency results in both reduced availability14 and affordability.15
With a TBM philosophy, devices are either overmaintained or
undermaintained, potentially leading to inappropriate levels of down-
time. Many less common failure modes are experienced with failure-
driven models (FDMs) and components are operated until the point
of failure—resulting in downtime due to unexpected failures.16 In a
risk-adverse community there can be a bias toward over maintenance,
which is only made worse without strong data driving maintenance.17
Today’s rapid evolution in technology and increasing system complexi-
ties makes smarter maintenance a necessity. The net impact of under-
or overperformed maintenance is a degradation of availability, cost, or
both. This challenge has been observed for many years; in 1990 Wire-
man analyzed maintenance trends back to 1979 and found that main-
tenance duration trends have risen by 10% to 15% per year.18
To explore the interest in industry and defense2to transition from
TBM to CBM, it is worthwhile to look at the benefits of CBM and
weaknesses in a TBM strategy. For industry, there are profits to make;
for defense, arguments can be made for either economic or opera-
tional capability. The following factors demonstrate how maintenance
performed before or after the required maintenance action result in
1. If maintenance is performed prior to an ideal point in time, main-
tenance is overperformed and there is a resulting net waste in the
total labor and consumables. In a reduced manning environment,
this puts a tax on the maintenance crews. In an autonomous envi-
ronment, the device may be pulled offline prior to a critical mission
or at an unnecessarily high frequency for service, which in effect,
either reduces the number of operational days for each unit, or
increases the number of spare units required to support a task.
2. If maintenance is performed after the optimal point, maintenance is
underperformed and components can degrade at a higher rate, the
number of unexpected failures naturally rises due to fewer inspec-
tion periods. Unexpected failures may bring the system offline in a
time-sensitive period, and in the case of autonomous operations it
may lead to complete loss of a system.
3. If maintenance is driven by embedded sensors passing data
to stakeholders, maintenance can be performed precisely when
needed—minimizing downtime, excess consumable usage, and min-
imized component wear.
An additional challenge that exists with a TBM program is if mainte-
nance is not performed, there may not be objective quality evidence
reporting maintenance was not performed. One notable and signifi-
cant example of this was Alaska Airlines Flight 261, in which it was
found that insufficient lubrication led to the crash, after an investiga-
tion found a wide range of human, technical, and organizational factors
contributed to the event.19,20 Under a CBM philosophy, embedded sen-
sors can mitigate risk due to human error since sensors monitor sys-
tem health and provide additional confidence that the system is well
equipped to support the mission.
One final challenge with TBM for consideration is there are strong
motivations to leverage autonomous vehicles both to reduce oper-
ational costs21 and improve operational flexibility and agility.22 The
operations and scheduling of these assets is complex, as is their likeli-
hood of failure or loss23 so having a strong understanding of readiness
and maintenance required is even higher for these types of assets.
The discussion of TBM versus CBM is very well aligned with the dis-
cussion surrounding DT within this article, in alignment with the previ-
ous generalized definition for DTs from Section 1.3. The existence of a
readily available rapidly testable digital analog to the system of inter-
est provides infrastructure for the analysis of various data for decision
making. In this case, maintenance data can be monitored and corre-
lated to a desired outcome, and the aggregation and output of this anal-
ysis provides objective, quality evidence that status is understood and
operations are proceeding as expected and intended. In effect, the DT
collecting the necessary data provides confidence that the system will
support the mission in question.
1.5 Barriers to DT adoption
In some fields, notably the manufacturing sector, there is a significant
amount of research covering use cases and return on investment of
DT for remote diagnostics employment.24,25 Unfortunately as with the
adoption of a new and novel concept, the development time and costs
associated with building a DT make it a difficult undertaking for many
organizations. Often publications ignore the cost of DT development
as a barrier. Implementation of a DT may be difficult; the cost of a DT
may be extremely high or cost prohibitive.26 In a large program such as
the F35 Lightning, the relative investment cost in the DTmay have posi-
tive return on investment due to a widely fielded population of systems,
or a significant cost of operations and maintenance.5In the experience
of the authors, many programs with low populations of fielded assets
such as the Navy, the DT development cost barrier may seem insur-
mountable. Furthermore, there are only a handful of instances where
DTs have successfully been incorporated into the fielding strategy,24
and the prospective confidence in positive return on investment is hard
One major barrier to the employment of DTs is the process for
building or implementing them is a very use-case–specific endeavor, so
exploration of the academic literature yields very few resources that
provide interested stakeholders with a repeatable and generalizable
process or strategy for employment. DTs in the literature often cover
systems that are already in their operations and maintenance phase, so
the development is entirely an after-deployment consideration.27 This
ad hoc nature presents engineers and data scientists with challenges in
BICKFORD ET AL.5
the lack of a common process for defining requirements for the DT, an
unclear path for development, and a steep learning curve for the early
stages of implementation. The result of the previous factors is a high DT
development cost, and risk that the DT will not have the appropriate
functionality to maximize utility to its stakeholders. This results in an
overall cost/risk pair that will dissuade many sponsors—especially for
programs such as accelerated acquisition or developmental programs.
1.6 The case for developing a DT during system
Currently many Fleet systems follow a RCM model in which many
maintenance actions, notably for hidden failures in which there is no
noticeable symptom, are planned and scheduled based on the relia-
bility of components within the system.28 Given the randomness of
many failure modes, TBM is inherently inefficient;16 many mainte-
nance actions are performed before they are truly required—notably
in risk adverse communities17 such as the DoD, resulting in more main-
tenance labor than required and increased consumable use. Further-
more, when failures are experienced, corrective action time initiates
after the incident resulting in unplanned downtime that can have a sig-
nificant detrimental effect on business or operations.5,29
Often when dealing with internationally distributed systems, the
logistics delay times of getting parts to the end-user can take days
or weeks. In this environment, PHM tools that can predict such fail-
ures, then schedule and prioritize maintenance when it does not impact
operation of the system is enormously beneficial to stakeholders.
Human capital often ends up being one of the most expensive parts of a
business and as a result, many communities are trying to minimize the
number of people in the loop,30 and increase the use of data, analyt-
ics, and planning in support models. In the Navy, this is reflected in the
Littoral Combat Ship (LCS) community, which has dramatically fewer
sailors onboard than would normally be the case.31,32 In this environ-
ment, unnecessary or inefficient preventive maintenance puts a toll on
system maintainers, creating even more demand for analytics aiding in
maintenance analysis and scheduling.
A DT focused on supporting maintenance, failure predictions, and
monitoring system health is effectively a model with integration to sys-
tem sensors that provide stakeholders with automatic collection and
analysis of data to provide PHM insights. “The goal of PHM is to allow
systems operators to catch incipient failures early enough to be able
to prevent or correct them.”.33 Employment of PHM sensors early in
a system’s design can effectively reduce the likelihood of failure of
a component,33 so by initiating the scoping efforts of the DT during
early system requirements decomposition has the highest return on
1. DT development is efficient because many of the questions that
drive system synthesis as part of an MBSE approach also establish
objectives or requirements for the DT.
2. DT development can play an early role in identifying failure modes,
symptoms, and resulting impacts, reducing long-term reliability
3. DT development early in a program’s design arms PHM teams with
early recommendations of the types, quantities, and locations of
sensors that will aid the DT’s health monitoring of the physical sys-
tem For the use case of this article, the authors will explore the
operational impacts of deploying a DT for an unmanned system. In
the world of autonomous systems, there are not onboard users that
can assist with overcoming issues once a casualty is experienced.
Deployed autonomous systems may even be completely lost under
certain circumstances, resulting in an extremely high cost associ-
ated with the failure. Failure tolerance is lowest due to the impact.
Due to these factors, it is even more critical to perform necessary
actions before failures, which then drives up the preventive mainte-
nance frequency, further driving increased inefficiency.
In addition to development cost and timeline, there are other strong
reasons to begin DT development during system design. In addition to
the DT, infrastructure and tools to analyze the data are also required.
Within the physical asset, implementation of a DT may necessitate
additional data storage for data logging, additional processing to per-
form any edge analysis that is required, a data transport mechanism to
get the data to end users, and the end-user processing hardware, soft-
ware, and tools necessary to interpret the results.
DT-driven requirements within the physical asset are very impor-
tant considerations, which highlights the efficiency gained by architect-
ing and designing the DT in parallel. In the DT literature, DTs are either
built off of the current capabilities that exist in the fielded system, or
additional sources of data (sensors) are added to the system. In the first
case, the DT is limited in capability to the analysis of data sources that
were predicted as a required or valuable data source during design.
Accordingly the full capability of a DT may not be realized due to design
constraints. In the second case sensors are added to the device after
the system is fielded. This results in inefficiencies due to the added
steps of installing and integrating those sensors, and in many cases the
postfielding sensors are not as well integrated as those in the original
design. These reasons are part of our motivations to develop a process
that is intuitive that will aid in systems engineers in the architecting of
the twin as the physical asset is designed. Finally,in government organi-
zations, the costs associated with engineering changes postfielding can
be significant, so there is a strong motivation within the navy to build
and integrate the DT concurrently with the system of interest.
1.7 Specific contributions
One challenge in the field of DTs is there is no standard process for
implementing a DT. This article contributes to the definition and devel-
opment processes for DTs by proposing a DT development model
and path. This article specifically proposes a solution for scoping and
defining the requirements for a DT, as well as guiding system experts
through the process of architecting the DT by leveraging the tradi-
tional systems engineering efforts already integral to developmental
and acquisition programs. The result of this method is a DT devel-
opment process that is intuitive to systems engineers and requires
6BICKFORD ET AL.
FIGURE 3 Relationship of MBSE, FE, and physics-based models to DT development
lower systems engineering or developer time investment than if a DT is
developed as a separate activity postfielding. Specifically, this process
leverages the requirements development and verification processes to
guide the development of a DT, which is then employed to aid through-
out the maintenance phase. Finally, this article explores how the notion
of DTs fits in with the field of systems engineering, and describes how
a systems engineering approach to defining and fielding a system can
also aid in the development of the DT.
2BACKGROUND AND RELATED RESEARCH
There are five primary related research areas that are necessary to
be understood for the purpose of this article. These research areas
include: systems engineering, MBSE, DTs, PHM, and computer-based
modeling including finite element (FE) modeling and physics-based
modeling. MBSE provides a natural framework for developinga DT. The
developed DT is the foundation for implementing PHM algorithms that
will enable performing CBM.
2.1 Systems engineering
The systems engineering process leveraged throughout system design
is a very well understood process with decades of research and
methodology developed.34 While this article will not speak directly to
a specific systems engineering methodology beyond MBSE, it is impor-
tant to note that the majority of systems engineering processes have
the same fundamental stages for system design: requirements analy-
sis, system specification development, system design, implementation,
test, and operations/maintenance. This article emphasizes opportuni-
ties to align the development of a DTwith the systems engineering pro-
cess up-front in a programs lifecycle.
Integration of modeling and simulation to answer questions
throughout the design process is commonplace. Figure 3outlines the
generic systems engineering process, various tools available to prac-
titioners, and the relationship with DT development. There are two
notable considerations of the systems engineering process that will
be covered in more depth due to their significant contributions to the
DT concept: system architecture definition and stakeholder require-
MBSE is a field of study within systems engineering focused on the
execution of the generic process outlined earlier (requirements devel-
opment, system design, implementation, test, and operations) within a
model-based environment. MBSE is generally described as a method-
ology used by system architects and technical leadership to aid them
in the requirements generation and validation process, system syn-
thesis, and system verification. The International Council on Systems
Engineering (INCOSE) defines MBSE as “the formalized application
of modelling to support system requirements, design, analysis, veri-
fication and validation activities beginning in the conceptual design
phase and continuing throughout development and later life cycle
The use of modeling and simulations to aid in system design is a very
well-understood concept with numerous publications and instances of
use in industry. In 1990 INCOSE was founded and has the vision of “a
better world through a systems approach.”.35 Today in t he D oD , th e
majority of programs undergo some form of systems engineering, and
MBSE is becoming increasingly common.
One critical aspect of MBSE ideology is the transition from
a document-based acquisition to coherent modeling of a system
to describe and communicate among stakeholders. This approach
“enhances specification and design quality, reuse of system specifica-
tions and design artifacts, and communications among the develop-
ment team.”.36 The idea of model reuse is the fundamental goal in the
vision for fielding low-cost DTs to aid decision making, something that
is consistent with the goals and objectives of modern DoD acquisition
and engineering policies.
BICKFORD ET AL.7
In practice today, MBSE is most commonly found in the first appli-
cation, notably after 2003 with DoD Directive 5000.01, and 5000.02
establishes DoD policy that includes systems engineering. The 2003
version of DODD 5000.01 states “[a]cquisition programs shall be man-
aged through the application of a systems engineering approach that
optimizes total system performance and minimizes total ownership
costs.”.37 Due to this instruction, the use of MBSE is commonly used as
the formal process used to decompose stakeholder top-level require-
ments to subsystem requirements for defense acquisition systems.
One MBSE survey38 shows that the majority of MBSE processes
discussed are specific to the system synthesis process—notable is the
use through requirements analysis and decomposition. While DODD
5000.01, INCOSE, and many other sources state MBSE is applicable
to the full lifecycle of a system, there are very few publications on
how MBSE can be used for sustainment. Given that one of the primary
objectives of MBSE is to analyze performance and reliability, one can
safely conclude that the use of integrated models that aid decision mak-
ers in the analysis of a system of interest’s health and performance is
an MBSE application. For the sake of this article our MBSE application
is the use of this DT to analyze a live system’s performance, reliabil-
ity, suitability, remaining usable life, or other factors that stakeholders
would deem necessary during initial system fielding.
MBSE is defined by INCOSE as “the formalized application of mod-
elling to support systems engineering beginning in the conceptual
design phase and continuing throughout development and later life
cycle phases.”.39 In 2007, INCOSE expanded on this definition in their
vision for 2020 by describing specific applicable systems engineering
disciplines, stating MBSE is “the formalized application of modelling to
support system requirements, design, analysis, verification and valida-
tion activities beginning in the conceptual design phase and continuing
throughout development and later life cycle phases.”.40,41
In line with these definition, there are three applications of MBSE
that align strongly with the vision of building a DT in parallel to the
1. The use of modeling to aid in system requirements definition and
2. The use of models to assist with analysis to demonstrate a chosen
conceptual design will meet the necessary requirements.
3. The use of system models throughout a product’s lifecycle, notably
to assess system health, reliability, maintainability, supportability,
and fielded performance.
There are many different methodologies and tools currently in use
to implement MBSE.38,42–45 In the survey produced by Lu, he states
SysML is one of the most common MBSE languages. From an archi-
tectural perspective, the different system modeling languages (SysML,
UML, LML, and others) are general modeling languages. Huynh states
that “a general-purpose modelling language for systems engineering,
SysML is effective in specifying requirements, system structure, func-
tional behavior, and allocations during specification and design phases
of systems engineering.”.45 With respect to DT, all of the objectives
and outputs from the different MBSE languages offer insights that will
drive the definition and architecture of a DT. Given the fact that these
languages all support the objectives for driving DT development, this
article intentionally does not select or endorse one specific language,
tool, ontology, or process because it is up to MBSE practitioners to
select those tools that meet their specific requirements. Part of the
value in this methodology is the broad applicability to diverse types
The critical element of MBSE with respect to a DT is the nature of
a DT and is the merging of various models to answer specific ques-
tions. MBSE establishes a set of standards and an underlying ontol-
ogy, which can be adapted to an appropriate architectural framework
that guides the development of a DT. In some instances, early MBSE
models can evolve and expand over time, increasing in fidelity to the
point where they can become part of the DT. There have been sev-
eral demonstrations in the literature that MBSE modeling efforts can
evolve beyond traditional UML, SysML, or LML. System modeling lan-
guages have been demonstrated to integrate with MATLAB Simulink to
perform CPU processor performance assessments of different archi-
tectures in support of chip design,46 MATLAB for assessing perfor-
mance of bio implants,47 DEVSys for discrete event simulations,48 as
well as ExtendSim, SimPy, AnyLogic, NetLogo.49 MBSE system model-
ing languages have also been successfully leveraged for use in agency
modeling.50 These examples demonstrate the initial descriptive high-
level general models that traditionally would not integrate with future
analysis tools, physics-based, or FE models now enable a future MBSE
environment where UML, SysML, or LML software provides a frame-
work for on-demand assessment or trade–space analysis. This opens
up many new use cases, many of which align directly with current inter-
ests for future DTs.
From these points, it becomes clear that MBSE and the vision for
DTs are very closely aligned; if developers are able to integrate those
system models in the operations and sustainment phase of a program,
they together in essence become a DT. In summary, MBSE is the study
and application of system models throughout a system’s lifecycle, and
the authors propose a DT becomes the operational instance of those
various models developed in the early stages of a program.
2.3 FE and physics-based models
FE and physics-based modeling tools are incredibly valuable tools for
DTs. FE modelling identifies potential algorithms or models of interest
for inclusion within a DT. In effect, these advanced modeling techniques
are one of the first insights into a systems performance or failure mode
concerns and indicators.
Today many design or acquisition programs go through some level
of FE modeling to analyze structural performance and reliability.
Research describing the use of FE models date back to at least
the 1940s,51 and computer-aided FE models became popular in the
early to mid-1990s. FE models are of particular interest to this arti-
cle because they have been proven as a method for predicting the
reliability of structural components.52 Today FE models are com-
monplace during system design to identify critical parameters that
8BICKFORD ET AL.
influence specific design performance characteristics, and apply math-
ematics to gain system-specific insights on how requirements are met.
Today many computer-aided design (CAD) modeling programs contain
native FE analysis tools.
Physics-based modeling is often used for performance-specific
applications relevant to the system under consideration. Physics-based
or analytical models exist for a wide range of design areas including cir-
cuit design,53 electromagnetics,54 gas turbine engines,55 laser atmo-
spheric propagation,56 projectile impact,57 explosions,58 and a wide
array of other performance indicating parameters. Often these mod-
els are used throughout system development and test and evaluation
Since physics-based and FE modeling is used to verify that a system
design can meet specific performance characteristics, the insights from
FE modeling can be directly implemented in a DT. The multiphysics
foundation enables DTs to edge closer and closer to a true virtual rep-
resentation of a system, and not just a series of models with extreme
levels of abstractions. If integrating a physics-based model directly into
the DT is not practical, designers may be able to characterize perfor-
mance of the system based on operational or environmental condi-
tions, and embed sensors that capture data that inform operators if the
system is within or out of tolerances determined by models.
To provide an example to this concept—if a gimbal tracking system
needs to maintain a certain tracking accuracy and that accuracy is
dependant on jitter or vibration observed on the yoke arms, then
FE or physics-based modeling may be performed to determine the
vibration modes at the pedestal that results in performance degrading
harmonics. DT designers can then in turn incorporate the necessary
vibration sensors into the pedestal and yoke arms to measure data that
predict performance. The DT integrated with the system can either
run the physics-based model in parallel to the system, or perform
analysis based on the range of normal parameters identified by the
system. The resulting insights are then fed to operators in real time for
operational decision making, or leveraged for event reconstruction to
inform future operations, training, or maintenance decisions.
The final important aspect to FE or physics-based models is they
provide knowledge on the operational modes of a system being
designed. When compared with operational characteristics of similar
systems in the literature, designers may find examplesof other success-
ful performance or health characteristics in academic literature that
can be leveraged. These modeling tools also provide the opportunity to
leverage commercial off the shelf (COTS) tools—essentially providing
PHM off the shelf.
2.4 PHM overview
PHM was introduced in the 1990s by NASA and describes the study of
past failure data to devise ways to assess a system’s health based on
current monitoring data.33,59 In recent years, PHM has been studied
as an approach for assessing system health with the objective of intro-
ducing CBM to a system.60–62 Critically for the employment of CBM,
PHM provides predicted system health metrics that can be studied to
aid in decision making. In the DoD the primary interest in PHM is in pre-
dicting failures to minimize downtime or maximizing operational capa-
bility. While these motivations are applicable to a wide range of opera-
tional systems, there is particular interest in applications for unmanned
systems since there is not a “man in the loop” that can overcome tech-
nical challenges during operations. In these cases, PHM and notably
PHM for autonomous decision making, something that has also been
explored in recent years,63 is of very high value.
L’Her et al. state “[t]he goal of PHM is to allow systems operators
to catch incipient failures early enough to be able to prevent or cor-
rect them. The consideration of PHM hardware in the early phase of
engineering design can optimize the system design toward this goal.”.33
From this perspective, PHM strongly aligns with the objective of a DT
and provides the conceptual framework for capturing sensor element
data to assess potential failures and provide an overall healthy state.
For this case study, PHM is our primary means for enabling the desired
To implement CBM in a Fleet, system stakeholders need to lever-
age the application of sensors and predictive analytics/prognostics to
schedule maintenance based on when it is needed, versus the tra-
ditional TBM schedule or periodicity used in the past. CBM is an
opportunity to improve system availability, improve maintenance, and
reduce maintenance costs by resolving small issues before major issues
arise. On the other hand, preventive maintenance is based on symp-
toms observed or predicted to mitigate failures once they occur. In
order to successfully implement CBM, there are a number of crit-
ical elements that must be captured. The operational team needs
to understand remaining useful life of components, subsystems, and
systems, and maintenance activities must be scheduled based on
PHM has a number of similar challenges to DT fielding, notably that
PHM is often a consideration after the initial fielding of a system.33
This means a program does not benefit from PHM until some period
after fielding. Additionally, PHM is a relatively new field, especially
within the Navy; therefore many design teams may not have exper-
tise in remote monitoring or prognostics. To further complicate this,
many algorithms developed to understand health of components are
use-case or technology specific. Many approaches exist for implement-
ing PHM,13 and a variety of different types of algorithms exist for
components such as batteries,64 gearboxes,65 bearings,66 hydrotur-
bine blades,67,68 and others.
Due to the natural alignment between DTand PHM objectives, it can
be concluded that leveraging an MBSE methodology throughout sys-
tem design is a useful strategy and the framework for DT development
outlined in this article successfully aids stakeholders in PHM employ-
ment, but has broader objectives of identifying and implementing other
analytic techniques that might be of interest.
While some of the objectives of DT fielding align well with PHM, it
is important to note there are distinct differences, which will become
clear in the examples of different types of DTs. A PHM system or
algorithm is a component within a system, and rarely exists and pro-
vides value without the parent system. A DT can live as a separate
entity that provides an example of what a healthy system will look like.
BICKFORD ET AL.9
FIGURE 4 Google search trends—January 2010 through January 2020 Data source: Google Trends.69
Further, a high fidelity and well-integrated DT can assess the impacts
of component degradation on mission effectiveness, something tradi-
tional PHM systems often do not include.
In essence, PHM is one critical component in the evolving and
expanding objectives for DTs, but it is only one component that is com-
bined with other capabilities to deliver new and unique operational
utility. This also exposes DT development to the concept that the DT is
itself a separate system to be architected and integrated with the phys-
DT is a concept that has been described for a number of topics prior
to 2004, but has seen a significant rise in the last 10 years as shown in
Figure 4. The term DT essentially describes the development and field-
ing of a virtual representation of a system.70 There are a wide range of
different applications for DTs. DTs are characterized by the seamless
integration between the cyber and physical spaces, and have been suc-
cessfully implemented in product design, production, PHM, and other
fields.71 To highlight the diverse functionality of DTs, several research
areas and applications are described below.
In 2012, the NASA defined a DT as the multiphysics, multiscale,
probabilistic, ultrafidelity simulation that reflects, in a timely manner,
the state of a corresponding DT based on the historical data, real-
time sensor data, and physical model.11 This commonly cited defini-
tion helps clearly couple the relationship between a DT and objectives
2.5.1 Visual aids
For configuration management for infrastructure modernization,
the DT may provide a user friendly, authoritative source of a digital
view of a physical system that aids users in quickly assessing the as-is
state.72 One example of this type of DT demonstrated in practice
includes LiDAR scan point clouds of a power substation that display
the spatial locations and visual condition of equipment that allows
planners to quickly scan and assess physical assets and infrastructure
requirements. In this example, the DT is the dimensional data of how
the system of system relates to other elements within or external
to the system. In line with the authors’ summary of the objective of
aDTinSection1.3, this dimensional DT improves decision making,
operations, and maintenance by answering questions on the physical
layout of the as-built system. Those questions may be driven by needs
to expand capacity, remove and replace obsolete equipment, or even
translation into a CAD file type for analysis with other simulation tools
as mentioned in Section 2.3.73
DTs in many instances provide the infrastructure to analyze and report
PHM data to stakeholders to better plan and execute maintenance,
assist with troubleshooting, determine remaining usable system life, or
other health data as required by stakeholders. A NASA team,11 along
with many others in a variety of fields demonstrate the value of inte-
grated robust modeling to answer specific and complicated questions.
10 BICKFORD ET AL.
DTs have also been proven for airframehealth monitoring;74 in applica-
tions such as the NASA use case, the DT is responsible for monitoring
crack formation in NASA and Air Force aircraft. These types of appli-
cations can be invaluable for stakeholders managing a fleet of fielded
systems. As mentioned in Section 2.3, one place to look for insights for
implementing PHM focused DTs is early FE modeling, were there may
be significant reuse. Further background information on PHM is pro-
vided in a subsequent subsection.
2.5.3 Lifecycle sustainment models
For the logistics community, MBPS, or product lifecycle management
(PLM) has emerged in recent years and comprises of a family of inte-
grated models that can increase the efficiency of the operations and
sustainment phase of a system.75–79 PLM provides a capability that is
part DT of an asset, plus an analytics model of the supply system applied
to sustainment and the logistics tail. Integrated DT models are effec-
tively a DT of the asset, while MBPS delivers a DT of the supply sys-
tem among other capabilities. Combined they allow modeling and sim-
ulation of various use cases to optimize support including maintenance
overhauls, adaptive training based on how users interactwith a system,
enabling dynamic sparing postures, and enabling data-driven decisions
in a variety of other supportability considerations.
In manufacturing, a DT may be a tool that aids in implementing “Smart
Manufacturing” or improving the manufacturability of new designs,
notably in an IOT world where distributed stakeholders want to mon-
itor physical equipment or manufacturing processes, analyze through-
put, assess ability to manufacture a component with specific tolerances
in a manufacturing process with varying tolerances, and many other
2.5.5 DT takeaways
In the following methodology section, this article will demonstrate that
the natural MBSE process performed throughout system acquisition
helps stakeholders identify questions they want their DT to answer.
One will notice there is a common theme across the use cases and appli-
cations mentioned above. The application of the DTis focused on deliv-
ering insights on a physical asset’s condition to stakeholders to drive
data-driven decisions. Given the variety of possible DT applications,
the authors of this article propose an underlying general concept of a
DT: the purpose of a DT is to answer some specific question about the
system under consideration.
The key takeaway, and most general definition of a DT the authors
will propose, is that a DT is a form of virtual model that answers specific
questions. This is an important definition for the sake of this article, as
the designer of a DT needs to start with top-level requirements for the
DT. What specific questions do end-users need to answer? Examples
of the types of questions a stakeholder may want insights on include:
“How should this device be serviced based on it’s materiel condition?”
“What additional training should be incorporated based on user error
in the past?” or “How much remaining life exists within this physical
For the use cases described in the following case study, the proposed
concept of a DT will be a packaged multidisciplinary solution that deliv-
ers prognostics and heath management, with the ultimate objective of
driving CBM and informing logistics systems that leverage MBPS/PLM.
Many DTs aim to provide performance indicators for decision mak-
ing to stakeholders, mission planners, or operational units, creating
a demand for the reuse of performance models throughout the sys-
tem lifecycle. When considering DT architecture and software, FE and
physics-based models may be valuable for the rapid developmentof the
DT due to the potential for reuse of modeling from the development
phase of system acquisition. In the author’s experience it is not com-
mon for their continued use throughout the lifecycle.
While the following methodology is applicable to all of the DT concepts
identified in Section 2.5, utility for driving PHM will be the emphasis.
A description of such a DT is closely aligned to that of the NASA defi-
nition discussed in Section 1.3. Designers are interested in leveraging
embedded sensors and the data elements they produce as inputs into
modeling and simulation tools to support PHM, and prompt action by
operational and sustainment teams. While this is similar to the objec-
tives of PHM, DTs offer a much broader opportunity for real-time mon-
itoring to aid in operations, and an ability to reconstruct a sequence of
events based on sensor data. The end goal is to create an integrated
framework that provides near real-time visualization of overall system
health and streamlines the delivery of data to analysts and operators
allowing them to more easily incorporate data-driven insights into their
One common theme across the current literature and case studies
of fielded DTs, is demand for their development arises out of response
to some emergent need. In the NASA example,11 maintenance and sus-
tainment teams needed an integrated model to monitor crack devel-
opment and structure health impact on aircraft lifespan. In other cases,
practitioners will find similar drivers during the operations and sustain-
ment phase. It has been shown in the literature that the inclusion of
PHM sensors into a design can have a significant improvement on over-
all system availability.33 Since a DT provides the framework for PHM
implementation, this conclusion can be made here as well, when consid-
ering the use case of unmanned systems where the long-term value in
a DT is high due to a significant need to understand and monitor actual
system health. As a result there can be great benefit in a systems engi-
neering approach to DT developmentthroughout system development.
In this article, the authors propose a process that aids stakehold-
ers and decision makers in the initial conceptualization and architec-
ture of a DT, as well as address the value added for DoD stakeholders.
BICKFORD ET AL.11
TAB L E 1 Systems engineering and MBSE efforts
Lifecycle phase Systems engineering processes MBSE efforts
Concept exploration Concept exploration Capability views
CONOPS development Operational views
System-level requirements (Reqs) System services models
Preliminary design Subsystem-level requirements Activity diagrams
High-level design System views
Detailed design Component-level requirements System models
Detailed design Performance models
Implementation (assembly) Hardware and software development CAD model iterations
System assembly Performance model iteration
Product support model iterations
Test and evaluation Component requirement verification Use of system models
Subsystem req verification Performance and
System verification product support models
Performance testing to verify system operability
Suitability testing and performance
Operations and maintenance Lifecycle sustainment Use of various models to maximize
Reliability analysis reliability, availability,
Performance analysis and performance
The authors’ vision of the concept of a DT is an integrated composite of
different algorithms and tools that help analysts and operators incor-
porate data into their decision-making process. In the context of this
article, the authors are focusing on the operations and performance
assessments application of a DT. Those in the operations and sustain-
ment communities will glean insights for their respective industries.
One persistent challenge with the employment of DTs is in practice,
they are often undertaken as a capability applied to a system post its
initial fielding. As a result, the development of this DT is a new addi-
tional activity the sponsor and stakeholders must fund. This limits the
fielding of DTs to large programs in which the development cost is low
relative to the program’s budget, or programs with high numbers of
deployed assets that raises the number of systems benefiting from the
DT, spreading out the development cost overmultiple applications. This
is something that the Navy cannot rely on—especially in communities
with low-yield high-mix configurations due to rapidly evolving technol-
ogy and capability. Given the current state of rapid technological evo-
lution, unmanned systems and directed energy are good examples of
these types of programs; there is no strong appetite to build robust
system-specific analytic tools when the system under consideration
will field in a small number, and will be obsolete in a few years.
In order to overcome this inherent challenge with DTs, the authors
propose the following methodology that can leverage a significant
amount of the work and thought processes followed by the majority of
DoD customers. The following methodology is applicable to programs
both in-development, or currently fielding, and may lend insight to DT
development for fielded systems.
3.1 Systems engineering process
The following methodology is applicable and tailorable to a number
of different systems development and fielding processes. For illustra-
tion of the following methodology outline and case study, the authors
describe the following lifecycle phases and the accompanying systems
engineering processes, and MBSE Efforts of high importance to DT
development (Table 1).
Through this system development framework, outlined in Table 1,
it is possible to break down the specific questions and data elements
that will define the scope, objectives, and drive the implementation of
the DT. By doing so, subject matter experts are not duplicating previous
work that was performed by previous systems engineers. The following
outline in Figure 5provides the decision process of architecting the DT
throughout the traditional MBSE process. It is important to note that
while a DT is codeveloped with the physical asset, the DT’s develop-
ment can actually precede the development of the system itself, and in
the right circumstances can in fact aid in the development of the physi-
cal system by providing a modeling and simulation framework. Further,
12 BICKFORD ET AL.
FIGURE 5 Digital twin development through MBSE process
these early DT discussions should also drive component-level require-
ments for the physical asset to maximize PHM opportunities.
3.2 Step 1: Concept exploration
Throughout the concept exploration phase, stakeholders analyze the
system of systems involved in the intended mission to identify how the
new system works within this operational context. Concept exploration
includes the development of the system CONOPS, and the derivation
of system top-level requirements. This phase is critical for assessing
both the intended use cases and mission threads of the system, but
these questions also provide significant insights to what stakeholders
will desire from the DT; this is essentially the ideal time to identify the
primary purpose of the DT.
3.2.1 Step 1.1: CONOPS
During the CONOPS development phase, systems engineers lever-
age MBSE to identify external system interfaces, and define the mis-
sion context and mission threads. The authors propose that this stage
also helps define the scope of the DT, and its CONOPS for use. The
CONOPS development for the system also helps identify the various
external interfaces that exist to support the mission. Those external
interfaces may be valuable sources of data in support of mission perfor-
mance analysis, reliability assessments, or logistics implications of the
current state of operations. From a technical perspective, this is a good
time to identify local and remote consumers of DT data. DT designers
can identify the ideal location for the DT to reside; if the primary con-
sumer of data is an operator of the system, it may makesense for the DT
to reside collocated with the device—especially in circumstances with
constrained communications or bandwidth limitations. If the primary
user of the DT data is a remote or shore support team, the DT may make
sense to reside at their site, or in a cloud linked to the internet or gov-
3.2.2 Step 1.2: Top-level requirements analysis
During this phase of system development, the acquisition team takes
the system CONOPS and stakeholder top-level requirements, and
explores the set of possible solutions. At this point in system develop-
ment, the authors propose that the systems top-level requirements be
used to identify what types of high-level decision making aids may be
valuable DT outputs. These top-level requirements are also a valuable
source of information regarding the specific mission parameters and
performance indicators the DT can provide answers for. For improving
operations and sustainment, the primary applications for DTs include
reliability, maintainability and maintenance planning, health monitor-
ing, and performance assessments. This is the appropriate time to iden-
tify what specific functions this DT needs to perform.
If the consequence of an unexpected failure is catastrophic or the
cost of a missed mission due to down equipment is high, stakehold-
ers may desire a DT that aids in the assessment of system reliability,
maintains system-specific reliability parameters, and can predict fail-
ures and remaining system life. This may be the case for systems like
unmanned vehicles that may be difficult to recover if there is a failure
BICKFORD ET AL.13
during operations and therefore the financial and operational cost of
unexpected failures is high. If a fleet of systems are sustained with lim-
ited maintenance throughput, the duration of maintenance becomes
an operations planning driver, or other maintenance challenges that
result in high value in maintenance scheduling and prioritization, then
a DT that tracks system health and correlates maintenance actions
to extended system longevity is high priority. If mission performance
or mission success is of high criticality such as a self-defense system
or surveillance system, then a DT that supports performance analysis
to provide insights on system performance based on materiel condi-
tion may be desirable. The ability to provide rapid decision aiding tools
based on environmental or health assessments can be invaluable to
Stakeholders must ask where concern areas are, or where data-
informed decisions have high return on investment; this will inform the
engineering community of priority analytics functions within the DT.
Notable DT goals may be to maximize availability, minimize required
resources, or drive better use of the system based on performance
analysis. Potential high return on investment capabilities include per-
forming predictive analytics to enable CBM, improve maintenance
scheduling and priority, maximizing system availability, predictive part
failures analysis, or other factors. Notable insights include concern
areas that can be tracked or identified by the DT, impacts and value of
those early indications, and the necessary external interfaces that will
exist for the DT.
3.3 Step 2: Preliminary design
During the preliminary design phase, systems engineers take the top-
level requirements, a mission thread, and the CONOPS, and decom-
pose those requirements into the critical functions that the system
must perform. The authors propose that this is the appropriate time
to take the previously identified objective and functions of the DT and
develop the support DT architecture, and the CONOPS of the DT’s
employment. If the program is using a rigorous MBSE process, the anal-
ysis performed through MBSE is directly applicable and may be lever-
ageable for the DT development. Any mission modeling that is per-
formed to drive requirements can also be leveraged to analyze mission
degrading impacts due to physical, materiel, or environmental condi-
tions. These insights identify system sources of data to meet defined
DT objec ti ves.
In later stages of the preliminary design phase, systems engineers
leveraging MBSE increase the fidelity of system models through the
modeling of activity diagrams, various system views, interface dia-
grams, and resource diagrams to help derive subsystem-level require-
ments. During this phase, subsystem-level requirements and a high-
level design begin to come together. The developer of the DT can
start to assess what generic data element types inform stakeholders
of subsystem-level health and performance characteristics in support
of the previously mentioned DT objectives. If physics-based modeling
is included in the MBSE work performed by the systems engineering
team, then these subsystem data elements, algorithms, and integration
requirements should be leveraged within the DT—either by the reuse
of MBSE models becoming the foundation of the DT, or by the repli-
cation of the MBSE process and framework within the DT leveraging
other analysis or modeling and simulation tools.
This is the appropriate time to revisit the DT objectives to concep-
tualize the data requirements to support the DT. One general DT data
element of high interest for a broad array of DT applications is oper-
ational sensor data. If embedded sensors are expected to exist within
subcomponents of interest, those data outputs may be useful for trend
analysis and correlation to specific casualties, may indicate or trigger
specific maintenance actions, and may provide insights to system-level
performance impacts based on subcomponent performance indicators.
For a reliability, failure prediction, and remaining system life DT, it
may be beneficial to begin to build a detailed system tree or config-
uration document identifying all components within the systems, and
the missions they support. Data should be associated with each entity
within the system configuration documentation. Specific data types
that will aid in the analysis include but are not limited to casualty track-
ing data, configuration data, component history and usage data, envi-
ronmental data, and operational data.
For a DT with requirements to support maintenance scheduling and
prioritization, the DT will likely need to consume maintenance data,
sensor data that indicate degraded performance, and some level of
remaining component life indicators to drive the replacement of com-
ponents that are high risk.
For a DT that emphasizes performance analysis, the primary data
source for analysis will be the previously mentioned subcomponent
sensor feeds. DT developers and systems engineers should work with
the component subject matter experts to identify how subcomponent
performance is traceable to system-level performance so that system-
level performance indicators can be created from component sensor
data. One possible valuable architecture for this type of DT is the con-
cept of risk-based decision making81–83 to inform mission planners of
the various probabilities of mission success.
At this point in a system’s design process, PHM or performance
assessment methods will come into play. DT developers should begin
to work closely with component engineers to identify and verify the
right data sources and data elements are being considered. It is criti-
cal to capture derived system requirements that are necessary to sup-
port the DT, and ensure those requirements result in the necessary
hardware and software changes to support DT. It may be necessary to
revise the design to include additional sensors to ensure the appro-
priate data will be available in the final product. By this point, the
DT framework should be well established, and estimated data can be
entered into the DT for test and validation that the DT supports mission
Once the DT architecture and data elements are defined, it is appro-
priate to begin to develop the digital thread, or the integration of sys-
tems and communication channels that transfer DT data from sources
As the system’s conceptual design matures, so will the DT as spe-
cific data elements of interest can be inferred before final parts selec-
tion. If enough investments are made in the DT, it can now start to
14 BICKFORD ET AL.
be used as a design aid by providing modeling and simulation capa-
bilities for the analysis of alternatives. This may come in the form of
a detailed requirements tree that assists with allocation of reliability
requirements, jitter budgets for laser, radar, or electronic warfare sys-
tems, or other health or performance characteristic metrics of inter-
est. When considering the development of the DT, this is a good time to
finalize the DT’s architecture, and identify what sensors are expected
to exist within the system that data need to be collected from, what
application programming interface (API) is required to collect and dis-
tribute that data, and what the resulting data collection and storage
requirements are for the DT.
3.4 Step 3: Detailed design
As the system design progresses into component-level requirements
and a detailed design, sensor or component-specific data elements
need to be mapped to the appropriate functions and algorithms
within the DT. Many derived component requirements may need to
be pulled into the DT. For example, a highly redundant phased array
radar’s effective transmit power scales with the low-level compo-
nent powers. These types of component-level design trades drive a
detailed system design that meets system-level requirements. For a
performance-focused DT, this analysis is the foundation for the future
DT’s performance analysis algorithms. Modeling performed to confirm
that component-level parameters support system-level requirements
lend direct insight to how that data, when collected and monitored,
will assist in PHM or performance analysis.
If these component design trades are not performed through the
MBSE process, the opportunity still exists for design engineers to
develop algorithms assessing component-level performance variations
on the system-level performance or reliability capability, but the DT
development will require more attention from the component SMEs.
Various disparate DT algorithms or models can now start to be
integrated where possible. If risk-based decision making is being used
to build a composite recommendation based on disparate PHM algo-
rithms, this is the appropriate time to start determining weighting fac-
tors for the different models.
From a DT development perspective, by the end of the detailed
design phase, DT designers should have enough information by this
point to finish the preliminary design for the DT, ensure the included
analytics techniques and algorithms perform correctly. If so, DT soft-
ware can be written, artificial data used to verify interoperability, and
3.5 Step 4: Implementation (assembly)
During the software and hardware development phase, the system
under consideration materializes as the system is assembled from its
base components. This means sensors, hardware elements, and soft-
ware that generate data that will be analyzed by the DT now become
available to DT designers. As a result, a best practice would be to
leverage the DT to feed performance insights back into the system’s
design as an analytics framework. During prior steps, DT designers take
insights from the system’s design to drive the development of the DT.
By this point the DT’s objectives, architecture, and design should be
stable and the DT sensor requirements previously identified should be
manifesting in the physical system.
3.6 Step 5: T&E
When the system transitions into the T&E phase of the program, DT
developers now have an opportunity to begin to use the DT, collect test
data, and train DT algorithms. There also may be opportunities to use
the DT and algorithms to support T&E, as outlined below.
3.6.1 Step 5.1: Component-level testing and
At the component testing phase of system development, the design
team begins to collect data on the performance of system components.
This makes it a good time to start demonstrating the capability of the
DT, and depending on level of design maturity of both the DTand physi-
cal system, the DT may be a valuable tool for manysubcomponent tests
and validations. As components start to transition into component-
level testing, any data collected should be loaded into the DT to verify
algorithms work as intended. This may be a reasonable time to begin
collecting these sensor data to build the system’s data library. In certain
circumstances, the design team can use the DT to model actual com-
ponent performance and the expected impact on system-level perfor-
mance. This can assist with validation that the chosen parts do support
the top-level design.
Finally, the logging and storing of component data throughout the
system’s lifecycle may be a desired function of the DT; if this is the
case, the DT should be collecting and logging serial number specific
data elements. These data elements will be valuable for comparing
laboratory versus field conditions impact on performance, and over
time will be the initial data elements for long-term reliability and per-
formance trend analysis. Additionally, if there are performance differ-
ences between identical fielded units, these historic component data
elements may provide valuable serialized data sets for analysis and
3.6.2 Step 5.2: Subsystem-level testing and
During subsystem testing the involvement of the DT is very similar to
that as in component-level testing, but by testing higher level assem-
blies, designers may have better interfaces to work with. If DT devel-
opment is advanced enough, the actual interface that passes data from
the physical asset to the DT may be stable and can be used and verified
BICKFORD ET AL.15
3.6.3 Step 5.3: System-level testing and
As the program enters system-level testing, the design and test teams
should now be able to leverage most of the M&S capability within
the DT and it can be a valuable asset for performance analysis. If
the DT is focused on reliability modeling, maintenance scheduling and
prioritization, or feeding a PLM tool or logistics chain, then the DT
may not have large enough sample sizes to be high impact. In these
circumstances T&E data should be collected to support the build-
ing and refining of algorithms—especially if machine learning is to be
3.7 Step 6: Operations and maintenance
Once the system under development hits deployment, operations, and
maintenance, the DT should now be employed with the physical asset.
A rigorous data collection, storage, and analysis process must be estab-
lished to build a strong data set with which the DT can draw insights
from. Stakeholders should start addressing feedback or recommenda-
tions from the DT when making decisions about operations and sus-
tainment of the system. If recommendations are good, confidence will
grow in the DT. If recommendations are bad, the DT must be refined as
DT development does not end once the physical asset is deployed.
As with any data science program, increasing volumes of data improve
model accuracy and analytics capability. Data collected in the early
stages of the program are essential to refining these models. Fur-
ther, stakeholders such as fleet stakeholders may identify emergent
requirements for the DT, or changes to the DT based on changes to
the support infrastructure, depot locations, updated maintenance task
analysis efforts, etc.
3.8 Methodology summary
The methodology outlined in this section demonstrates that the pro-
cess for defining, architecting, building, testing, and deploying a physi-
cal system naturally aligns with the process a systems engineer would
take to design and build a DT. The methodology demonstrates how key
MBSE processes that drive system architecture also drive DT architec-
ture. Critically, the discussions around the development of these mod-
els support the development of the DT including:
1. Operational views provide insights to where the DT should inte-
grate with the system and where data might be consumed.
2. Activity models show the system actions and interactions of inter-
est for DT monitoring.
3. System hierarchymodels show the system of systems, components,
and subcomponents of interest for display or monitoring.
4. Scenario diagrams show mission threads of particular interest if
there is motivation to model mission performance.
From a return on investment perspective, this methodology accom-
plishes two goals for stakeholders. First, the DT is available to support
early phases of the program—possibly including T&E. The up-front
investment in a DT model ties together all of the available analysis
performed throughout the lifecycle, rather than a limited subset,
maximizing total utility. Second, DT development is not an isolated
delayed activity initiated postfielding after a systematic issue has been
observed in the operations and sustainment. Given these concepts, it
is fair to assume these two factors result in decreased overall cost of
DT development and employment.
This section presents a case study to illustrate and demonstrate the
method proposed above. The case study presented here is not an
exhaustive study of a specific system. Instead, the case study shows
how the method can work in a simplified manner to highlight the bene-
fits of the method.
4.1 Unmanned systems background
In recent years there has been an explosion of unmanned systems
entering the maritime environment. A wide range of both surface
and subsurface unmanned systems are currently operational. Of note,
Seagliders have been employed for academic and research purposes
for many years.86–90 In the surface community, unmanned surface ves-
sels (USVs) have seen significant growth in recent years as well. In
2016 the U.S. Navy fielded a medium displacement USV named the Sea
Hunter,91 with an operational architecture defined by Casola et al.92
Use cases of these systems range from logistics transport vessels,
environmental data collection and monitoring, surveillance and patrol,
and a wide array of military applications.93 For the case study of this
article, the authors will build upon the conceptual USV (USV) mission
sets described by Corfield and Young,94 Ru-jian Yan et al.,95 and Yaakob
et al.96 In these examples, the concept of unmanned systems are thor-
oughly explored as a cost effective, low risk, force multiplier—notably
for littoral environments.93 The specific use case under consideration
is the use of a distributed fleet of USVs for the patrol of a remote island
area. Of particular relevance to the topic of DTs, unmanned systems
offer a new challenge when compared to manned vessels—unmanned
vessels do not have a human in physical contact with the asset that can
resolve or mitigate risk from unexpected failures. As a result of this
challenge, there is lower tolerance for risk and increased need for fault
diagnosis, fault tolerant controls, and redundancy.97
This case study will leverage an idealized unmanned surface vehicle
(USV) to compare theoretical availability both with and without a DT
developed in parallel to the system.
As shown in Figure 6, there are a number of commercially avail-
able unmanned systems that are inherently modular and can support a
variety of hardware modules and missions. Notable examples include
the Arctic Research Centre Autonomous Boat (ARCAB),98 Aquarius
16 BICKFORD ET AL.
FIGURE 6 Currently available unmanned surface vessels of
interest for this case study
USV Vessel under development by Eco Marine Power,99 MANTAS
Unmanned Surface Vessel developed by MARTAC Systems,100 or sev-
eral products produced by 5G International Inc.101 These systems are
shown and described to familiarize the reader with comparable real-
world systems. The following case study will not assess any of these
vehicles directly, and will leverage a generic USV architecture.
USVs are regularly cited as a natural platform for surveillance.102
For this case study, an idealized fictitious operational scenario will be
used. This case study is illustrative of the method and is representa-
tive of what might happen to the real system but is explicitly not used
to make engineering decisions about any real specific system or ongo-
4.2 USV mission context
A small fleet of USVs operate out of an unmanned or minimally manned
forward USV base, as seen in Figure 8. These USVs autonomously
patrol a coastline via fixed GPS coordinate waypoints. The specific
coastline in consideration is of important strategic value and the cost of
a missed or failed patrol is considered high to stakeholders. Due to the
remote operation area, logistics delay times are significant and main-
taining a large manned contingent becomes costly.
4.3 USV scenario
The following system assumptions are made in the case study:
1. The unmanned vehicle’s primary purpose is littoral patrol.
2. The unmanned vehicle is semiautonomous and can run missions
based on GPS waypoints.
3. The unmanned vehicle is based out of a forward operating,
unmanned or minimally manned port and has the ability to periodi-
cally replenish its fuel reserves.
4. There is a fleet of 10 unmanned systems.
The following stakeholder assumptions are made for the sake of this
1. Inability to perform a mission is of high consequence.
2. Lossof communications of the USV has a high likelihood of resulting
in complete loss of a USV.
3. Due to the cost of sustaining the forward-operating base, assets in-
theater are kept to a minimum, including maintenance crews, sup-
port personnel infrastructure, tools, and spare parts.
4.4 Case study systems engineering process
For this case study, the high-level generic architecture consists of a
battery-based energy storage module (ESM) that serves as the primary
energy stores for the USV, an electric propulsion system, a satellite
communication (SATCOM) system, surface electro-optical (EO) cam-
eras for surveillance, water sampling systems, and an onboard com-
puter that controls the USV. An example block diagram can be seen in
The following describes the systems engineering methodology, and
the resulting DT insights gained at each step.
4.4.1 Step 1: Concept exploration
Stakeholders require an USV that can operate in a remote forward
operational area. Due to the high volume of searchable area that
requires patrolling, and the significant burden of sustaining a large
team at this remote site, USVs have been identified as the appropriate
asset. USVs will execute continuous patrolling operations along a long
and extensive coastline.
Due to the remote nature of this forward operating site, the port
is minimally manned to reduce logistics requirements, which puts an
increased priority on the ability to predict and plan maintenance, hard-
ware remaining usable life, and potential hardware failures. The imple-
mentation of PHM to aid in the prediction and scheduling of mainte-
nance is a key function of the DT.
Due to the high priority of this specific coastal area, inability to per-
form a mission due to unplanned maintenance or hardware failures is
high consequence. Given the nature of autonomous operations, there
is an always present risk of total system loss due to some critical fail-
ures. These factors drive requirements for the DT to monitor each
USVs health, perform predictive failure analysis. For this case study,
this drives a confidence in availability to 95%.
Due to the potentially long transit times of the USV, and loss of
awareness if a unit is recalled and a replacement is redeployed—
stakeholders will want the DT to answer questions regarding the sys-
tem’s ability to successfully perform a mission based on the perfor-
mance metrics of its components. This decomposes to a requirement
for the DT to perform analysis for sensor systems, propulsion systems,
and communication systems. Algorithms that aid in the tracking of the
health and performance of these components is of high value to avoid
BICKFORD ET AL.17
FIGURE 7 Block diagram for the notional USV
FIGURE 8 USV operational environment
Given the stakeholder requirement analysis performed throughout
the concept exploration phase, the DTs CONOPS can now be formal-
ized. There is concern with missed missions, and lost USVs due to unex-
pected system failures. It is important that at this point in the require-
ments analysis to assess stakeholder risk tolerances.
1. Predictive failure analysis: will identify components that are at
high risk of near-term failures. Local stakeholders will leverage this
information to plan near-term preventive maintenance and deter-
mine which assets should execute specific missions. Predictive fail-
ure analysis will also be used to prompt the ordering of repair parts
when certain risk thresholds are met.
2. Health monitoring: will aid in mission planning to ensure vessels
selected for specific missions have the ability to perform the nec-
essary mission, and will help plan longer term maintenance actions
such as major system overhauls that will take USVs offline for
extended periods of time.
3. Physical location: given that the primary consumer of DT data will
be the operations and maintenance teams so it is logical for the
DT to reside at the forward USV base with some of the process-
ing performed by the USV. General health monitoring data can be
remotely transferred to additional stakeholders via an internet con-
nection. Operators will want constant health and status of the USV
and there is also value in emergency PHM reports directly from the
18 BICKFORD ET AL.
USV to the forward base to aid in recovery after an unexpected
Taking the required functions and general CONOPS from the pre-
vious step, DT developers can now identify the general types of algo-
rithms that will support these mission areas. For component fail-
ure predictions, algorithms and methodologies need to be gathered
from application-specific literature and collaboration with the physical
asset’s design teams as the system’s preliminary design solidifies and
the types of components are identified.
4.4.2 Step 2: Preliminary design
When an acquisition program gets to the preliminary design phase,
DT developers know the general DT CONOPS and architecture and
can outline the DTs architecture. Embedded sensors throughout the
USV provide data to the USV onboard computer, which performs basic
data reduction and sends status updates to the shore support com-
munity. Upon return to the Forward USV base, data are uploaded to a
computing system. As the preliminary design progresses and the high-
level USV design depicted in Figure 7is selected, the DT developer can
begin to look at the available PHM literature to identify the specific
System models such as activity diagrams, interface diagrams, and
service models inform stakeholders that shipboard infrastructure is
required to collect PHM data. The onboard computing module within
the USV already contains the necessary interfaces to support this
Once the general DT CONOPS is defined, it is valuable to assess
current PHM and performance analysis techniques that are applicable
to the system under consideration. This helps refine the DT architec-
ture and identify system sources of data. For this case study example,
PHM is widely studied for Lithium Ion batteries, and tools are available
such as the Adaptive Recurrent Neural Network (ARNN) developed by
He et al.64 to conduct PHM analysis. For the application of PHM for
the electric propulsion system, a process such as that developed by
Ginart et al.103 may be useful. Identifying these types of algorithms that
exist help clearly identify system sources of data, or areas where senors
might be of interest.
This process may not work for all subcomponents in the system. For
example, SATCOM antennas come in a variety of architectures with a
wide array of electronics. In these cases, working with the component’s
OEM to model or derive reliability parameters may be necessary.
Toward the end of the preliminary design phase of the USV’s archi-
tecture, we now have a defined DT architecture, we have identified
system sources of data and some types of general algorithms that will
assist with the necessary analysis, data requirements can start to be
defined, and a digital thread can be established. DT system require-
ments can now start to be integrated into the system’s requirements
documentation, and as hardware is selected, assessments can be made
regarding whether or not included sensors are sufficient to meet DT
requirements, and if not—additional sensors can be designed in during
the detailed design phase.
4.4.3 Step 3: Detailed design
As the system transitions into the detailed design, DT architects can
now verify that the chosen design meets the necessary sensor require-
ments for the DT, and DT designers can now verify these parameters
are available for the selected battery systems in the USV, and these
data elements can be mapped to specific sensors of interest. At this
point, a data/sensor traceability matrix may be of value to ensure all
PHM data streams have the appropriately identified data source.
Any physics-based models or FE models generated for system
assessments also come into play at this point. With a relatively simple
system such as this USV, PBMs are likely to only be performed for the
surface vessel’s structure, and induced jitter on the sensor payload. It is
assumed that this is the case, and these models are mentioned below.
188.8.131.52 PHM algorithms and considerations for the USV case study
For the lithium-ion batteries in the power storage module, the PHM
algorithms use internal impedance, cycle numbers, and battery aging
rate to determine remaining useful life. Cycle numbers and internal
impedance is readily available for most lithium ion batteries so data col-
lection is trivial. The battery-specific aging rates need to be character-
ized, so that data will need to be included in test plans for component
testing so that they can be analyzed and the necessary PHM algorithm
can be developed to support initial fielding.
For the propulsion system, Ginart103 has shown PHM can be imple-
mented by analyzing the inverter pulse-width modulation (PWM)
waveform to analyze transistor degradation. PWM data need to be
included in the DT plan, and the design team needs to ensure integra-
tion between the onboard computer and the necessary sensors to cap-
Strain gauges and fiber optic sensors are one accepted way to
monitor structural health and fatigue.104–108 Grisso and Drazen have
demonstrated the use of sensor data for DTs of ship structures.105
Fiber optic sensors are inherently rugged, and instrumenting a rela-
tively small USV with these fibers is a very achievable endeavor. This is
an area where PBM may have playedan important role in hull selection.
Models used for the assessment and downselect should be assessed
to determine if the new application of PHM sensors align with model
inputs or outputs. If so, bounds or correlated values may be drawn for
early versions of the model.
Employing PHM for complex electrical systems can be challenging.
In the case of the SATCOM subsystem DT developers have options.
First, they can rely on the built in test capabilities provided by the SAT-
COM system vendor. Second, DT developers can inspect the system
and perform a failure modes effects and criticality analysis (FMECA)109
to assess the various failure modes that will result in degraded mission
performance, a failed mission, and total loss of an operational asset.
For each of these failure modes, DT developers can analyze the various
embedded sensors supporting each mission, and work with the design
BICKFORD ET AL.19
team to collect data sets that can be correlated to each failure mode.
Prognostics failure mode/sensor data correlation and algorithm devel-
opment can be a major undertaking so it may be best to defer to the
OEM for a small program.
PHM for electro-optic systems (EO/IR) will likely be focused on
degrading sensor performance and the EO/IR’s ability to support mis-
sion requirements. Monitoring changes from baseline or the sensors
ability to modify contrast, blur, noise, or dynamic range will provide
indication of system performance. Stakeholders can analyze these per-
formance indicating parameters to correlate outputs to performance in
detecting and identifying targets at required ranges. There have been
several studies and methodologies developedto apply PHM to complex
electrical systems that may aid design engineers and DT developers in
building capability within their systems.110
The DT data source and algorithm mapping is now driving embed-
ded sensor requirements, the onboard computing system now has the
additional requirements of hosting the DT models, and the SATCOM
antenna has the additional requirements of providing data link to the
forward USV base.
184.108.40.206: Develop DT software
For the implementation of the DT, developers have a number of
different tools at their disposal. DT work can be done in LabView,
Simulink, MATLAB, Python. In general, any tool that can support
the required analytic processes can work. There has recently been
the emergence of advanced software tools that have built in physics
engines and models that can accelerate some development timelines.
In our use case, the DT is intended to run continuously during oper-
ations and partially resides within the physical system therefore a
human-in-the-loop excel based or other software tool that works opti-
mally when controlled by a user is not desired.
For the architecture of the DT described, as previously men-
tioned embedded system sensors continuously collect data during nor-
mal operations. Block-specific algorithms analyze those sensor data
streams and provide maintenance and performance insights to oper-
ations and maintenance teams.
The final remaining key component of the DT is something that
translates individual component knowledge into actionable infor-
mation. In this case, the DT is monitoring the individual health of
4.4.4 Step 4: Implementation
During the system implementation phase, the DT framework should
be developed, algorithms should be notionally established, and where
possible validated or tuned with real data captured during any compo-
nent testing that was performed during the detailed design.
In this case study, we will keep the specifics general to remain hard-
ware agnostic. During system implementation, the DT should be fully
integrated with the physical asset: sensors identified in the previous
step must be integrated into components, data interfaces must be
established between sensors and the onboard computer to collect and
analyze data, operations and maintenance recommendation tools must
be established, and data collection/transfer software must be written
to deliver data to stakeholders for postevent construction.
4.4.5 Step 5: T&E
Given that the primary purpose of the USV DT is to predict failures,
track reliability, aid in maintenance planning, and indicate probability
of a future failed mission, the DT in this case study is not expected
to have significant value to stakeholders during the T&E phase. Areas
where this may be reconsidered include specific parameters stakehold-
ers may have identified as critical key performance indicators such
as EO/IR performance assessments, propulsion performance param-
eters, power storage voltage or amperage values under load, or SAT-
4.4.6 Step 6: Operations and maintenance
Once the system enters operations and maintenance, the DT becomes
fully operational. For the analysis of the impact of implementation
of the aforementioned DT on a USV, notional mean time to fail-
ure (MTTF) data has been identified for the blocks of the USV
under consideration. The following table identifies these reliabil-
ity parameters. Additionally, this DT monitors optical sensor perfor-
mance, which will predict possible mission failure due to performance
The primary delivered function of this DT, as shown in Figure 9,
provides health and performance characteristics on the SATCOM,
onboard computer, EO/IR, hull, energy storage, and propulsion sys-
tems. While valuable, these insights have limited value to an entry-level
USV operator or maintainer. A maintenance and mission planning rec-
ommendation system front-end is a necessary final component.
4.4.7 DT development summary
The previous steps demonstrated that the various stages of MBSE
usage during the system development process can clearly help scope
and define the requirements for the DT. Specific to this case study,
stakeholders see high value in a DT that aids in predictive analytics
to minimize downtime. Throughout the DT methodology, specific PHM
algorithms and methodologies were identified that will aid in the future
PHM that will drive predictive analytics and enable CBM. It is impor-
tant to note that there is a common theme in the PHM processes
identified—they require the usage data, sensor data, and environmen-
tal data to perform their functions. The individual algorithms within the
DT make system-specific recommendations to operations and mainte-
nance crews for the upcoming maintenance and parts required for con-
It is also important to note that there is also an opportunity to lever-
age the data coming out of the DT to aid in improved usage of the sys-
tem. This would be done through monitoring usage of some of these
20 BICKFORD ET AL.
FIGURE 9 Final DT architecture
blocks, but the modeling of that impact on system operation is a use-
case–specific application and is slightly out of scope of this article given
the objective of the case study is demonstrating the ability to leverage
the MBSE system development process to generate a DT. Further, the
analysis in this case study demonstrates there is a high potential for
very early return on investment from this development.
4.5 Assessing DT availability improvements
Since the specific components, sensors, and operational context were
generalized in this case study, actual performance analysis of the con-
ceptual DT cannot be determined. Assessing the impact of a conceptual
DT, however, is a great way of demonstrating applicability and value in
the application of a DT. In this case, we can estimate the baseline theo-
retical availability of the USV system without a DT based on data found
on vendor websites and within the literature. That baseline number can
be compared to an estimated value based on a theoretical improve-
ment by a DT that offers insights on required maintenance or potential
For the reliability modeling of the deployed USV, the availability
modeling process used for this case study is described by Ward et al.111
Figure 10 shows the sequence of events within a Monte Carlo simu-
lation. Reliability data, shown in Table 2were gathered from a num-
ber of manufacturer specifications for representative hardware. Crit-
ical parameters for this model include MTTF, sometimes referred in
other publications as mean time between failures (MTBF), mean logis-
tics delay time (MLDT), and mean time to repair (MTTR). These terms
are all defined in OPNAVINST3000.12a.112
TAB L E 2 Notional failure rate data for the USV
System functional block
SATCOM 10,000 336 3
Onboard computer (OBC) 25,000 168 4
Electro-optic sensors (EO/IR) 25,000 336 3
Energy storage module (ESM) 130,000 336 3
Electric drive (ED) 25,000 720 16
The reliability and availability numbers under assessment have been
captured from a variety of manufacturer and academic sources. It is
assumed that each major assembly has a normal distribution for its
MTTF,MLDT, and MTTR. Delay times are estimated based on the expe-
rience and numbers observed by the authors in their professional expe-
rience given the operational scenario outlined in this case study.
4.5.1 Monte Carlo simulation
To assess the theoretical system availability pre-DT incorporation, the
data in Tables 2and 3were used. No variation was added to the mean
times to repair as any deviation in material challenges are captured in
the variance of MLDT. It was found that the system would experience
an operational availability of approximately0 .93. If stakeholders deter-
mine they want a 95% confidence that no missions will be missed, that
will drive the number of available USVs or spare parts to support the
missions up significantly.
BICKFORD ET AL.21
FIGURE 10 Monte Carlo simulation: Ward et al.
TAB L E 3 Notional failure data standard deviations for the USV
System functional block MTTF SD (hours) MLDT SD (hours)
SATCOM 3,000 168
Onboard computer (OBC) 7,500 168
Electro-optic sensors (EO/IR) 7,500 168
Energy storage module (ESM) 39,000 168
Electric drive (ED) 7,500 168
The improved operational availability significantly reduces the con-
cerns for maintaining an inventory of spares for the operational pop-
ulation. From the traditional operational availability (Ao) calculations
defined in OPNAVINST3000.12a,112 we can generate theoretical Ao
values for each individual block within the USV. The equation for Ao is:
(MTTF +MDT)where MDT =MLDT +MTTR.(1)
In the equation above, MTD is mean down time, an aggregate of
any downtime factors including logistics delays, admin delays, outside
assistance delays, or others.
From the values in Equation 2,anAoof0.917canbecalculatedfor
the pre-DT condition.
This also provides the opportunity to field casualty or failure-
specific training when needed along with the component, something
of interest to the operations research community that will not be dis-
cussed at length in this article.
To analyze the potential impact of a DT, the Monte Carlo was rerun
with a new set of input parameters that reflect a DT that predicts
70% of failures. From available data sources, an estimated PHM sys-
tem that predicts 70-percent of failures seems very reasonable given
the maturity of PHM algorithms for the components under consider-
ation. MLDTs were decreased by 70% to estimate the reduced wait
times due to predicted failure events. Mean times to repair were kept
To analyze the sparing requirements for the forward operating base
based on failure rates, we can leverage a Poisson distribution113,114 to
analyze sparing requirements at a specific confidence requirement. To
do so, the following equation can be used:
Spare Requirement =(T×n)∕𝜆 + q95√(T×n)∕𝜆,(2)
∙Tis mission duration or period between sparing
∙nis the number of operational systems
∙𝜆is the failure rate of the component
∙q95 is a constant corresponding to the confidence level desired, and
for a 95% confidence is 1.645
In this instance, a mission duration of 4 weeks is reasonable since
the logistics delays assumed are equal to 2 weeks. The number of oper-
ational systems is 10 from the case study assumptions.
From the spare parts requirements analysis, Table 4shows the the-
oretical operational availability value outputs from the Monte Carlo
simulation, and Table 5covers the corresponding estimated number of
spares for each major assembly with and without the fielding of a DT
based on the previously mentioned availability figures.
The resulting availability of the remodeled data resulted in a new
system-level operational availability of 0.973, a significant increase
22 BICKFORD ET AL.
TAB L E 4 Monte Carlo simulation results
System functional block
Ao with DT
SATCOM 0.967 0.990
Onboard computer (OBC) 0.993 0.998
Electro-optic sensors (EO/IR) 0.987 0.996
Energy storage module (ESM) 0.997 0.999
Electric drive (ED) 0.971 0.991
TAB L E 5 Sparing requirement comparison—DT deployment
results in a significant reduction in required spare
System functional block
SATCOM 3 1
Onboard computer (OBC) 2 1
Electro-optic sensors (EO/IR) 2 1
Energy storage module (ESM) 1 1
Electric drive (ED) 2 1
from the previous value of 0.917. At 70% failure prediction, rather
than sparing each of these components and maintaining a large inven-
tory, components can be purchased prior to failure and installed when
needed. This represents an approximately 5% improvement in avail-
ability compared to the pre-DT configuration. At this availability rate,
such a small fraction of missions will be missed due to unexpected fail-
ures that many stakeholders maybe willing to accept sparing only when
needed. Given the risk-adverse perspective of the fictitious stakehold-
ers in this case study, fielding one of each spare to the forward base is a
reasonable compromise between cost and risk, and is shown in Table 5.
From these results, the number of required deployed spares prior
to DT fielding is almost two complete USVs. Every major functional
block requires multiple forward deployed spares, significantly driving
up the procurement and sustainment costs. Further, some of these
components may run past initial warranties offered by vendors due to
extended periods sitting on the shelf waiting to be installed. With a DT,
less than 1 of each spare is required. The net impact of this change is sig-
nificant procurement and sustainment cost savings, reduced inventory
and logistics footprint, plus other downstream improvements provided
by the integrated DT. When comparing these sparing requirements to
the post-DT fielded solution, it quickly becomes clear that there is high
utility in scenarios like this for the fielding of DTs.
This article develops a methodology that walks systems engineers
through the development of a PHM-centric DT system in parallel to
the physical asset being developed. By leveraging the various MBSE
requirement decomposition and view development processes, a DT
based on system operational requirements, system functions, and
both inter and intrasystem interfaces can be conveniently architected
and fielded alongside the low rate initial production assets. Addition-
ally, through modeling the case study demonstrates how the appli-
cation of various PHM algorithms can increase operational availabil-
ity, while reducing deployed spare parts required on-hand to maintain
Within the case study, considering the theoretical availability
percentagesinTable4, sustainment teams have an interesting predica-
ment. The overall availability of the components in the USV is quite
high, meaning there is low demand for these components. Due to the
low demand of these components, contracts with suppliers may not be
maintained, inventories within the Naval Supply or Defense Logistics
Agency (DLA) systems may not be maintained, and logistics delay times
when parts are needed may periodically spike. In the authors’ experi-
ence, programs maintaining systems such as these may occasionally
have part lead times lasting several months, resulting in exceptionally
poor operational availability, missed missions, and potential threats
to national security. As a result, the MDTs identified in this case study
are naturally extremely conservative, and the true benefit of the
deployed DT may be significantly higher than that demonstrated in
this case study. In effect, the case study has demonstrated a return on
investment due to the implementation of PHM in agreement with the
resulting takeaway from the PHM article described by L’Her et al.,33
“a system can be designed with PHM hardware instead of expensive
redundancies while maintaining a similar system reliability.” While
this article did not directly dive into the performance analysis decision
aid value of a DT, it is clear that the fielding of the capability will offer
high utility to operational teams aligning operational assets to a set of
missions of different levels of criticality, risk tolerance, or performance
The inherent benefits of the approach proposed in this article is that
it provides a natural and intuitive framework acquisition Systems Engi-
neers can follow to deploy DTs for their systems. It also reduces the
cost of deploying the DT because it leverages the processes already
followed by system developers, ensures DT and PHM components
are integrated into the system by pushing PHM discussions earlier in
the system architecting process, eliminating an additional tasking and
efforts postdelivery. The implementation of the DT also has a signifi-
cant impact on operational availability at levels comparable to improv-
ing built in redundancy. Finally, the DT offers an architecture for the
capturing, storing, and analysis of component performance and reliabil-
ity data—a critical and invaluable element on an infant system as stake-
holders resolve reliability and performance issues.
The one significant drawback that exists with the approach provided
by this article is it relies on systems engineers to develop the archi-
tecture and framework for an integrated PHM system. Not all sys-
tems engineers are PHM subject matter experts, and will therefore
rely on existing PHM analysis and research that is directly applicable
to the components included in their system design. In emerging fields,
notably ones with dramatically new or different architectures from
previous system designs, there may not be publications and research
into PHM applications. In these cases, the development of a PHM
BICKFORD ET AL.23
strategy will increasingly fall upon the hardware and software subject
matter experts, effectively eliminating the efficiency of developing the
DT in parallel to the system.
Another drawback that exists is DT developers need mature stake-
holder requirements, objectives, and possibly assessment of risk. If
these areas are not mature enough, DT development efforts may put
the program down a path of investing engineering time, sensor imple-
mentation, or algorithms that do not answer the specific questions
stakeholders will require. This will result in a suboptimal DT, and pos-
sible rework or redesign of the PHM architecture.
This article has demonstrated the alignment between DT, MBSE, PHM,
and FE modeling but there are a variety of other research areas of
direct applicability to DT development and fielding. The fields of mis-
sion engineering, PLM, and T&E enable new expansion of the inte-
grated model concept as well as open DT data consumers. Addition-
ally, risk-based decision making and aggregate risk provide new ways
to interpret DT data—notably as diverse DT applications such as con-
figuration management, sparing, reliability,and environmental data are
brought together to aid in operational decision making.
6.1 Mission engineering
One notable area that deserves significant exploration is the appli-
cation of DTs to the emerging field of mission engineering. Mission
engineering is effectively the analysis and design of a mission as one
would a system. Mission engineering has been defined by Wertz as “the
definition of mission parameters and refinement of mission parame-
ters and requirements so as to meet the broad, often poorly defined,
objective of a space mission in a timely manner at minimum time and
risk.”.115 Dahmann and Gold define mission engineering as “deliberate
planning, analyzing, organizing, and integrating of current and emerg-
ing operational and system capabilities to achieve desired warfight-
ing mission effects.”.116–119 Considering the objectives and approach
to mission engineering, the insights to actual system health and perfor-
mance promises to be extremely fruitful, notably in systems with high
levels of redundancy that results in scalable performance characteris-
tics such as phased arrays or fiber laser weapon systems.
The use of MBPS or PLM are growing rapidly in the DoD as stake-
holders look for new ways to transform traditional logistics analytics
and processes, and use integrated models and analytics to drive bet-
ter decision making. Many traditional logistics planning processes are
limited to their use of antiquated processes based on transaction data.
tem’s reliability, perform design trades, and model/adjust the sustain-
ment tail. DTs are a transformational data source for the implementa-
tion of PLM capability and make sustainment decisions based on the
materiel condition of deployed hardware—notably with prepositioning
of parts, training, and remote assistance as well as supporting variable
and dynamic sparing. The net effect will be the empowerment of stake-
holders to model the operational environment and adjust the logistics
posture and strategy quickly as the CONOPS evolves.
6.3 DTs for T&E
DTs offer significant value for the T&E of complex systems. Traditional
programs undergo rigorous T&E during acquisition but testing is exe-
cuted in discrete scheduled events. Performance characteristics are
rarely captured and analyzed on operational assets and operators are
not informed of a systems actual capability based on materiel condi-
tion. There is an enormous opportunity to deploy real-time T&E with
modern system DTs that track and monitor performance and deviation
from program requirements. This can enable a next-generation opera-
tional decision-making aid that informs operators of system ability to
support specific missions throughout an evolving conflict.
6.4 Risk-based decision making
Risk-based decision-making is an area of particular interest for future
DT work. As described in Section 2.5, DTs have a wide range of appli-
cations and use cases. Some programs may want the inclusion of mul-
tiple types of DT algorithms to make stronger decision making. Each
DT application may provide its own insights or recommendations to
system operators but unless they are somehow weighted and aggre-
gated, DT outputs will not be intuitive. The concept of risk-based deci-
sion making and risk aggregation is one area that will be valuable for
future DT work, as the topic provides insights on how to makedecisions
based on incomparable or incommensurable data types.
In conclusion, DTs offer an opportunity to revolutionize the operations,
support, and sustainment of deployed systems. Use cases of lever-
aging the DT to indicate performance and health characteristics of a
physical asset have been demonstrated in both industry and academia,
and there are enormous opportunities to develop stronger methodolo-
gies for conceptualizing, designing, and building DTs. This article has
demonstrated that the objectives and fundamental concepts of MBSE
and DTs are in agreement. Both intend to leverage integrated models
to support a system’s lifecycle.
Further this article has demonstrated that the nominal MBSE
approach followed by many development programs, notably for DoD
systems, assist with the architecture and framing of a PHM-centric
DT as well. By following this approach, DT fielding on initial deploy-
ment results in higher operational availability, reduced requirements
24 BICKFORD ET AL.
for fielding spare parts, as well as performance indicating decision
Finally, this article has demonstrated even on program onset, there
is significant value in developing a DT, as the academic community
has well-established off-the-shelf prognostics tools that can be inte-
grated into new designs to maximize system availability. The com-
bination of these three positions makes it clear that sponsors and
stakeholders should be motivated to consider the employment of DTs
within their programs and this methodology is a natural approach for
This research is partially supported by the Naval Postgraduate School.
Any opinions or findings of this work are the responsibility of the
authors, and do not necessarily reflect the views of the sponsors
or collaborators. The case study presented in this publication, while
based on real systems, is intentionally fictional and idealized in
Jason Bickford https://orcid.org/0000- 0002-8327-2102
Douglas L. VanBossuyt https://orcid.org/0000-0001-9910- 371X
Paul Beery https://orcid.org/0000- 0002-8480-1133
1. Zimmerman, P.DoD digital engineering strategy. In 20th Annual NDIA
Systems Engineering Conference, Springfield, VA; 2017.
2. Naval Sea System Command. Reliability-Centered Maintenance Hand-
book. Washington DC: Direction of Commander, Naval Sea Systems
3. Prajapati A, Bechtel J, Ganesan S. Condition based maintenance: a
survey.J Qual Mainten Eng. 2012;18:384-400.
4. Gaguzis MP. Effectiveness of Condition-Based Maintenance in Army Avi-
ation. Fort Leavenworth, KS: Army Command and General Staff Col-
5. Tao F, Cheng J, Qi Q, Zhang M, Zhang H, Sui F. Digital twin-driven
product design, manufacturing and service with big data. Int J Adv
Manuf Tech. 2018;94(9-12):3563-3576.
6. Tao F, Zhang M, Liu Y, Nee AYC. Digital twin driven prognos-
tics and health management for complex equipment. CIRP Ann.
2018;67(1):169-172. Available from: http://www.sciencedirect.com/
7. Zaccaria V, Stenfelt M, Aslanidou I, Kyprianidis KG. Fleet monitoring
and diagnostics framework based on digital twin of aero-engines. In:
ASME TurboExpo 2018: Turbomachinery Technical Conference and Expo-
sition. American Society of Mechanical Engineers Digital Collection;
8. Panetta K. Gartner identifies the top 10 strategic technology
trends for 2015. Gartner Newsroom. 2014; p. 13-15. Available from:
18-gartner-identifies-the- top-10-strategic-technology-trends- for-
9. Savitz E. Gartner: top 10 strategic technology trends for 2013:
Forbes. Gartner Newsroom. 2012; p. 1-15. Available from:
top-10-strategic-technology- trends-for- 2013/.
10. Garfinkel J. Top 10 strategic tech trends for 2019. Gartner Newsroom.
2019; p. 1-5.
11. Glaessgen E, Stargel D. The digital twin paradigm for future NASA
and US Air Force vehicles. In: 53rd AIAA/ASME/ASCE/AHS/ASC
Structures, Structural Dynamics and Materials Conference and 20th
AIAA/ASME/AHS Adaptive Structures Conference; 2012. p. 1818.
12. Wang W. Delay time modelling. In: Pham Hoang, ed. Complex System
Maintenance Handbook. Springer Series in Reliability Engineering. Lon-
don: Springer; 2008:345-370.
13. Ahmad R, Kamaruddin S. An overview of time-based and condition-
based maintenance in industrial application. Comput Ind Eng.
14. Ljungberg Õ. Measurement of overall equipment effectiveness as
a basis for TPM activities. Int J Oper Prod Manage. 1998;18(5):
15. Wang W. An overview of the recent advances in delay-time-based
maintenance modelling. Reliab Eng Syst Safe. 2012;106:165-178.
16. Yam R, Tse P, Li L, Tu P. Intelligent predictive decision support
system for condition-based maintenance. Int J Adv Manuf Tech.
17. Baker R. Risk aversion in maintenance: overmaintenance and the
principal-agent problem. IMA J Manag Math. 2006;17(2):99-113.
18. Wireman T. World Class Maintenance Management. New York: Indus-
tria Press; 1990.
19. Woltjer R, Hollnagel E. The Alaska Airlines flight 261 accident: a sys-
temic analysis of functional resonance. In: 2007 International Sympo-
sium on Aviation Psychology; 2007. p. 763.
20. Loss of control and impact with Pacific ocean, Alaska Airlines flight
261, McDonnell Douglas MD-83, N963AS, about 2.7 miles north
of Anacapa Island, California, January 31, 2000; 2003. Available
21. Cox P, Jordan C, Mangum K, Mitchell J, O’Neill K, Seraile K.
Unmanned surface combatant considerations for concept explo-
ration. Chemistry & .... 2011; Available from: http://onlinelibrary.
22. Kinsey B. Agility the navy way.All Hands Magazine. 2019 April.
23. Brito M, Griffiths G. A Bayesian approach for predicting risk of
autonomous underwater vehicle loss during their missions. Reliab Eng
Syst Safe. 2016;146:55-67.
24. Kritzinger W, Karner M, Traar G, Henjes J, Sihn W. Digital Twin
in manufacturing: A categorical literature review and classification.
IFAC-PapersOnLine. 2018;51(11):1016-1022. Available from: https://
25. Tao F and Cheng J, Qinglin Q, Meng Z, He Z, Fangyuan S. Digital twin-
driven product design, manufacturing and service with big data. Int J
Adv Manuf Tech. 2018;94(9):3563-3576. Available from: https://doi.
26. West TD, Blackburn M. Is digital thread/digital twin affordable? A
systemic assessment of the cost of DOD’s latest Manhattan project.
Procedia Comput Sci. 2017;114:47-56.
27. Barricelli BR, Casiraghi E, Fogli D. A survey on digital twin: defi-
nitions, characteristics, applications, and design implications. IEEE
28. Moubray J. The Case Against Streamlined RCM. UK: Aladon; 2000.
29. Djurdjanovic D, Lee J, Ni J. Watchdog agent: an infotronics-based
prognostics approach for product performance degradation assess-
ment and prediction. Adv Eng Inform. 2003;17(3-4):109-125.
30. Douangaphaivong Thaveephone. Littoral Combat Ship (LCS) Man-
power Requirements Analysis. Monterey, California: Naval Postgradu-
ate School; 2004.
31. O’Rourke R. Navy Littoral Combat Ship (LCS)/Frigate Program: Back-
ground and Issues for Congress. Washington, DC: Library of Congress;
32. Richter MP. Analysis of Operational Manning Requirements and Deploy-
ment Procedures for Unmanned Surface Vehicles Aboard U.S. Navy Ships.
Monterey, CA: NavalPostgraduate School; 2006-09.
BICKFORD ET AL.25
33. L’Her G, Van Bossuyt DL, O’Halloran BM. Prognostic systems rep-
resentation in a function-based Bayesian model during engineering
design. Int J Prognost Health Manage. 2017;8(2):23.
34. Buede DM, Miller WD. The Engineering Design of Systems: Models and
Methods. Hoboken, NJ: John Wiley & Sons; 2016.
35. INCOSE. International Council on Systems Engineering Website;
2020. Available from: https://www.incose.org/.
36. Friedenthal S, Moore A, Steiner R. A Practical Guide to SysML: The Sys-
tems Modeling Language. 3rd ed. Amsterdam: Elsevier, MK, Morgan
Kaufmann is an imprint of Elsevier; 2015.
37. USD(A&S). DoDD 5000.01, May 12, 2003, Incorporating Change 2,
August 31, 2018; 2003.
38. Estefan JA,et al. Survey of model-based systems engineering (MBSE)
methodologies. Incose MBSE Focus Group. 2007;25(8):1-12.
39. Dickerson CE, Mavris D. A brief history of models and model based
systems engineering and the case for relational orientation. IEEE Syst
40. Crisp HE. Systems Engineering Vision 2020. Seattle, WA:Vol. INCOSE-
41. Hart LE. Introduction to Model-Based System Engineering (MBSE)
and SysML. San Diego, CA: INCOSE; 2015. Available from:
42. Huldt T, Stenius I. State-of-practice survey of model-based systems
engineering. Syst Eng. 2019;22(2):134-145.
43. Russell M. Using MBSE to enhance system design decision making.
Procedia Comput Sci. 2012;8:188-193.
44. Jinzhi L. State-of-the-art of MBSE tool-chains. KTH Royal Institute of
Technology, School of Industrial Engineering and Management; 2019.
45. Huynh TV, Osmundson JS. A systems engineering methodology for
analyzing systems of systems using the systems modeling language
(SysML). Department of Systems Engineering, Naval Postgraduate School,
46. McKean D, Moreland Jr JD, Doskey S. Use of model-based architec-
ture attributes to construct a component-level trade space. Syst Eng.
47. Duncan KR, Etienne-Cummings R. A model-based systems engi-
neering approach to trade space exploration of implanted wireless
biotelemetry communication systems. IEEE Syst J. 2018;13(2):1669-
48. Kapos GD, Dalakas V, Nikolaidou M, Anagnostopoulos D. An inte-
grated framework for automated simulation of SysML models using
DEVS. Simulation. 2014;90(6):717-744.
49. Beery P, Paulo E. Application of model-based systems engineering
concepts to support mission engineering. Systems. 2019;7(3):44.
50. Acheson P, Dagli C, Kilicay-Ergin N. Model based systems engineer-
ing for system of systems using agent-based modeling. Procedia Com-
put Sci. 2013;16:11-19.
51. Hrennikoff A. Solution of problems of elasticity by the framework
method. J Appl Mech. 1941;8:169-175.
52. Haldar A, Mahadevan S. Reliability Assessment Using Stochastic Finite
Element Analysis. New York: John Wiley& Sons; 2000.
53. Barnaby HJ, Esqueda IS. Physics-based reliability model for large-
scale CMOS circuit design. Google Patents; 2015. US Patent
54. Nejadpak A, Mohammed OA. Physics-based modeling of power con-
verters from finite element electromagnetic field computations. IEEE
55. Allaire DL. A physics-based emissions model for aircraft gas turbine
combustors. Massachusetts Institute of Technology; 2006.
56. Doss-Hammel S, Tsintikidis D, Merritt D, Fontana J. Atmospheric
characterization for high-energy laser beam propagation in the mar-
itime environment. In: Valley Michael T, ed. Target-In-The-Loop: Atmo-
spheric Tracking, Imaging, and Compensation. vol. 5552. Bellingham,
WA: International Society for Optics and Photonics; 2004. p. 208-
57. Grady DE, Winfree NA. Impact fragmentation of high-velocity com-
pact projectiles on thin plates: a physical and statistical characteriza-
tion of fragment debris. Int J Impact Eng. 2001;26(1-10):249-262.
58. RemennikovAM, et al. A review of methods for predicting bomb blast
effects on buildings. J Battlef Technol. 2003;6(3):5.
59. Elattar HM, Elminir HK, Riad A. Prognostics: a literaturereview. Com-
plex Intell Syst. 2016;2(2):125-154.
60. Zhang H, Kang R, Pecht M. A hybrid prognostics and health manage-
ment approach for condition-based maintenance. In: 2009 IEEE Inter-
national Conference on Industrial Engineering and Engineering Manage-
ment. IEEE; 2009. p. 1165-1169.
61. Kalgren PW, Byington CS, Roemer MJ, Watson MJ. Defining PHM, a
lexical evolution of maintenance and logistics. In: 2006 IEEE Autotest-
con. IEEE; 2006. p. 353-358.
62. Haddad G, Sandborn P, Pecht M. Using real options to manage
condition-based maintenance enabled by PHM. In: 2011 IEEE Confer-
ence on Prognostics and Health Management. IEEE; 2011. p. 1-7.
63. Van Bossuyt DL, O’Halloran BM, Arlitt RM. A method of identifying
and analyzing irrational system behavior in a system of systems. Syst
64. He W, Williard N, Osterman M, Pecht M. Prognostics of lithium-ion
batteries based on Dempster–Shafer theory and the Bayesian Monte
Carlo method. JPowerSources. 2011;196(23):10314-10321.
65. LeboldM, McClintic K, Campbell R, Byington C, Maynard K. Review of
vibration analysis methods for gearbox diagnostics and prognostics.
In: Proceedings of the 54th Meeting of the Society for Machinery Failure
Prevention Technology. vol. 634; 2000. p. 16.
66. Qiu H, LeeJ, Lin J, Yu G. Robust performance degradation assessment
methods for enhanced rolling element bearing prognostics. Adv Eng
67. Gregg SW, Steele JP, Van Bossuyt DL. Feature selection for moni-
toring erosive cavitation on a hydroturbine. Int J Progn Health Manag.
68. Gregg SW, Steele JP, Van Bossuyt DL. A Method for Automated Cav-
itation Detection with Adaptive Thresholds. International Journal of
Prognostics and Health Management. 2018;9.
69. Google. Google trends, digital twin. Google; 2020. Available from:
70. Schleich B, Anwer N, Mathieu L, Wartzack S. Shaping the digital twin
for design and production engineering. CIRP Ann. 2017;66(1):141-
71. Tao F, Zhang H, Liu A, Nee AYC. Digital Twin in Industry: State-of-
the-Art. IEEE Transactions on Industrial Informatics. 2019;15(4):2405-
72. Eckstein M. Navy simulating efficient shipyard layouts as part of
20-year modernization, optimization effort. USNI News. 2019 April;
Available from: https://news.usni.org/2019/04/05/navy-simulating-
efficient-shipyard-layouts-as-part-of- 20-year- modernization-
73. Dakowicz M, Gold C, Kidner D. Building reconstruction using LIDAR
data. In Proceedings 4th ISPRS Workshop on Dynamic and Multi-
dimensional GIS; 2005.
74. Li C, MahaDeVan S, Ling Y, Choze S, Wang L. Dynamic Bayesian
network for aircraft wing health monitoring digital twin. AIAA J.
75. Stark J. Product Lifecycle Management. In: Product Lifecycle Man-
agement (Volume 1). Switzerland: Springer International Publishing;
2015. p. 1-29. Available from: https://doi.org/10.1007/978-3-319-
76. Li J, Tao F, Ying C, Liangjin Z. Big data in product lifecycle man-
agement. Int J Adv Manuf Tech. 2015;81(1):667-684. Available from:
26 BICKFORD ET AL.
77. Matsokis A, Kiritsis D. An ontology-based approach for prod-
uct lifecycle management. Comput Ind. 2010;61(8):787-797.
Available from: http://www.sciencedirect.com/science/article/
78. SrinivasanV. An integration framework for product lifecycle manage-
ment. Comput Aided Des. 2011;43(5):464-478. Available from: http:
79. Venkatasubramanian V. Journals & books create account sign in
prognostic and diagnostic monitoring of complex systems for product
lifecycle management: challenges and opportunities. Comput Chem
80. Qi Q, Tao F, Zuo Y, Zhao D. Digital twin service towards smart man-
ufacturing. Procedia CIRP. 2018;72:237-242. Available from: https:
81. Peterman RM, Anderson JL. Decision analysis: a method for taking
uncertainties into account in risk-based decision making. Hum Ecol
82. Bohnenblust H, Slovic P. Integrating technical analysis and pub-
lic values in risk-based decision making. Reliab Eng Syst Safe.
83. Dempere J, Papakonstantinou N, O’Halloran B, Van Bossuyt DL. Risk
modeling of variable probability external initiating events. In: 2017
Annual Reliability and Maintainability Symposium (RAMS). IEEE; 2017.
84. Kraft EM. The air force digital thread/digital twin-life cycle integra-
tion and use of computational and experimental knowledge. In: 54th
AIAA Aerospace Sciences Meeting; 2016. p. 0897.
85. Nassar AR, Reutzel EW. A proposed digital thread for additive man-
ufacturing. In: 24th Annual Solid Freeform Fabrication Symposium (SFF),
Austin, TX, Aug; 2013. p. 12-14.
86. Liao Y, Li Y, Liu T, Li Y, Wang L, Jiang Qq. Unmanned wave glider
technology: state of the art and perspective. JHarbinEngUniv.
87. Eriksen CC, Osse TJ, Light RD, et al. Seaglider: A long-range
autonomous underwater vehicle for oceanographic research. IEEE J
Ocean Eng. 2001;26(4):424-436.
88. Nicholson J, Healey A. The present state of autonomous underwa-
ter vehicle (AUV) applications and technologies. Mar Technol Soc J.
89. Manley JE. Unmanned surface vehicles, 15 years of development. In:
OCEANS 2008; 2008. p. 1-4.
90. Everett HR. Unmanned surface vehicles. In: Arkin Ronald C, ed.
Unmanned Systems of World Wars I and II.Cambridge,MA:TheMIT
Press; 2015; p. 1-14.
91. Courtland R. DARPA’s self-driving submarine hunter steers like
a human. IEEE Spectr. 2016;7:1–3. https://spectrum.ieee.org/
92. Casola KJ, Beery PT, Paulo EP. System architecting and analysis
of medium displacement unmanned surface vehicle “Sea Hunter”
as a surface warfare component of distributed lethality. Nav Eng J.
93. CoxP, Jordan C, Mangum K, Mitchell J, O’Neill K, Seraile K. Unmanned
Surface Combatant Considerations for Concept Exploration. Monterey,
CA: Naval Postgraduate School; 2011.
94. Corfield S, Young J. Unmanned surface vehicles-game changing tech-
nology for naval operations. IEEE Control Eng Ser. 2006;69:311.
95. Yan Rj, Pang S, Sun Hb, Pang Yj. Development and missions of
unmanned surface vehicle. J Mar Sci Appl. 2010;9(4):451-457.
96. Yaakob O, Mohamed Z, Hanafiah M, Suprayogi D, Abdul Ghani M,
Adnan F, et al. Development of unmanned surface vehicle (USV) for
sea patrol and environmental monitoring. In: Proceedings of the Inter-
national Conference on Marine Technology, Kuala Terengganu, Malaysia;
2012. p. 20-22.
97. Papakonstantinou N, Bashir AZ, O’Halloran B, Bossuyt DLV. Early
assessment of drone fleet defence in depth capabilities for mission
success. In: 2019 Annual Reliability and Maintainability Symposium
(RAMS); 2019. p. 1-7.
98. Carlson DF, Fürsterling A, Vesterled L, Skovby M, Pedersen SS, Mel-
vad C, et al. An affordable and portable autonomous surface vehi-
cle with obstacle avoidance for coastal ocean monitoring. Hardwarex.
99. Eco Marine Power. Eco marine power: Technologies for sustainable
shipping; 2020. Available from: https://www.ecomarinepower.com/
100. MARTAC. MARTAC systems; 2019. Available from: https:
101. 5G International. 5G International Inc; 2016. Available from: https:
102. Merino Laso P, Brosset D, Giraud MA. Secured architecture
for unmanned surface vehicle fleets management and control.
Proceedings—IEEE 16th International Conference on Dependable, Auto-
nomic and Secure Computing, IEEE 16th International Conference on Per-
vasive Intelligence and Computing, IEEE 4th International Conference on
Big Data Intelligence and Computing. 2018; p. 373-375.
103. Ginart AE, Brown D, Kalgren PW, Roemer MJ. On-line ringing char-
acterization as a PHM technique for power drives and electrical
machinery. In: 2007 IEEE Autotestcon. IEEE; 2007. p. 654-659.
104. Chan TH, Yu L, TamHY, Ni YQ, Liu S, Chung W, et al. Fiber Bragg grat-
ing sensors for structural health monitoring of Tsing Ma bridge: back-
ground and experimental observation. Eng Struct. 2006;28(5):648-
105. Marquardt B. Digital twin brown bag: structural health monitoring.
NAVSEA NEWS. 2019 Feb;.
106. Drazen DA,Mondoro AM, L GB. Use of digital twins to enhance oper-
ational awareness and guidance. In: 18th Conference on Computer and
IT Applications in the Maritime Industries. COMPIT; 2019. p. 344-351.
107. Takeda S, Aoki Y, Ishikawa T, Takeda N, Kikukawa H. Structural health
monitoring of composite wing structure during durability test. Comp
108. MONDOROA, GRISSO B. On the integration of SHM and digital twin
for the fatigue assessment of naval surface ships. Struct Health Mon-
itoring. 2019. http://www.dpi-proceedings.com/index.php/shm2019/
109. Bowles JB. The new SAE FMECA standard. In: Annual Reliability and
Maintainability Symposium. 1998 Proceedings. International Sympo-
sium on Product Quality and Integrity. IEEE; 1998. p. 48-53.
110. Pecht M. Prognostics and health management of electronics. In:
PechtM,KangM,eds.Encyclopedia of Structural Health Monitoring.
Hoboken, NJ: Wiley Online Library; 2009.
111. Ward M, Lam J, Stewart B. Quantifying expected gains from imple-
menting a prognostics algorithm on systems with long logistics delay
times. In: 2015 IEEE Conference on Prognostics and Health Management
(PHM). IEEE; 2015. p. 1-5.
112. Smith JG, Manary JM, Price AT, Weinstein LW. A Practical Guide for
Military Systems, Sub-Systems and Equipment. Operational Availabil-
ity Handbook. 2003. https://www.secnav.navy.mil/doni/Directives/
113. Nahman JM, Tanaskovic MR. Probability models for optimal spar-
ing of distribution network transformers. IEEE Trans Power Deliv.
114. Bluvband Z, Shahaf S. Sparing criteria. Clear management approach.
In: Annual Reliability and Maintainability Symposium, 1984. Proceedings.
IEEE; 1984. p. 446-451.
115. Wertz JR, Everett DF, Puschell JJ. Space Mission Engineering: The New
SMAD. Hawthorne, CA: Microcosm Press; 2011.
BICKFORD ET AL.27
116. GoldR. Mission engineering. In: 19th Annual NDIA Systems Engineering
117. Dahmann J, Markina-Khusid A, Kamenetsky J, Antul L, Jacobs R.
Systems of systems engineering technical approaches as applied
to mission engineering. In: SoSECIE Webinar Series Presentation;
118. Dahmann J. Keynote Address: Mission engineering: system of sys-
tems engineering in context. In: IEEE System of Systems Engineering
119. Van Bossuyt DL, Beery P, O’Halloran BM, Hernandez A, Paulo E.
The Naval Postgraduate School’s Department of Systems Engineer-
ing approach to mission engineering education through Capstone
Projects. Systems. 2019;7(3):38.
JASON BICKFORD is the research manager at the Naval Surface
Warfare Center (NSWC) in Port Hueneme, and is a current doc-
toral student in the Systems Engineering Department at the Naval
Postgraduate School. Jason’s professional experience includes sus-
tainment engineering, test and evaluation, and acquisition sys-
tems engineering for a variety of naval systems including combat
systems and directed energy weapons. Jason’s research areas of
interest include digital twins, prognostics and performance algo-
rithms, and risk-based assessments, with an emphasis on tools
that improve warfighter and shore support decision making. Jason
holds a BS in electrical engineering from UC Davis, and an MS in
systems engineering from the Naval Postgraduate School.
DOUGLAS L. VAN BOSSUYT is an assistant professor in the Sys-
tems Engineering Department at the Naval Postgraduate School.
His research focuses on understanding and mitigating deleteri-
ous emergent system behaviors from a risk analysis and failure
modeling perspective through the development of system design
methodologies targeted at the system architecture phase of the
system design process. He holds an honors bachelor of science in
mechanical engineering, an honors bachelor of arts in international
studies, a master’s of science in mechanical engineering, and a PhD
in mechanical engineering all from Oregon State University.
PAUL BEERY is an assistant professor in the Systems Engineer-
ing Department at the Naval Postgraduate School. His research
focuses on the trade-off analysis and characterization of system
trade spaces early in the design lifecycle through linkage of system
architectures and operational simulation models. He holds a bach-
elor’s degree in statistics from Rutgers University,a master’s in sys-
tems engineering analysis from the Naval Postgraduate School, and
a PhD in systems engineering from the Naval Postgraduate School.
ANTHONY POLLMAN is an assistant professor in the Systems Engi-
neering Department at the Naval Postgraduate School in Mon-
terey, California. He holds a BS and MS in nuclear engineering from
Purdue University, a PhD in mechanical engineering from the Uni-
versity of Maryland-College Park, and an executive MBA from the
NPS. He teaches courses in system dynamics, combat systems, sen-
sors, and mathematical modeling. His research interests include
process modeling and simulation, operational energy, autonomous
systems, and radiation detectors. He is retired Marine and veteran
of both Iraq and Afghanistan.
How to cite this article: Bickford J, Van Bossuyt DL, Beery P,
Pollman A. Operationalizing digital twins through model-based
systems engineering methods. Systems Engineering. 2020;1–27.