ArticlePDF Available

A Functional Failure Analysis Method of Identifying and Mitigating Spurious System Emissions From a System of Interest in a System of Systems


Abstract and Figures

Increasingly tight coupling and heavy connectedness in systems of systems (SoS) presents 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 significant 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 a SoS by failing in ways that do not further degrade a 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 flows 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 investment 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.
Content may be subject to copyright.
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 systemsdesigners 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-
nicant damage when one member system fails in an unanticipated
way. It is therefore important to develop systems that are good
neighborswith the other systems in an SoS by failing in ways
that do not further degrade an SoSs 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 SoIs 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.
[DOI: 10.1115/1.4046991]
Keywords: model-based systems engineering, system of systems,
failure analysis, functional model
1 Introduction
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-
ment schedule.
1.1 Specic 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 SoIs system boundaryspurious
system emissions (SSEs)that otherwise may not have been iden-
tied 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 identied 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 [47] and SoS engineering also
play a signicant role in many SoI system architecting efforts [8,9].
Functional modeling helps to develop an understanding of how
systems work at the functional level [10] during system architecture
development. There are a variety of different taxonomies available
to produce functional models [11]. 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 [1416]. One function may have many potential component
solutions, such as converting electrical energy function to rotational
energy function may be satised by several types of electrical
motors and ows can similarly have multiple physical manifesta-
tions [17].
Throughout the system design process, a variety of failure anal-
ysis methods are often employed such as FMECA early in a system
design process [18] and PRA which often is done after major system
architecture decisions have been made [19]. PRA uses the concept
of an initiating eventan event that is the starting point for a failure
that propagates through a system [20]. 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 [23]. The function failure identication 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
Corresponding author.
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 [26]. Our previous work is in contrast with the method
advanced in this paper that specically focuses on not allowing
SSEs from an SoI to occur that may negatively affect the rest of
an SoS.
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.
3 Methodology
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 specically, the
functional architecture is being rened. 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 [27] 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 specic payloads and mission constraints identied 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 simplied to better highlight the specic 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 identied and developed as necessary
and are specic 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 [31]),
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. [12]). In many cases, a nominal system design
process will already have developed a functional model as part of
modeling the system [3]. 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 specic 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
the method.
Finally, an analysis of the SoIs 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
,dened as the probability density of the cost
of a system damaging other systems within a SoS from emitted
failure ows.
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 identied
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 ows 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 identied failure ow exports shown in Table 3from
the function are then appended to the functions 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
Req Requirement
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
identied 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 identied, 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 specic SSEs that they produce.
Table 5shows a representative subset of cut-sets for the UAV SoI
that only includes the SSEs identied 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
can be
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
reect a reduction in P
, denoted by EP
. Equation (2) dem-
onstrates how to calculate EP
where eis the SSE and mis the
mitigation strategy.
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 identied in Table 2.
×EPReduced +MC(4)
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 specic mitigation
strategy, m.
MRPm=rank( max (MPm))
+rank(std(MPm)) (5)
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 condence 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
identied 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 justied 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 signicantly 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 condent in a thor-
ough consideration of potential SSEs having been conducted. Fur-
thermore, a practitioner can be reasonably assured that a signicant
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.
4 Discussion
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
disabled systems
Material-control-analog Interference with radio transceivers
causes UAVs to automatically land
regardless of terrain or of potential
adversary presence
⋮⋮ ⋮
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 solidied 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 [26], 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 benet 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
Material Human
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
Mixture Gasgas
Signal Status Auditory
Energy Mechanical Pneumatic Visual Pneumatic motor
Energy Electrical Control Analog AC motor
Energy Electromagnetic Solar ”” AC motor
Energy Human
Energy Electrical Electromagnetic Optical DC motor
Mechanical Rotational
Energy Radioactive/nuclear Thermal AC, DC, pneumatic motor
Note: Failure ows generated by specic 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
system boundary
path Failure ow path
1 Energy-electrical provision-supply energy-electrical
channel-export signal-control-discrete
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 identied 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
Note: P
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
beenspecically 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 signicant.
During the development of the case study, we identied 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 signicant 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 signicant
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 signicant 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 certied for construction and use [32].
One limitation of the method is that it is specically 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 [26].
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
5 Conclusion
This paper presented a conceptual design method intended for
use during the system architecture phase of the systems engineering
process and specically 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 reect the views of the sponsors or collaborators.
[1] Blanchard, B., and Fabrycky, W., 2006, Systems Engineering and Analysis, 4th
ed. (International Series in Industrial and Systems), Prentice-Hall, Upper
Saddle River, NJ.
[2] Kapurch, S., 2010, NASA Systems Engineering Handbook, DIANE Publishing
Company, Hanover, MD.
[3] Crawley, E., Cameron, B., and Selva, D., 2015, System Architecture: Strategy and
Product Development for Complex Systems. Always Learning. Pearson,
Hoboken, NJ.
[4] Gold, R., 2016, Mission Engineering,19th Annual NDIA Systems Engineering
Conference, Springeld, VA, Oct. 2427.
[5] 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. 1821, pp. 521530.
Table 7 Sample mitigation strategies for a subset of the UAV SoI SSEs
Spurious system
Mitigation strategy
function(s) Physical solution(s) P
New failure
ow(s) NFFLS? P
magnitude, stop,
Shielding to prevent rotor strikes 4.7 ×10
/year Material, solid,
Yes 3.5 ×10
/year $300k
Signal, status,
Signal, process Redundant control system to
verify visual control signals
before sending
4.2 ×10
/year No No 0 $1M
Material, liquid Provision, store,
Catchment subsystem to retain
any liquid generated by failed
battery cells
5.2 ×10
/year No No 0 $500k
Channel, export Long hose to direct liquid to
6.2 ×10
/year Material,
mixture, liquid
Yes 3.1 ×10
/year $250k
⋮⋮⋮ ⋮
Note: P
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
function. P
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
[6] Giles, K., and Giammarco, K., 2019, A Mission-Based Architecture for Swarm
Unmanned Systems,Syst. Eng.,22(3), pp. 271281.
[7] Beery, P., and Paulo, E., 2019, Application of Model-Based Systems
Engineering Concepts to Support Mission Engineering,Systems,7(3), p. 44.
[8] Jamshidi, M. and Sage, A. P., eds., 2008, System of Systems Engineering:
Innovations for the Twenty-rst Century, Vol. 1, Wiley, Hoboken, NJ.
[9] Sousa-Poza, A., Kovacic, S., and Keating, C., 2008, System of Systems
Engineering: An Emerging Multidiscipline,Int. J. Syst. Syst. Eng.,1(12),
pp. 117.
[10] Otto, K., and Wood, K., 2001, Product Design: Techniques in Reverse
Engineering and New Product Development, Prentice Hall, Englewood Cliffs,
[11] 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. 47, American Society of
Mechanical Engineers, pp. 227236.
[12] 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. 6582.
[13] Stone, R. B., and Wood, K. L., 2000, Development of a Functional Basis for
Design,ASME J. Mech. Des.,122(4), pp. 359370.
[14] 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. 360372.
[15] 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.
[16] 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),
pp. 801811.
[17] 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),
pp. 89111.
[18] Gilchrist, W., 1993, Modelling Failure Modes and Effects Analysis,Int. J. Qual.
Reliab. Manage., 10(5), pp. 1623.
[19] Stott, J. E., Britton, P. T., Ring, R. W., Hark, F., and Hateld, 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 711, IAPSAM, pp. 112, Paper 371.
[20] 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. 14981503.
[21] 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. 2226, American Nuclear Society, La Grange Park, IL, pp. 408413.
[22] Modarres, M., 2009, Advanced Nuclear Power Plant Regulation Using
Risk-Informed and Performance-Based Methods,Reliab. Eng. Syst. Saf.,
94(2), pp. 211217.
[23] Henley, E. J., and Kumamoto, H., 1981, Reliability Engineering and Risk
Assessment, Vol. 568, Prentice-Hall, Englewood Cliffs, NJ.
[24] 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. 209234.
[25] 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. 30Sept. 2, ASME.
[26] Van Bossuyt, D. L., OHalloran, 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. 519537.
[27] Coldren, L. O., 1985, Afghanistan in 1984: The Fifth Year of the Russo-Afghan
War,Asian Surv.,25(2), pp. 169179.
[28] Hunsaker, L., 2015, ARSENL Reaches Its Ultimate Goal of 50 Autonomous
UAVs in Flight,
[29] Kurtoglu, T., and Tumer, I. Y., 2008, A Graph-Based Fault Identication and
Propagation Framework for Functional Design of Complex Systems,ASME
J. Mech. Des.,130(5), p. 051401.
[30] OHalloran, 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.
[31] Anderson, D., 2018, A Design Process for Design Automation,Ph.D. thesis,
Singapore University of Technology and Design, Singapore.
[32] Westinghouse Electric Company, LLC, 2004, AP1000 Probabilistic Risk
Assessment, revision7th ed., WestinghouseElectric Company,LLC, Pittsburgh, PA.
[33] 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
... The work presented in this paper focuses on systems that may be tasked with conducting missions as part of several different SoSs. When a system moves between SoSs, there is a risk that emergent behaviors may occur within the SoS [7,8]. ...
... Other methods such as probabilistic risk assessment (PRA) are commonly used in industries where the outcome of a failure could be very serious [10,11]. We use functional failure identification and propagation (FFIP) in this paper which is a method of analyzing functional models to understand how failures can propagate through a system or a SoS to cause failure [7,8,[12][13][14]. Several methods of mitigating failures at the functional level have been proposed [15][16][17] in addition to methods such as redundancy, diversity, and defense in depth [18]. ...
... Existing systems engineering models are next collected or developed if they do not already exist. Of particular use to the proposed method are FFIP models including the baseline FFIP models and other FFIP-based models such as the analyses that the irrational system behavior FFIP-based methods produce [7,8]. ...
Conference Paper
Full-text available
With the growth of autonomy and augmentation of machine learning in system decision-making, systems-of-systems (SoS) have become increasingly complex. Security and safety, as well as national economic stability, are reliant on interconnected systems with multiple decision making components. While such inter-connectivity advances the speed at which action and mission control decision making can take place, it also increases the number of dependencies at risk in the case of an attack and the speed at which attacks become effective in their goals. Attacks on the supply chain and on system lifecycle phases other than the operation are also becoming more common. In this paper we consider from a mission engineering perspective a complex reconfigurable SoS covering management of a wind farm with autonomous uncrewed patrol systems, crewed maintenance vessels , back-end control and machine learning components. The complex SoS is situated in the exclusive economic zone of one country, but with perimetric position to regional power competitors. We investigate causal effects of adversarial capabilities in * Address all correspondence to this author. the case study, using a zero trust combined with Defense in Depth approach. Of particular interest are situations where an adversary injects an incipient fault during one mission that is only brought to fruition during a subsequent mission.
... With the growing interest in machine learning (ML) applications and solutions, critical systems engineering choices must start incorporating hitherto unaccounted risks from potential threats associated with ML data collection, training, and ML-based decisions. Complex system design and risk assessments are not foreign to system design and risk assessments: cyber-physical systems such as drones, automated factories, autonomous vehicles, financial investment systems, virtual assistants, etc. have all benefited from such analysis [1][2][3]. Thus, this work attempts to account for and adapting to the risks posed by increasingly automated systems that use advanced ML techniques in a systems engineering context. ...
... Numerous methods such as Failure Modes Effects and Criticality Analysis (FMECA), Probabilistic Risk Assessment (PRA), hazard analysis, reliability analysis, and others exist to identify potential issues that cross discipline boundaries and can have adverse impact on the system [1][2][3][14][15][16][17]. However, systems still suffer "black swan events" where a deleterious emergent system behavior occurs that was either not predicted or ignored during system design [3,18,19]. ...
... Numerous methods such as Failure Modes Effects and Criticality Analysis (FMECA), Probabilistic Risk Assessment (PRA), hazard analysis, reliability analysis, and others exist to identify potential issues that cross discipline boundaries and can have adverse impact on the system [1][2][3][14][15][16][17]. However, systems still suffer "black swan events" where a deleterious emergent system behavior occurs that was either not predicted or ignored during system design [3,18,19]. Research is ongoing in this area in an attempt to address these issues and produce safer, more reliable systems. ...
Conference Paper
Full-text available
Fuelled by recent technological advances, Machine Learning (ML) is being introduced to safety and security-critical applications like defence systems, financial systems, and autonomous machines. ML components can be used either for processing input data and/or for decision making. The response time and success rate demands are very high and this means that the deployed training algorithms often produce complex models that are not readable and verifiable by humans (like multi layer neu-ral networks). Due to the complexity of these models, achieving complete testing coverage is in most cases not realistically possible. This raises security threats related to the ML components presenting unpredictable behavior due to malicious manipulation (backdoor attacks). This paper proposes a methodology based on established security principles like Zero-Trust and defence-in-depth to help prevent and mitigate the consequences of security threats including ones emerging from ML-based components. The methodology is demonstrated on a case study of an Unmanned Aerial Vehicle (UAV) with a sophisticated Intelli-* Address all correspondence to this author. gence, Surveillance, and Reconnaissance (ISR) module.
... Some of these are physics of failure prediction, historical failure data prediction, hybrid physics and data approaches, and functional failure mitigation modeling [24][25][26]. Failure research in the stated areas consists of stored system of systems, systems with spurious emissions, off-the-shelf software components, power electronics, turbine blades, and oil pipelines [27][28][29][30][31][32][33]. Maintainability prediction methods using hybrid neural networks, fuzzy logic, extreme learning machines, and mixture frailty models have also been used to predict the maintainability of evolving software systems, object-oriented systems, and mechanical components [34][35][36][37][38]. ...
Full-text available
Model-Based Systems Engineering (MBSE) methods have developed a strong foothold in the design space in industry. These methods have proven fruitful when the right method is applied to the right problem. Reliability, Availability, and Maintainability (RAM) is an equally important area. Currently, there is a gap in applying a methodology to integrate the two in the design process, particularly when the design is complex. This work attempts to provide a methodology that results in the successful integration of RAM and MBSE that can be used during the early phases of design. The methodology was developed after an extensive literature review, followed by the illustration of the methodology through an example of a steam turbine fuel system. Each step of the method is applied and explained in the illustrative example, to include figures, tables, and calculations demonstrating the effectiveness of the method, concluding with evidence for validation.
... Prior work has used methods such as Bayesian hierarchical clustering to help identify the most advantageous component solutions to functions based on information that is brought up into the conceptual design phase which otherwise would be developed much later in the system design process [19]. Methods of analyzing failure, risk, and reliability in systems take a similar approach where detailed failure information is developed early on and used in reliability and risk analyses during conceptual design to promote better risk-informed decision-making which is intended to speed the entire system development process by reducing the need for re-design or the late addition of subsystems to address specific threats or vulnerabilities to the system [20][21][22][23][24]. ...
Conference Paper
Full-text available
We introduce a method to help protect against and mitigate possible consequences of major regional and global events that can disrupt a system design and manufacturing process. The method is intended to be used during the conceptual phase of system design when functional models have been developed and component solutions are being chosen. Disruptive events such as plane crashes killing many engineers from one company travel-ing together, disease outbreaks killing or temporarily disabling many people associated with one industrial sector who travel to the same conference regularly, geopolitical events that impose tariffs or complete cessation of trade with a country that supplies a critical component, and many other similar physical and virtual events can significantly delay or disrupt a system design process. By comparing alternative embodiment, component, and low-level functional solutions, solutions can be identified that better pass the bus factor where no one disruptive event will cause a major delay or disruption to a system design and manufacturing process. We present a simplified case study of a renewable energy generation and storage system intended for residential use to demonstrate the method. While some challenges to immediate adoption by practitioners exist, we believe the method has the potential to significantly improve system design processes so that systems are designed, manufactured, and delivered on schedule and on budget from the perspective of significant dis-ruptive events to design and manufacturing.
... They have been used to develop a design methodology to perform failure analysis at the conceptual stage to reduce product development time [11]. An augmented approach has been used at the systems of systems level to mitigate the instances of a subsystem's failure to propagate to the rest of the system [12]. Function models have also been used in combination with artificial neural networks to predict market price of electromechanical products [13]. ...
Conference Paper
Full-text available
This paper presents the development of logic rules for evaluating the fitness of function models synthesized by an evolutionary algorithm. A set of 65 rules for twelve different function verbs are developed. The rules are abstractions of the definitions of the verbs in their original vocabularies and are stated as constraints on the quantity, type, and topology of flows connected to the functions. The rules serve as an objective and unambiguous basis of evaluating the fitness of function models developed by a genetic algorithm. The said algorithm and the rules are implemented in software code, which is used to both demonstrate and validate the efficacy of the rule-based approach of converging function model synthesis using GAs.
... While we advocate the MEDRAF ZT hybrid safety/security risk assessment methodology presented above, the methodology is intended to be used as part of a suite of risk assessment analysis methods. For instance, where appropriate, FMECA should still be performed and other efforts such as identifying and mitigating spurious signals into a system should be undertaken [58]. The methodology is meant to augment -not replace -existing analysis methods. ...
Full-text available
Designing complex, socio-technical, cyber-physical systems has become increasingly challenging in recent years. Interdependencies between engineering domains can lead to emergent behavior that is difficult to predict and manage. The recent shift toward model-based design has demonstrated significant advantages for minimizing these challenges. Further, the early identification of safety and security design weaknesses in safety-critical systems leads to reduced redesign costs in later design phases. As a result, this article contributes the Multidisciplinary Early Design Risk Assessment Framework for early combined safety and security assessment based on interdisciplinary dependency models of a system. The focus is on factors contributing to the estimation of the probabilities of successful attacks on system components. The Zero Trust paradigm is applied in which all humans, hardware, and processes interacting with the system are considered to pose a security risk. A calculation of security-related probability estimates is presented which is dependent on the current global security environment. Subsequently, security and safety probability estimates are combined to present an overall safety-security risk calculation using hybrid safety-security trees. The risk values help designers assess the loss of specific key components and safety functions. The methodology is demonstrated with a case study of a spent fuel pool cooling system in a nuclear reactor. The results of the case study show that the risk of losing one key system component doubles when combining security and safety compared to only assessing safety events. This paper is based on a paper presented at CIE 2020.
... These models include (but are not limited to) agent-based models [28][29][30], discrete event simulations [31], and a Bayesian network-based interdependency analysis [8,24]. Efforts are also being made to devise computationally cheaper techniques, such as dependency network analyses [32][33][34] and function failure identification and propagation [35], that can analyze how disruptions to one system could propagate through a SoS. These evaluations, however, can be made only once the SoS architecture is decided, and detailed knowledge regarding the behavior of the constituent systems, their interactions, and the effects of any operating conditions is available. ...
The objective of this study is to investigate the value of an ecologically inspired architectural metric called the Degree of System Order in the System of Systems (SoS) architecting process. Two highly desirable SoS attributes are the ability to withstand and recover from disruptions (resilience) and affordability. In practice, more resilient SoS architectures are less affordable and it is essential to balance the trade-offs between the two attributes. Ecological research analyzing long-surviving ecosystems (nature's resilient SoS) using the Degree of System Order metric has found a unique balance of efficient and redundant interactions in their architecture. This balance implies that highly efficient ecosystems tend to be inflexible and vulnerable to perturbations while highly redundant ecosystems fail to utilize resources effectively for survival. Motivated by this unique architectural property of ecosystems, this study investigates the response to disruptions vs. affordability trade-space of a large number of feasible SoS architectures. Results indicate that the most favorable SoS architectures in this trade-space share a specific range of values of Degree of System Order. This suggests that Degree of System Order can be a key metric in engineered SoS development. Evaluating the Degree of System Order does not require detailed simulations and can, therefore, guide the early stage SoS design process towards more optimal SoS architectures.
... While many unintended consequences affect the performance or safety [1] of a system, some unintended consequences affect other systems. For example, in tightly coupled systems of systems (SoS), the failure of one system can have unintended consequences on the rest of the systems [2]. While it is often possible to discern the proximate and even root causes of unintended consequences in hindsight, it is challenging to predict unintended consequences proactively during the design of novel engineered products or systems due to complexity and the bounded rationality of human designers. ...
Conference Paper
When designing engineered systems, the potential for unintended consequences of design policies exists despite best intentions. The effect of risk factors for unintended consequences are often known only in hindsight. However, since historical knowledge is generally associated with a single event, it is difficult to uncover general trends in the formation and types of unintended consequences. In this research, archetypes of unintended consequences are learned from historical data. This research contributes toward the understanding of archetypes of unintended consequences by using machine learning over a large data set of lessons learned from adverse events at NASA. Sixty-six archetypes are identified because they share similar sets of risk factors such as complexity and human-machine interaction. To validate the learned archetypes, system dynamics representations of the archetypes are compared to known high-level archetypes of unintended consequences. The main contribution of the paper is a set of archetypes that apply to many engineered systems and a pattern of leading indicators that open a new path to manage unintended consequences and mitigate the magnitude of potentially adverse outcomes.
Conference Paper
Full-text available
Increasingly tight coupling and heavy connectedness in systems of systems (SoS) presents new problems for systems designers and engineers. While the failure of one system within a SoS may produce little collateral damage beyond a loss in SoS capability, a highly interconnected SoS can experience significant 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 a SoS by failing in ways that do not further degrade a SoS’s ability to complete its mission. This paper presents a method to (1) analyze a system for potential spurious emissions and (2) choose mitigation strategies that provide the best return on investment for the SoS. The method is suited for use during the system architecture phase of the system design process. A functional and flow approach to analyzing spurious emissions and developing mitigation strategies is used in the method. Use of the method may result in a system that causes less SoS damage during a failure event.
Full-text available
System of interest (SoI) failures can sometimes be traced to an unexpected behavior occurring within another system that is a member of the system of systems (SoS) with the SoI. This article presents a method for use when designing an SoI that helps to analyze an SoS for unexpected behaviors from existing SoS members during the SoI's conceptual functional modeling phase of system architecture. The concept of irrationality initiators—unanticipated or unexpected failure flows emitted from one system that adversely impact an SoI, which appear to be impossible or irrational to engineers developing the new system—is introduced and implemented in a quantitative risk analysis method. The method is implemented in the failure flow identification and propagation framework to yield a probability distribution of failure paths through an SoI in the SoS. An example of a network of autonomous vehicles operating in a partially denied environment is presented to demonstrate the method. The method presented in this paper allows practitioners to more easily identify potential failure paths and prioritize fixing vulnerabilities in an SoI during functional modeling when significant changes can still be made with minimal impact to cost and schedule.
Full-text available
This paper presents an approach to the utilization of model-based systems engineering (MBSE) early in the system lifecycle, which focuses on early identification of desirable system characteristics to support mission engineering (ME). The paper relies on the definition of an analysis approach and the associated mapping of architectural products. The analysis strategy focuses on integration of the results of operational simulations and system synthesis models through tradespace visualization. The architectural mapping presents the association of Systems Modeling Language (SysML) products to the analysis strategy. The coordination of these elements is presented as a demonstration of the role that MBSE concepts can play in support of ME. The approach is demonstrated through a case study analysis of a conceptual mine warfare system conducting mine countermeasure operations.
Full-text available
Computers are playing an increasingly important role in design and engineering. However, we currently lack a process for developing these computer tools, instead relying on expert experience and ad-hoc experimentation. In this thesis, we develop a design process for design automation, based on a study of the behavior of expert design automation practitioners. In addition to this process, the study finds several strategies used by those design automation practitioners, as well as the most common challenges faced in developing design automation tools. To validate the study, we apply the process to several engineering and design efforts, across the design process; we develop a tool to generate computer-aided mind maps for ideation, we develop a simulator and design exploration tool for rocket engine fuel grains, and we reduce the amount of physical testing necessary to develop novel wheg designs for a climbing microrobot. Finally, to address one of the major challenges facing design automation found in our study, we develop a tool to convert unstructured engineering component data into a structured, searchable form. Through all this, we show the potential for our design process for design automation to significantly, positively impact the design process.
Conference Paper
Full-text available
We propose mission engineering and analysis to examine and develop viable solutions for complex issues. Systems engineering addresses technological and managerial challenges in the design and development of physical and virtual systems. The military decision making process is a recognized method to develop a mission plan. The structure of mission engineering and analysis establishes the military planning process as its backbone, while systems engineering techniques serve as the internal controls and mechanisms. Scenario methodologies, modeling and simulation, hierarchical and value-focused thinking are systems engineering tools that shape the system of interest. This paper explains our ideas for creating a robust framework for tackling multidimensional problems. Mission engineering and analysis offers a holistic view of a system's development as part of a larger system. It begins with the combat mission that the system would support and ends with the system's integration in the operational unit that would apply it to achieve the mission. The process treats the system acquisition process as a subsystem. Previous methods have seen the operational mission as a start point. We designate the mission and mission plan, which may include weapon system development, as the complete system of interest. In doing so, we seek to deliver more robust and capable military and non-military systems. A notional implementation of mission engineering and analysis to assist fledgling countries conceptualize and develop solutions for border security issues captures the ideas presented in the paper.
This research applies a mission engineering approach with model‐based systems engineering foundations to formalize a swarm unmanned system design methodology and architecture. The architectural framework and methodology herein presented extend current swarm system design methods, which are primarily bottom‐up approaches focused on the behavior of individual agents. We introduce a top‐down, hierarchical approach with an overarching mission decomposed into phases, tactics, plays, and algorithms. Three unmanned aerial vehicle swarm case studies (one of which is discussed in this paper) are used to demonstrate the approach and its effectiveness in formalizing a mission‐based framework of common patterns in swarm missions that promote architecture reusability.
In the context of Probabilistic Safety Analysis (PSA) of nuclear power plants (NPP), external events are defined as events originating from outside the plant, but with the potential to create a PSA initiating event at the plant.
Discover the emerging science and engineering of System of Systems. Many challenges of the twenty-first century, such as fossil fuel energy resources, require a new approach. The emergence of System of Systems (SoS) and System of Systems Engineering (SoSE) presents engineers and professionals with the potential for solving many of the challenges facing our world today. This groundbreaking book brings together the viewpoints of key global players in the field to not only define these challenges, but to provide possible solutions. Each chapter has been contributed by an international expert, and topics covered include modeling, simulation, architecture, the emergence of SoS and SoSE, net-centricity, standards, management, and optimization, with various applications to defense, transportation, energy, the environment, healthcare, service industry, aerospace, robotics, infrastructure, and information technology. The book has been complemented with several case studies-Space Exploration, Future Energy Resources, Commercial Airlines Maintenance, Manufacturing Sector, Service Sector, Intelligent Transportation, Future Combat Missions, Global Earth Observation System of Systems project, and many more-to give readers an understanding of the real-world applications of this relatively new technology. System of Systems Engineering is an indispensable resource for aerospace and defense engineers and professionals in related fields.
Aggregate nuclear plant failure data is used to produce generic common-cause factors that are specifically for use in the common-cause failure models of NUREG/CR-5485. Furthermore, the models presented in NUREG/CR-5485 are specifically designed to incorporate two significantly distinct assumptions about the methods of surveillance testing from whence this aggregate failure data came. What are the implications of using these NUREG generic factors to model the common-cause failures of aerospace systems? Herein, the implications of using the NUREG generic factors in the modeling of aerospace systems are investigated in detail and strong recommendations for modeling the common-cause failures of aerospace systems are given.