A Functional Failure Analysis Method of
Identifying and Mitigating Spurious
System Emissions From a System of
Interest in a System of Systems
Douglas L. Van Bossuyt
Department of Systems Engineering,
Naval Postgraduate School,
Monterey, CA 93943
Ryan M. Arlitt
Department of Mechanical Engineering,
Technical University of Denmark,
DK-2800 Kgs. Lyngby, Denmark
Increasingly tight coupling and heavy connectedness in system of
systems (SoS) present new problems for systems’designers and
engineers. While the failure of one system within a loosely
coupled SoS may produce little collateral damage beyond a loss
in SoS capability, a highly interconnected SoS can experience sig-
niﬁcant damage when one member system fails in an unanticipated
way. It is therefore important to develop systems that are “good
neighbors”with the other systems in an SoS by failing in ways
that do not further degrade an SoS’s ability to complete its
mission. This paper presents a method to (1) analyze a system of
interest (SoI) for potentially harmful spurious system emissions
(failure ﬂows that exit the SoI’s system boundary and may cause
failure initiating events in other systems within the SoS) and (2)
choose mitigation strategies that provide the best return on invest-
ment for the SoS. The method is intended for use during the system
architecture phase of the system design process when functional
architectures are being developed, and analysis of alternatives
and trade-off studies are being conducted.
Keywords: model-based systems engineering, system of systems,
failure analysis, functional model
As the ﬁeld of system of systems (SoS) engineering has devel-
oped over the last several years, an emerging area of interest is
how well member systems behave with each other. Many system
engineers desire systems of interest (SoIs) that are “good neighbors”
to other systems within the SoS in both nominal operation and in
degraded or failed system states. While failure mode effects and
criticality analysis (FMECA) and probabilistic risk assessment
(PRA) techniques among others are currently being used to help
design SoIs in later phases of the system design process, there is
a need for an approach that analyzes the effects that an SoI operating
in a degraded or failed state has on its SoS neighbors during the
early system architecture phase of SoI development. Understanding
the effects that an SoI may have on its neighbor systems very early
in the system design process allows for large changes to be made at
relatively low cost and with minimal impact to a system develop-
1.1 Speciﬁc Contributions. In this paper, we present a
method intended for the early system architecture phase of the
systems engineering process where functional architectures are
under development. The method helps to identify and mitigate
potential failure ﬂows exiting an SoI’s system boundary—spurious
system emissions (SSEs)—that otherwise may not have been iden-
tiﬁed or may have been discounted. This method helps to develop
strategies to mitigate SSEs from the very earliest functional model-
ing efforts of a new SoI. System engineers can use the method to
identify potential SSE sources from an SoI into the SoS and
propose mitigation strategies to address the identiﬁed SSEs.
While other methods such as PRA and FMECA can be used to
investigate potential SSEs, those methods are generally employed
either later in the system development process after system architec-
tures have been selected and frozen or do not directly integrate into
existing functional analysis methods.
2 Background and Related Work
The work presented in this article is set within the context of the
systems engineering process that takes a system from initial concept
to production, customer delivery and use, maintenance and upgrade,
and disposal [1,2]. Of particular interest to this research is the early
phase of systems engineering that is encompassed by the system
architecting process where customer need statements, design refer-
ence missions, system requirements, functional system models and
architectures, trade-off studies, and a variety of other activities
occur [2,3]. Mission engineering [4–7] and SoS engineering also
play a signiﬁcant role in many SoI system architecting efforts [8,9].
Functional modeling helps to develop an understanding of how
systems work at the functional level  during system architecture
development. There are a variety of different taxonomies available
to produce functional models . We prefer the functional basis
for engineering design (FBED) [12,13] and use it throughout this
paper. A functional modeling taxonomy generally is composed of
functions and ﬂows where functions transform incoming ﬂows to
different outgoing ﬂows. Functions and ﬂows are connected to
their physical component solutions through databases and reposito-
ries [14–16]. One function may have many potential component
solutions, such as converting electrical energy function to rotational
energy function may be satisﬁed by several types of electrical
motors and ﬂows can similarly have multiple physical manifesta-
Throughout the system design process, a variety of failure anal-
ysis methods are often employed such as FMECA early in a system
design process  and PRA which often is done after major system
architecture decisions have been made . PRA uses the concept
of an initiating event—an event that is the starting point for a failure
that propagates through a system . Many systems engineered
using PRA have the ability to react to incipient failures and either
transition to a safe shutdown state or continue operating either nom-
inally or in a degraded state while repairs are made [21,22] although
unanticipated failures can still occur which may lead to system
Reliability block diagrams (RBDs) can be used to analyze the
reliability of a system either from the component or functional
level . The function failure identiﬁcation and propagation
(FFIP) family of methods extends the concept of RBDs to under-
stand how failures propagate through a system, how to detect incip-
ient failures, and what may be done to mitigate such failure events
[24,25]. Some work has been done that includes the authors of this
paper to understand how to redesign an SoI at the functional level to
withstand SSEs that enter the SoI as unanticipated failure initiating
A version of this paper appeared at the 2019 ASME IDETC/CIE (Van Bossuyt,
D. L., and Arlitt, R., 2019, “Toward a Functional Failure Analysis Method of Identifying
and Mitigating Spurious System Emissions in a System of Systems,”International
Design Theory and Methodology Conference, IDETC/CIE, ASME, Anaheim, CA).
This work is in part a work of the U.S. Government. ASME disclaims all interest in
the U.S. Governments contributions.
Manuscript received August 29, 2019; ﬁnal manuscript received April 8, 2020;
published online May 14, 2020. Assoc. Editor: Yan Wang.
Journal of Computing and Information Science in Engineering OCTOBER 2020, Vol. 20 / 054501-1
Copyright © 2020 by ASME
events . Our previous work is in contrast with the method
advanced in this paper that speciﬁcally focuses on not allowing
SSEs from an SoI to occur that may negatively affect the rest of
In summary, within the scope of early system architecture where
functional models of a SoI are under development and major archi-
tectural design decisions have not been ﬁnalized, no existing
method that we are aware of is available to system engineers to sys-
tematically identify potential SSEs and propose mitigation strate-
gies from a functional perspective.
In this section, we present a novel method to identify potential
SSEs originating in an SoI that could negatively impact other
members of an SoS, quantify potential SSE probabilities, identify
potential mitigation strategies to prevent SSEs from causing harm
to other systems in the SoS, and conduct trade-off studies to deter-
mine the best course of action moving forward with the SoI system
design. The method is intended to be used during the system archi-
tecture phase of system design where large changes to an SoI design
can be made with relatively little impact to cost or schedule.
Figure 1depicts the seven steps of the methodology, the reusable
dependencies, and the preparatory step, and their relations to one
3.1 Case Study. In order to demonstrate and illustrate the
method throughout the methodology section of this paper, we
now introduce an illustrative case study of an autonomous vehicle
SoI that is being designed to enter service with an autonomous
logistics system (the SoS). The SoI is currently in the system archi-
tecture phase of the system design process, and speciﬁcally, the
functional architecture is being reﬁned. The SoS operates in a
mountainous desert environment carrying material from a logistics
depot to a forward operating base. This frees up military personnel
and contractors from routine and potentially dangerous resupply
missions  to concentrate on other high value activities. There
are other constituent members of the SoS including the logistics
depot and co-located ground control station, command and
control relay stations, and other autonomous systems such as auton-
omous ground vehicles. Figure 2shows a high-level operational
view of the SoS.
The system architecture process for the SoI has already down-
selected to the production of an unmanned aerial vehicle (UAV)
for the speciﬁc payloads and mission constraints identiﬁed during
the development of the customer needs statement, the design refer-
ence mission, and the system requirements (shown in Table 1).
While the SoI presented in the case study of this paper is ideal-
ized, it takes inspiration from real systems [6,28]. The case study
is used to illustrate each step of the method presented below and
has been intentionally simpliﬁed to better highlight the speciﬁc con-
tributions of the method.
3.2 Reusable Dependencies. Prior to beginning the prepara-
tory step of the method, reusable dependencies (e.g., function to
component relational database, cost and performance data, func-
tional failure modes, etc.) are identiﬁed and developed as necessary
and are speciﬁc to the SoI. Once created, these resources can
support multiple SoI analyses when the SoIs are deemed similar
enough by practitioners. Reusable dependency databases include
historical function to component relationships [15,16], function to
failure data and relationships [25,29,30], cost and performance
data of components (seeded automatically where practical ),
and abstracted behavior failure behavior models [25,29].
3.3 Preparatory Step. Several preparations must be made
within two categories: (1) prepare a FFIP model of the system
and (2) prepare information for the trade-off study conducted in
steps 6 and 7 prior to entering the main method.
To develop a FFIP model, a functional model of the SoI must ﬁrst
be developed. In order to do this, a functional taxonomy must be
chosen to match the taxonomy used in the reusable dependency
Fig. 1 High level ﬂowchart of the relationships between the seven steps of the method, the
preparatory step, and the reusable dependencies
054501-2 / Vol. 20, OCTOBER 2020 Transactions of the ASME
databases (e.g., Ref. ). In many cases, a nominal system design
process will already have developed a functional model as part of
modeling the system . Figure 3shows a high-level FFIP model
for the case study SoI UAV developed using FBED.
Next, system requirements information must be collected includ-
ing performance metrics and system constraints. Cost and failure
probability constraints in particular are required to use this
method. Other requirements and constraints will vary depending
upon the speciﬁc SoI. Generally, these data will already have
been developed as part of the system design process. Table 1
shows the requirements for the UAV SoI. This information will
help to set goals for the trade-off studies conducted in step 6 of
Finally, an analysis of the SoI’s place in a larger SoS environ-
ment must be undertaken which will be used in steps 6 and 7 of
the method. Questions to ask are (1) what other systems are
present, (2) how important is it that each system continues to func-
tion, (3) what is the cost of having a system fail, and (4) what exter-
nal event(s) may cause a system to fail. The resulting information
then is recorded in terms of consequences for other systems
within the SoS failing. Consequence data are shown in Table 2
for the case study. The consequence is determined by the cost dis-
tribution function, C
,deﬁned as the probability density of the cost
of a system damaging other systems within a SoS from emitted
3.4 Step 1: Analysis of Each Function and What It
Conceivably Could Emit. Previous to step 1, reusable dependen-
cies including a function to component relational database contain-
ing failure modes information were developed. Now the failure
modes must be expanded to go beyond failures that have been pre-
viously observed. To identify a high proportion of all possible
emitted failure ﬂows beyond what has previously been identiﬁed
with existing methods, we advocate working backwards from the
ﬂow taxonomy of FBED to disprove the hypothesis that each of
the ﬂow types can be emitted as a failure ﬂow by the function in
question. For instance, the energy-thermal ﬂow may be generated
by a function such as control-stop-inhibit where the component
solution is a metal barrier if the function receives a failure ﬂow
input such as energy-vibration where the ﬂow’s physical solution
is a high frequency, high amplitude vibration caused by an unantic-
ipated failure somewhere else in the SoI. Table 3presents an
example of a function where potential received failure ﬂows are
connected to emitted failure ﬂows and associated potential compo-
nent solutions to the function. The crossed-out failure ﬂow exports
represent those exports that have been found to be impossible to
create regardless of the failure ﬂow import to the function.
The newly identiﬁed failure ﬂow exports shown in Table 3from
the function are then appended to the function’s failure database
Fig. 2 High-level operational concept view of the SoS. The existing SoS member systems include
unmanned ground vehicles, a logistics depot and ground control station, command and control
relay stations, and the forward operating base. The new SoI UAVs are also represented on the
Table 1 SoI requirements for a UAV used to carry cargo
1 Carry 10 kg 5 km
2 Complete round-trip transit with 99% success rate
3 Communicate with ground control station at 1.5Mbit/s TX/RX
Journal of Computing and Information Science in Engineering OCTOBER 2020, Vol. 20 / 054501-3
3.5 Step 2: Evaluate All Potential Flow Paths Through the
System of Interest. Next, a partial re-evaluation of the FFIP
model of the SoI is conducted. All potential failure propagation
paths that lead to a failure ﬂow exiting the system boundary are
identiﬁed as per the FFIP method; however, we do not assign prob-
abilities to individual ﬂow paths, functional failure events, or initi-
ating events at this point in time. The proposed method intentionally
does not assign probabilities at this step to avoid the pitfalls of trun-
cation of failure ﬂow paths that often occurs during FFIP-style anal-
yses. A small sample of failure ﬂow paths that exit the system
boundary from the SoI is presented in Table 4.
3.6 Step 3: Determine Probabilities of Spurious System
Emissions Exiting the Systemof Interest. After all failure ﬂow
paths have been identiﬁed, the next step is to quantify the probabil-
ity of each failure ﬂow emitted as a SSE from the SoI. This step
diverges from established FFIP practices. Rather than stopping at
producing cut-sets (the paths that a failure follows from initiation
to exiting the system as a SSE) that are analyzed individually, the
probability of each SSE is developed from aggregating cut-sets
into groups based on the speciﬁc SSEs that they produce.
Table 5shows a representative subset of cut-sets for the UAV SoI
that only includes the SSEs identiﬁed through this method. Each
SSE type and probability of occurrence, PO
, is listed where the
probability is an aggregation of all SSE failure ﬂow path cut-sets
that result in that particular failure ﬂow emission type.
3.7 Step 4: Analyze Results. Next, the results of the prior
steps are analyzed to understand the potential consequences to the
other systems within the SoS. Table 2provides a means for evalu-
ating how SSEs from the SoI may impact other systems in the SoS.
A mapping of SSEs produced by an SoI to initiating events of other
systems in the SoS with a probability of negative consequence (P
to the other systems can be produced. We propose that P
combined with C
developed in Table 2into an emission priority
(EP) which we suggest as a metric to make comparisons between
SSEs similar to how the risk priority number that FMECA produces
is used and the general understanding of how engineering risk is cal-
culated (e.g., risk =probability × consequence). The calculation to
produce EP for a given ﬂow emission eis provided in Eq. (1).
Table 6provides a representative subset of EPs for the UAV SoI
that are rank ordered based on the EP which indicates which
SSEs have the biggest negative impact on the SoS.
Fig. 3 An FFIP model of the SoI UAV developed using the FBED taxonomy. The dotted dashed line represents the
system boundary. The dashed line represents a SSE.
054501-4 / Vol. 20, OCTOBER 2020 Transactions of the ASME
3.8 Step 5: Identify Spurious System Emission Mitigation
Strategies. The next step is to develop approaches to mitigate
SSEs before they leave the SoI. In this method, we advocate for
addressing SSEs before they leave the system boundary in order
for the SoI to not potentially initiate failures in neighboring systems.
We recommend information on mitigation strategies including
both the functional representation and the physical solution to each
mitigation strategy. Additionally, information on (1) the likelihood
of completely mitigating the SSE, (2) other failure ﬂows that may
be created by the mitigation strategy, and (3) other relevant failure
data should be captured at this stage. Table 7shows an example of
several mitigation strategies for the SoI where P
is the probability
of a mitigated SSE still occurring in spite of the mitigation strategy.
New failure ﬂow leaving system (NFFLS) represents if a new failure
ﬂow produced by a failure within the implementation of the mitiga-
tion strategy may leave the SoI system boundary as a SSE. P
the probability of an NFFLS leaving the SoI as a SSE. Note that
does not provide insight into if the new SSE can damage other
systems within the SoS. M
is the mitigation implementation cost.
In order to understand what mitigation strategies are preferred,
we proposed developing a mitigation probability (MP) which is
similar in formulation to EP. To calculate a population of MPs
where one mitigation strategy may be useful in mitigating several
SSEs (or one emission may be addressed to different extents by dif-
ferent mitigation strategies), a matrix is populated with EPs that
reﬂect a reduction in P
, denoted by EP
. Equation (2) dem-
onstrates how to calculate EP
where eis the SSE and mis the
An example of the matrix that is populated by Eq. (2) is shown in
matrix (3). Here, each row corresponds to a failure emission while
each column corresponds to a mitigation strategy. Many of the cells
resolve to zero in this matrix, indicating that the mitigation strategy
has no impact on that emission.
Next, MP can be calculated for the matrix produced from Eq. (2)
as shown in Eq. (4). In this equation, EP
represents a column vector
of the original EPs as identiﬁed in Table 2.
3.9 Step 6: Determine What Mitigation Strategies to
Implement. In order to determine what mitigation strategies to
implement in a SoI to reduce its potential negative impact on the
SoS, we propose the mitigation rank priority (MRP) metric which
converts MP into a metric than can be more easily rank-ordered.
Equation (5) shows how to determine MRP for a speciﬁc mitigation
MRPm=rank( max (MPm))
MRP as presented in Eq. (5) is only one potential formulation of
MRP, where each term corresponds to the estimated worst case
(max), average case (mean), and predictability (standard deviation)
of the distribution. Practitioners may wish to change the formula-
tion depending on, for instance, how much conﬁdence they have
in their data sources. The important aspect of MRP for the pur-
poses of this method is that it can be used to develop rank order-
ings and trade space exploration analysis which may be useful to
SoI system stakeholders and decision-makers for their understand-
ing of SSE risks and mitigation strategies. In short, MRP helps in
the communication of risk management to stakeholders and
At this point in the method, trade-off studies and optimization can
be conducted between major SoI system constraints and require-
ments, mitigation strategies and their corresponding reduction in
probability of a SSE from leaving the SoI system boundary that
adversely impacts other systems within the SoS, and other impor-
tant system performance metrics. An approach we suggest is to
maximize total MRP (sum of all MRP
identiﬁed for implementa-
tion) within the constraint of a cost cap on total mitigation cost (M
for the SoI.
3.10 Step 7: Iterate and Reanalyze. Now that mitigation
strategies have been chosen and are ready for implementation into
the SoI system functional model, and we suggest iterating
through the method at least once more to verify that the mitigation
strategies have not introduced new failures into the SoI or SSEs that
are undesirable. In particular, Table 7indicates if there are new
) created by the proposed mitigation strategies.
Re-analysis is further justiﬁed by the potential for the failure prob-
ability requirements set in the preparatory step being violated from
unintended consequences of the mitigation strategies. For instance,
a new rotor shroud on the UAV SoI may signiﬁcantly reduce
payload capacity thus violating requirement #1 from Table 1.
Iteration of the SoI system design through the method stops when
the requirements set in the preparatory step of the method are met.
At this point, the practitioner can be relatively conﬁdent in a thor-
ough consideration of potential SSEs having been conducted. Fur-
thermore, a practitioner can be reasonably assured that a signiﬁcant
assessment of potential mitigation strategies has been completed.
The resulting SoI system design is expected to produce fewer
SSEs that may damage other systems within the SoS.
The method presented above differs from existing methods of
identifying and mitigating SSEs in an SoS context in several
ways. Most existing methods such as requirements management,
PRA and FMECA, and other similar techniques from the systems
Table 2 Consequence data for an mixed UAV and unmanned
ground vehicle (UGV) SoS where consequence is the cost
distribution function C
for the impact of the system on the SoS
Failure ﬂow exports from
system of interest that leads
to initiating events for other
systems in the SoS Consequence C
Energy-electrical Static-electric discharges during dust
storms caused by UAV rotors or
propellers can short out onboard
electronics of nearby vehicles leading
to loss of both UAVs and UGVs
Material-solid-particulate Large particulate from crashed UAVs
can clog air vents and cause
overheating of UGVs leading to
Material-control-analog Interference with radio transceivers
causes UAVs to automatically land
regardless of terrain or of potential
Note: In this example, each C
is a point distribution.
Journal of Computing and Information Science in Engineering OCTOBER 2020, Vol. 20 / 054501-5
engineering community either only implicitly suggest that SSEs be
examined and mitigated at the conceptual stage of design before
functional architecture has been solidiﬁed or explicitly examine
spurious systems emissions after functional architectures have
been ﬁnalized and component design has begun. While our previ-
ous work looks at SSEs , it does so from the perspective of
defending against the spurious system emissions rather than pre-
venting the emissions from occurring in the ﬁrst place.
Successful implementation of the method in the system architec-
ture phase of the system design may beneﬁt system engineers by
Table 3 An example of examining a channel-guide-rotate function to understand which potential failure ﬂows can occur
Failure ﬂow imports
Failure ﬂow exports
Primary Secondary Tertiary →Primary secondary Tertiary Component solution(s) to function
Energy Mechanical Translational →Gas DC motor
Energy Electrical →Liquid AC motor
Energy Mechanical Translational →Solid Object AC motor, DC motor
Energy Mechanical Translational →Particulate AC motor, DC motor, pneumatic motor
Signal Status Auditory
Energy Mechanical Pneumatic →Visual Pneumatic motor
Energy Electrical →Control Analog AC motor
Energy Electromagnetic Solar →”” ” AC motor
Energy Electrical →Electromagnetic Optical DC motor
Energy Radioactive/nuclear →Thermal AC, DC, pneumatic motor
Note: Failure ﬂows generated by speciﬁc component solutions are indicated on the right-hand side of the table. Failure ﬂow exports that have been reasonably
proven to be impossible for the function to emit have been crossed out. In certain cases, multiple failure ﬂow exports may be developed from the same failure
ﬂow import. Additionally, some failure ﬂow exports may have multiple associated component solutions to the function or one component solution to the
function may be associated with multiple potential failure ﬂow exports.
Table 4 Subset of failure ﬂow paths of the UAV SoI that exit the
path Failure ﬂow path
1 Energy-electrical →provision-supply →energy-electrical →
2 Material-mixture-gas/solid →channel-guide-translate →
3 Provision-supply →energy-electrical →channel-guide-rotate
Table 5 Probability of occurrence of a representative subset of
failure ﬂows identiﬁed through the proposed method that exit the
SoI boundary as SSEs
Failure ﬂows that result in system emissions PO
Energy, mechanical, translational 2.2 × 10
Material, gas 4.3 × 10
Signal, status, visual 5.6 × 10
Material, solid, particulate 1.9 × 10
Material, liquid 8.3 × 10
Table 6 Representative subset of SSE EPs of the UAV SoI
Spurious system emission P
Energy-mechanical-translational 5.2 ×10
/year $5M $2600/year
Material-solid-particulate 1.9 ×10
/year $1M $19/year
Material-control-analog 2.6 ×10
/year $2M $520/year
comes from Table 5and C
is from Table 2. Entries are rank
ordered by EP to indicate which SSEs have the biggest negative impact
on the SoS.
054501-6 / Vol. 20, OCTOBER 2020 Transactions of the ASME
aiding in identifying SSEs earlier than they otherwise would have
been—speciﬁcally during the development of functional architec-
ture models. By identifying potential SSEs very early in the
design process, system engineers can implement strategies to
prevent the SSEs from happening as part of the initial system archi-
tecting effort rather than implement remediation and/or mitigation
strategies much later in the systems design process where costs
are much higher and deviation from schedule may be signiﬁcant.
During the development of the case study, we identiﬁed a few of
the types of unexpected insights that the proposed method may
uncover. For instance, we found that a variety of SSEs may make
the UAV SoIs in an SoS more detectable by adversaries. We also
found that some failures in subsystems such as those involved elec-
tronic warfare countermeasures on the UAV SoI may cause SSEs
that have a signiﬁcant detrimental effect to the other systems in
the SoS including a disruption in communications. The method pro-
vides a framework to not only identify these SSEs and communicate
their impacts but also to weigh the trade-offs between mitigation
strategies at the functional stage.
The method can be used in parallel on many different SoIs within
an SoS which allows for a comparison across all mitigation strate-
gies for all SoIs in an SoS to be conducted during step 6 to identify
the biggest return on investment to buy down overall risk of SoS
failure. Taking a larger SoS-level view may help to save signiﬁcant
cost and drastically increase probability of SoS mission success. An
initial investigation of conducing the method in parallel on multiple
SoIs indicates that the method presented above is quite extensible
and ﬂexible in this regard.
One signiﬁcant challenge of the method is the amount of effort
required to develop the various database products and analyses.
However, we argue that similar efforts are needed for PRA and
for other FFIP-based methods. In our experience, PRA analysis
can be extremely data-intensive and often span many years in the
case of complex systems such as nuclear reactors as evidenced by
the lengthy PRA process that reactors must undergo before they
are certiﬁed for construction and use .
One limitation of the method is that it is speciﬁcally designed to
be used in the case where a practitioner has a good understanding of
the SoS that the SoI being engineered will be placed within. In the
case where an entirely new SoS is under development, additional
methodological development is needed to manage the uncertainty
posed by the situation. If nothing is known of the SoS, C
be determined. The only information available to a practitioner
would then be PO
Validation of the results of the method is an important step that
we advocate be performed by a human. We intend for the method
to include a human in the loop at every iteration in order to vali-
date that the results are reasonable. While automating, the valida-
tion may be possible in the future with a very robust failure and
mitigation repository, such an undertaking is very resource-
A potential fruitful avenue of future work may be to develop a
method that ties together failure analysis of an SoS by bridging
the method presented in this paper and our previous work .
This may provide a new way of making large system architecture
decisions while such decisions are still relatively inexpensive to
implement. However, the implementation may be computationally
This paper presented a conceptual design method intended for
use during the system architecture phase of the systems engineering
process and speciﬁcally during functional architecture development
to identify and mitigate potential SSEs originating from a SoI that
can negatively impact an SoS. The method is conducted using func-
tional models which are appropriate for early system architecture
trade-off studies. A systematic way to identify potential low proba-
bility but high consequence SSEs is presented using the FBED ﬂow
taxonomy. Practitioners can use the method to identify and mitigate
SSEs from an SoI to prevent damage to other systems within an
SoS. An illustrative case study of a UAV SoI being designed to
enter service with an existing SoS is presented to demonstrate the
This research is partially supported by the Naval Postgraduate
School and the Technical University of Denmark. Any opinions
or ﬁndings of this work are the responsibility of the authors and
do not necessarily reﬂect the views of the sponsors or collaborators.
 Blanchard, B., and Fabrycky, W., 2006, Systems Engineering and Analysis, 4th
ed. (International Series in Industrial and Systems), Prentice-Hall, Upper
Saddle River, NJ.
 Kapurch, S., 2010, NASA Systems Engineering Handbook, DIANE Publishing
Company, Hanover, MD.
 Crawley, E., Cameron, B., and Selva, D., 2015, System Architecture: Strategy and
Product Development for Complex Systems. Always Learning. Pearson,
 Gold, R., 2016, “Mission Engineering,”19th Annual NDIA Systems Engineering
Conference, Springﬁeld, VA, Oct. 24–27.
 Hernandez, A. S., Karimova, T., Nelson, D. H., Ng, E., Nepal, B., and Schott, E.,
2017, “Mission Engineering and Analysis: Innovations in the Military Decision
Making Process,”Proceedings of the American Society for Engineering
Management (ASEM) 2017 International Annual Conference: Reimagining
Systems Engineering and Management, Huntsville, AL, Oct. 18–21, pp. 521–530.
Table 7 Sample mitigation strategies for a subset of the UAV SoI SSEs
function(s) Physical solution(s) P
ﬂow(s) NFFLS? P
Shielding to prevent rotor strikes 4.7 ×10
/year Material, solid,
Yes 3.5 ×10
Signal, process Redundant control system to
verify visual control signals
/year No No 0 $1M
Material, liquid Provision, store,
Catchment subsystem to retain
any liquid generated by failed
/year No No 0 $500k
”Channel, export Long hose to direct liquid to
Yes 3.1 ×10
is the probability of a mitigated SSE still occurring. NFFLS represents if a new SSE may leave the SoI as a result of the mitigation strategy
is the probability distribution function of a new SSE leaving the system. M
is the mitigation cost distribution function.
Journal of Computing and Information Science in Engineering OCTOBER 2020, Vol. 20 / 054501-7
 Giles, K., and Giammarco, K., 2019, “A Mission-Based Architecture for Swarm
Unmanned Systems,”Syst. Eng.,22(3), pp. 271–281.
 Beery, P., and Paulo, E., 2019, “Application of Model-Based Systems
Engineering Concepts to Support Mission Engineering,”Systems,7(3), p. 44.
 Jamshidi, M. and Sage, A. P., eds., 2008, System of Systems Engineering:
Innovations for the Twenty-ﬁrst Century, Vol. 1, Wiley, Hoboken, NJ.
 Sousa-Poza, A., Kovacic, S., and Keating, C., 2008, “System of Systems
Engineering: An Emerging Multidiscipline,”Int. J. Syst. Syst. Eng.,1(1–2),
 Otto, K., and Wood, K., 2001, Product Design: Techniques in Reverse
Engineering and New Product Development, Prentice Hall, Englewood Cliffs,
 van Eck, D., McAdams, D. A., and Vermaas, P. E., 2007, “Functional
Decomposition in Engineering: A Survey,”ASME 2007 International Design
Engineering Technical Conferences and Computers and Information in
Engineering Conference, Las Vegas, NV, Sept. 4–7, American Society of
Mechanical Engineers, pp. 227–236.
 Hirtz, J., Stone, R., McAdams, D., Szykman, S., and Wood, K., 2002, “A
Functional Basis for Engineering Design: Reconciling and Evolving Previous
Efforts,”Res. Eng. Des.,13(2), pp. 65–82.
 Stone, R. B., and Wood, K. L., 2000, “Development of a Functional Basis for
Design,”ASME J. Mech. Des.,122(4), pp. 359–370.
 Bohm, M. R., Stone, R. B., and Szykman, S., 2005, “Enhancing Virtual Product
Representations for Advanced Design Repository Systems,”J. Comput. Inf. Sci.
Eng., 5(4), pp. 360–372.
 Bohm, M. R., Vucovich, J. P., and Stone, R. B., 2008, “Using a Design
Repository to Drive Concept Generation,”ASME J. Comput. Inf. Sci. Eng.,
8(1), p. 014502.
 Bohm, M. R., Stone, R. B., Simpson, T. W., and Steva, E. D., 2008, “Introduction
of a Data Schema to Support a Design Repository,”Comput. Aided Des.,40(7),
 Van Wie, M., Bryant, C. R., Bohm, M. R., McAdams, D. A., and Stone, R. B.,
2005, “A Model of Function-Based Representations,”AI EDAM, 19(2),
 Gilchrist, W., 1993, “Modelling Failure Modes and Effects Analysis,”Int. J. Qual.
Reliab. Manage., 10(5), pp. 16–23.
 Stott, J. E., Britton, P. T., Ring, R. W., Hark, F., and Hatﬁeld, G. S., 2010,
“Common Cause Failure Modeling: Aerospace Versus Nuclear.”, Proceedings
of the 10th International Conference on Probabilistic Safety Assessment and
Management, Seattle, WA, June 7–11, IAPSAM, pp. 1–12, Paper 371.
 Knochenhauer, M., and Louko, P., 2004, “Guidance for External Events
Analysis,”Probabilistic Safety Assessment and Management, C. Spitzer, U.
Schmocker, and V. N. Dang, eds., Springer, New York, pp. 1498–1503.
 Sorensen, J. N., Apostolakis, G. E., Kress, T. S., and Powers, D. A., 1999, “On the
Role of Defense in Depth in Risk-Informed Regulation,”Proceedings of PSA ’99,
International Topical Meeting on Probabilistic Safety Assessment, Washington,
DC, Aug. 22–26, American Nuclear Society, La Grange Park, IL, pp. 408–413.
 Modarres, M., 2009, “Advanced Nuclear Power Plant Regulation Using
Risk-Informed and Performance-Based Methods,”Reliab. Eng. Syst. Saf.,
94(2), pp. 211–217.
 Henley, E. J., and Kumamoto, H., 1981, Reliability Engineering and Risk
Assessment, Vol. 568, Prentice-Hall, Englewood Cliffs, NJ.
 Kurtoglu, T., Tumer, I. Y., and Jensen, D. C., 2010, “A Functional Failure
Reasoning Methodology for Evaluation of Conceptual System Architectures,”
Res. Eng. Des.,21(4), pp. 209–234.
 Jensen, D., Tumer, I. Y., and Kurtoglu, T., 2009, “Flow State Logic (FSL) for
Analysis of Failure Propagation in Early Design,”International Design Theory and
Methodology Conference, IDETC/CIE, San Diego, CA, Aug. 30–Sept. 2, ASME.
 Van Bossuyt, D. L., O’Halloran, B. M., and Arlitt, R. M., 2019, “A Method of
Identifying and Analyzing Irrational System Behavior in a System of Systems,”
Syst. Eng.,22(6), pp. 519–537.
 Coldren, L. O., 1985, “Afghanistan in 1984: The Fifth Year of the Russo-Afghan
War,”Asian Surv.,25(2), pp. 169–179.
 Hunsaker, L., 2015, “ARSENL Reaches Its Ultimate Goal of 50 Autonomous
UAVs in Flight,”https://nps.edu/-/arsenl-reaches-its-ultimate-goal-of-50-
 Kurtoglu, T., and Tumer, I. Y., 2008, “A Graph-Based Fault Identiﬁcation and
Propagation Framework for Functional Design of Complex Systems,”ASME
J. Mech. Des.,130(5), p. 051401.
 O’Halloran, B. M., 2013, “A Framework to Model Reliability and Failures in
Complex Systems During the Early Engineering Design Process,”Ph.D. thesis,
School of Mechanical, Industrial, and Manufacturing Engineering, Corvallis, OR.
 Anderson, D., 2018, “A Design Process for Design Automation,”Ph.D. thesis,
Singapore University of Technology and Design, Singapore.
 Westinghouse Electric Company, LLC, 2004, AP1000 Probabilistic Risk
Assessment, revision7th ed., WestinghouseElectric Company,LLC, Pittsburgh, PA.
 Van Bossuyt, D. L., and Arlitt, R., 2019, “Toward a Functional Failure Analysis
Method of Identifying and Mitigating Spurious System Emissions in a System of
Systems,”International Design Theory and Methodology Conference, IDETC/
CIE, ASME, Anaheim, CA.
054501-8 / Vol. 20, OCTOBER 2020 Transactions of the ASME