ArticlePDF Available

Conceptual design of sacrificial sub-systems: failure flow decision functions


Abstract and Figures

This paper presents a method to conceptually model sacrificing non-critical sub-systems, or components, in a failure scenario to protect critical system functionality through a functional failure modeling technique. Understanding the potential benefits and drawbacks of choosing how a failure is directed in a system away from critical sub-systems and toward sub-systems that can be sacrificed to maintain core functionality can help system designers to design systems that are more likely to complete primary mission objectives despite failure events. Functional modeling techniques are often used during the early stage of conceptual design for complex systems to provide a better understanding of system architecture. A family of methods exists that focuses on the modeling of failure initiation and propagation within a functional model of a system. Modeling failure flow provides an opportunity to understand system failure propagation and inform system design iteration for improved survivability and robustness. Currently, the ability to model failure flow decision-making is missing from the family of function failure and flow methodologies. The failure flow decision function (FFDF) methodology presented in this paper enables system designers to model failure flow decision-making problems where functions and flows that are critical to system operation are protected through the sacrifice of less critical functions and flow exports. The sacrifice of less critical system functions and flows allows for mission critical functionality to be preserved, leading to a higher rate of mission objective completion. An example of FFDF application in a physical design is a non-critical peripheral piece of electrical hardware being sacrificed during an electrical surge condition to protect critical electronics necessary for the core functionality of the system. In this paper, a case study of the FFDF method is presented based on a Sojourner class Mars Exploration Rover (MER) platform.
This content is subject to copyright. Terms and conditions apply.
Ada-Rhodes Short2, Ann D. Lai2, Douglas L. Van Bossuyt2
This research was partially supported by United States Nuclear Regulatory Commission
Grant Number NRC-HQ-84-14-G-0047. Any opinions or findings of this work are the
responsibility of the authors, and do not necessarily reflect the views of the sponsors or
collaborators. The authors wish to acknowledge the work of the undergraduate research
assistants in the Van Bossuyt lab and specifically wish to thank the following students for their
contributions: Alexis Humann, David Hodge, Zachary Mimlitz, and Robin Coleman. The
authors wish to thank LeVar Burton, Fred Rogers, Gene Roddenberry, Carl Sagan, and their
individual middle school and high school science and technical arts teachers who inspired them
to pursue careers in the sciences and engineering, and instilled in them a sense of purpose and
This paper presents a method to conceptually model sacrificing non-critical subsystems,
or components, in a failure scenario to protect critical system functionality through a functional
failure modeling technique. Understanding the potential benefits and drawbacks of choosing
how a failure is directed in a system away from critical subsystems and toward subsystems that
can be sacrificed to maintain core functionality can help system designers to design systems that
are more likely to complete primary mission objectives despite failure events. Functional
modelling techniques are often used during the early stage of conceptual design for complex
systems to provide a better understanding of system architecture. A family of methods exists that
focuses on the modelling of failure initiation and propagation within a functional model of a
system. Modelling failure flow provides an opportunity to understand system failure propagation
and inform system design iteration for improved survivability and robustness. Currently, the
1 A version of this paper appeared in the ICED2015 conference where it was recognized as a Reviewers’
2 Department of Mechanical Engineering, Colorado School of Mines, Golden, Colorado, United States of
Page 1 of 35
ability to model failure flow decision making is missing from the family of function failure and
flow methodologies. The Failure Flow Decision Function (FFDF) methodology presented in this
paper enables system designers to model failure flow decision making problems where functions
and flows that are critical to system operation are protected through the sacrifice of less critical
functions and flow exports. The sacrifice of less critical system functions and flows allows for
mission critical functionality to be preserved, leading to a higher rate of mission objective
completion. An example FFDF application in a physical design is a non-critical peripheral piece
of electrical hardware being sacrificed during an electrical surge condition to protect critical
electronics necessary for the core functionality of the system. In this paper, a case study of the
FFDF method is presented based on a Sojourner class Mars Exploration Rover (MER) platform.
Key Words: Functional Modelling, Failure Modelling, Failure Flow Decision-Making, Design
1 Introduction
Complex systems such as Mars Exploration Rovers (MERs) or airborne, aquatic, or
terrestrial autonomous vehicles often operate in hazardous environments in which servicing or
repairing damaged or broken hardware is infeasible or impossible due to high costs, isolation of
the environment, or extreme conditions leading to loss before opportunity for repair. Low-cost
systems such as hobby aerial drones or aquatic Remote Operated Vehicles (ROVs) can be
replaced easily, but unique and expensive systems such as a MER are difficult and time- and
resource-consuming to replace when the system fails. Therefore, it is critical to deploy systems
capable of surviving in their operating environments and accomplishing the mission over the
intended duration. Significant attention is often given to understanding system failure risk and
mitigation of potential failures during system design, but risk analysis often occurs after major
system architecture decisions have been made and the system design has already progressed to a
point in which system design changes are prohibitively costly and time-consuming. Performance
of risk analysis in the early conceptual stage of the design process before major architectural
decisions are made can contribute to system designs that have a higher probability of surviving
the intended mission without failure, without costly design changes, and without compromising
other aspects of the design or mission.
Page 2 of 35
In the past two decades, a variety of work has been performed to analyze the risk of
system failure during operation at the conceptual stage of design. NASA’s Team-X (“JPL Team
X” 2016) and other groups have developed methods for assessing risk of system failure at the
conceptual stage of mission design through trade-off studies for risk analysis. Other groups have
focused on the development of functional system modeling to assess risk of failure (Kurtoglu and
Tumer 2008). Functional modelling has become a useful tool for conceptual system design and
has been used to simulate a system’s response to an environment (Short and Van Bossuyt
2015b). Multiple methods have been developed in the last decade to analyze risk of system
failure using functional models (Kurtoglu and Tumer 2007; Jensen, Tumer, and Kurtoglu 2009;
Kurtoglu and Tumer 2008).
This paper presents the Failure Flow Decision Function (FFDF) method that provides
insight into decisions when designing or operating systems facing failure. FFDF uses the Failure
Flow Identification Propagation (FFIP) (Kurtoglu and Tumer 2008) method and Flow State
Logic (FSL) (Jensen, Tumer, and Kurtoglu 2009) to perform system failure analysis on a
functional model, allowing FFDF to determine what sub-system failures are more likely to cause
critical system failure. FFDF builds upon the foundation of the Functional Basis for Engineering
Design (FBED) (Stone and Wood 2000) as a convention for the representation of functional
models of systems and proposes the addition of the Direct Failure function to the FBED lexicon.
The Direct Failure function is representative of systems that allow for an action to be taken by a
system that mitigates critical system failure through the sacrifice of sub-systems that are less
critical to total mission success. An example of a Direct Failure function realized in physical
components is a circuit that directs electrical surges to particular systems, a flood routing system
downstream of a reservoir, or components that allow for a system to reorient itself to incur a
physical impact in the safest way possible. A second example is a humanoid robot designed to
carry a payload that is deemed critical to the robot’s function up and down stairs; if the robot
falls it may stick out an arm to protect the payload. Acting increases the probability of damaging
an arm, but reduces the probability of damaging the payload. Directed Failure functions can
describe a wide variety of systems used in autonomy to mitigate failure. FFDF has applications
in the design of more robust systems for operation in hazardous environments as well as the
ability to inform control and operation of autonomous systems (Short and Van Bossuyt 2015b;
Page 3 of 35
Short, Mimlitz, and Van Bossuyt 2016; Short, Mimlitz, and Van Bossuyt 2016; Mimlitz, Short,
and Van Bossuyt 2016).
1.1 Specific Contributions
This paper proposes a method for the analysis of system survivability informed by
functional modelling. FFDF allows for rapid analysis of a system for survivability at the
conceptual stage prior to making large architectural decisions. The result of FFDF is a set of
values representing the criticality of individual components to system survivability that is used to
inform the sacrifice of sub-systems when necessary during a failure scenario for the improved
survivability of the system. When applied to autonomous systems such as exploratory rovers,
FFDF can improve survivability by informing which functions can be sacrificed if necessary for
system survival. The work also lays the groundwork to building more complex autonomous
systems by providing an informed basis for decision making when facing failure.
2 Background
The FFDF method builds upon foundational work from several related fields including
decision theory, failure analysis methods, and system and functional modelling. This section
discusses topics pertinent to the understanding and implementation of FFDF.
2.1 System and Functional Modeling
System and functional modeling refers to a suite of tools and methods for conceptualizing
complex systems and their functionality with a wide variety of applications for analysis and
system design. Several established methods perform system modelling through the definition of
functions and flows in a system, where a function represents a process performed by the system
or sub-systems and flows represent energy, materials, or information passed between and worked
on by the functions; additionally, there are import and export flows that enter or exit the system
boundary. Several common techniques used in systems engineering applications include
Functional Flow Block Diagrams (FFDB) (Lightsey 2001; Blanchard and Fabrycky 1990),
Enhanced Function Flow Block Diagrams (EFFBDs) (Long 2002; David, Idasiak, and Kratz
2010), Integrated Computer Aided Manufacturing (ICAM) DEFinition for Function Modeling
(IDEF0) (Force 1981), Systems Modeling Language (SysML) (Huang, Ramamurthy, and
McGinnis 2007), and Functional Basis for Engineering Design (FBED) (Hirtz et al. 2002; Stone
and Wood 2000). The FFBD method is useful for modeling systems in which there are direct
Page 4 of 35
linear flows passed between functions and a clear input and output exists for the system.
However, FFBD is limited in its ability to model systems with more complex flow paths, which
makes it difficult to accurately represent the system. EFFBD takes an alternative approach that
instead models the behavior and physical properties of a system via the passing of states and
information. EFFBD implements this approach through modelling mechanical and control
system behavior. While EFFBD can offer benefits for system design and development of
controls, EFFBD is limited as a platform for performing analysis of system health resulting from
the lack of inclusion of sub-systems for monitoring system health. SysML is a flexible form of
Unified Modeling Language (UML) (Rumbaugh, Jacobson, and Booch 2004) that is specific to
system engineering. While SysML is used extensively for certain aerospace applications, its rigid
rules set provides a significant barrier to adoption and little work has been done to analyze risk in
the conceptual stage of design. FBED uses an established lexicon (Hirtz et al. 2002) to represent
functions and flows, can be used to develop models of most engineered electrical and mechanical
systems, and is particularly well-suited to modeling systems in the conceptual stage of design.
For example using the FBED lexicon a battery could be represented by a Store Energy function
with an Electrical Energy flow connecting the battery to powered systems. A more complex
example is a drive train for an electrical vehicle, in which a motor control board delivers power
to electrical motors, which go into gear boxes, which in-turn drives wheels. This system could be
represented by a Control Magnitude Electrical function importing Digital Signal and Electrical
Energy flows and exporting Electrical Energy flows into Convert Electrical-to-Rotational Energy
functions representing the motors. A Rotational Work flow leaving the Convert Electrical-to-
Rotational Energy function enters a Transmit Rotation function representing the gearbox, which
exports a modified Rotational Work flow. Finally the Rotational Work flow enters a Convert
Rotation-to-Translation representing a wheel and then exports Translational Work.
The work presented in this paper uses FBED for functional modelling which was selected
over other methods because of its ability to represent a wide variety of complex systems, with a
myriad of available failure analysis methods, the well-developed conventions and practices,
existing functional component design repositories, and the support of FBED by the National
Institute of Standards and Technology (NIST) (Bohm, Stone, and Szykman 2005; Materese
2002). The FBED lexicon was established after extensive study by Stone and Wood and
Page 5 of 35
consolidated previous functional model lexicons into a single standard (Hirtz et al. 2002; Stone
and Wood 2000).
Surveying the existing work on the generation of functional models, two common
approaches exist, the first of which involves the development of a model to represent an existing
system through functional decomposition (van Eck, McAdams, and Vermaas 2007). In
functional decomposition, the system is decomposed into component sub-systems and the
functionality of each sub-system is then determined. Sub-system functionality can be represented
as function blocks and flow paths, and a model can be developed. Functional decomposition is
common when developing models of existing systems for the purpose of analysis. The second
common approach generates functional models from the desired functionality of a system with
no existing physical system design. Under this approach, desired system import and export flows
are often determined and modelled as passing through an unknown “black box”. Necessary sub-
systems are then defined to represent processes necessary to achieve the desired export flow and
functionality, and functions can then be selected to represent the sub-systems. The developed
functional model is then used to design the physical system by selecting components that satisfy
functions (Bohm, Stone, and Szykman 2005; Stone and Wood 2000; Hirtz et al. 2002). Under
both approaches to functional modelling, analysis of the system can be performed through
various methods, and physical components can be selected in order to serve a defined functional
purpose in the system. This paper presents a case study of a functional model of a sojourner class
MER that is analyzed through FFDF for improved system survivability. While this work studied
a model developed through functional decomposition, FFDF can also be used on functional
models that were not based on existing systems.
2.2 Failure Analysis Methods
A variety of failure analysis methods are currently used in industry and academia.
Common methods include: Probabilistic Risk Assessment (PRA) (Kumamoto, Henley, and J
1996; Stone and Wood 2000) which is heavily used in aerospace, defense, and civilian nuclear
power; Reliability Block Diagrams (RBD) (Distefano and Puliafito 2007) which determine
system reliability by modelling parallel and serial failure flow paths through blocks containing
statistical reliability data; Failure Modes and Effects Analysis (FMEA) (Mohr 2002) which has
been used across a broad spectrum of industries since its development in the 1950s for military
Page 6 of 35
applications; and Fault Tree Analysis (FTA) (Ericson 1999) which was developed by Bell Labs
in the 1960s for analysis of aerospace systems. While PRA, RBD, FMEA, and FTA provide a
good foundation for analysis, they are limited in their ability to model failure, generate practical
models, and be implemented. Several methods have been developed for failure analysis of FBED
models (Stone and Wood 2000). Function-based Analysis of Critical Events (FACE) (Hutcheson
et al. 2006) enables designers to modify functional models informed by critical events during a
complex system’s lifecycle. The Function Failure Design Method (FFDM) (Stone, Tumer, and
Van Wie 2005) melds FMEA and FBED in order to create a method for selecting functions and
component solutions informed by past, collected, or historical failure data. Function Failure
Identification Propagation (FFIP) (Kurtoglu and Tumer 2008; Kurtoglu and Tumer 2007) models
the flow of failure through FBED-based functional models as it passes between functions along
flow paths. Function Failure Reasoning (FFR) (Kurtoglu, Tumer, and Jensen 2010) provides a
simulation tool for modelling FFIP in a complex system. The Flow State Logic (FSL) (Jensen,
Tumer, and Kurtoglu 2009) method refines FFIP and provides a representation of the analyzed
system’s complete failure state. The Uncoupled Failure Flow State Reasoner (UFFSR)
(O’Halloran, Papakonstantinou, and Van Bossuyt 2015) method improves on FFIP by including
analysis of failures that do not propagate along nominal flow paths but rather through physical
space between functions. Similarly to FFIP, Functional Dependency Network Analysis (FDNA)
expands upon FMEA to anaylze complex systems, systems of systems, and enterprise systems
(Garvey and Pinto 2009; Garvey, Pinto, and Santos 2014). FDNA builds on Inoperability Input-
Output Models (IIM) (Haimes et al. 2005), Design Structure Matrices (DSM) (Browning 2001),
Leontief Systems, and FMEA, and uses directed graphs consisting of nodes representing
capabilities (similar to functions described above) and edges representing dependencies between
modes. While FDNA analyzes unidirectional systems such supply chains or other enterprise
systems, FDNA is limited in its ability to analyze systems in which failures can propagate
against the flow of input-output relationships, a restriction not shared by FFIP. System
Operational Dependency Analysis (SODA) (Guariniello and DeLaurentis 2017) improves upon
FDNA by considering the internal status of systems and better accounts for stochasticity. Despite
its benefits in efficiency of analysis and ability to support decision making, SODA takes a
similar approach to FDNA regarding failure propagation; neither method has an ability to
account for failures that propagate backwards against the direction of dependency. An advantage
Page 7 of 35
of SODA and FDNA over FFIP-based methods is that they consider non-binary failure states and
can express operability of nodes on a scale from 0 to 100. The ability to express nuanced levels
of operability is very helpful for systems that are repairable or can undergo scheduled
maintenance, but becomes trivial in the case of remote systems that cannot be repaired such as
those considered in this paper. While significant progress has been made in the past decade,
many areas still need to be addressed and further development of existing methods is needed.
2.3 Hazard Rate Estimation and Success Assessment
A common method for analyzing the likelihood of a system surviving a desired mission is
calculating the system’s hazard rate. A hazard rate
is a probabilistic representation of expected
system failures over a unit of time. Estimation of risk using a hazard rate is commonly performed
using an exponential distribution (Wertz, Everett, and Puschell 2011a) to evaluate the expected
survivability rate
at time
, as seen in Equation 1.
From the expected survival rate in Equation 1, the expected failure rate
can be found
through subtraction of
from 1 as shown in Equation 2.
Under this convention, the survivability rate
is the probability that a system with hazard
will still be functional at time
. Similarly, the failure rate
describes the probability that a
system will have failed by time
. Modelling survival and failure rates is critical to the
construction of a mathematical representation of failure in a functional model.
The FFDF method builds upon a foundation of system and functional modelling, failure
analysis, hazard rate estimation, and decision theory. FFDF applies these concepts to enable
informed decision making when facing failure, and enhances the effectiveness of system
physical and control design.
3 Methodology
The Failure Flow Decision Function (FFDF) method presented in this paper is a tool that
performs failure analysis on a functional model in order to inform failure flow routing decisions
in the operation of a system for reduced probability of system failure over the duration of a
Page 8 of 35
mission. FFDF consists of eight steps separated into three distinct phases: Phase 1) Generation of
the functional model, Phase 2) Performance of failure flow analysis, and Phase 3) Interpretation
of results. Figure 1 shows the eight steps of FFDF. The FFDF method starts with the creation of
a functional representation of a system of interest using the FBED lexicon (Steps 1-4 in Phase 1).
Analysis is then performed on the developed functional model in order to determine the
probability that the failure of an individual function leads to failure of a critical function (Steps
5-6 in Phase 2). The results of the analysis can then be interpreted and a Direct Failure function
can be inserted into the functional model in the optimal position for system survivability (Steps
7-8 in Phase 3). FFDF is aimed towards the early conceptual stage of system design and allows
for the design and operation of systems that are particularly adept at operation in environments
where repairs are impractical or impossible.
Phase 1: Generate Functional Model
Step 1: Develop Functional Model
The first step of FFDF is the generation of a functional model of the system of interest.
The FBED lexicon can be used (Hirtz et al. 2002). The process begins by defining high-level
functions to represent all major functionality of the system being modelled. The functions are
then connected with flows, as shown in Figure 2, where thick solid lines represent the passing of
physical material, thin solid lines represent the passing of energy such as electricity or heat, and
dotted lines represent the passing of information or signals between functions. Figure 2
represents a simplified functional model of a Sojourner class MER. A more complex functional
model of a Sojourner class MER used in the case study is shown in Appendix 1.
Page 9 of 35
Page 10 of 35
Begin FFDF
Generate Model Funcon Flow Block Diagram
Dene Crical Funcons and Flows
Assign Failure Propagaon Probabilies
Convert Funconal Model into Mathemac
Find All Flow Paths
Calculate System Crical Failure Probability
from Iniang Events
Conclude FFDF
Analyze Results
Place FFDF Direct Failure Funcon
Step 2: Define Critical Functions and Flows
The second step of the FFDF method is the identification of critical flows and functions
in the system of interest. Previous works define critical functions as a set of design functions that
significantly represent the functionality of a system of interest (Lucero et al. 2014). FFDF uses a
modified definition in which critical functions are elements of the functional model that must
perform their intended function. There are two major classes of critical functions allowing for
numerical and probability analysis of the functional model: 1) independent critical functions
(ICFs), and 2)
critical functions (kNCFs).
Page 11 of 35
Record VisualProcess Signal Process Signal
Electric to
Rotaon to
Electric to
Electric to
Electric to
Rotaon to
Rotaon to
Rotaon to
 
Figure 2: Example of a simplified functional model of a Sojourner-based Mars Exploration
Rover. Boxes represent functions, thick lines represent material flows, thin lines represent
energy flows, and dotted lines represent signals or information.
ICFs are individual functions that, in a failure state, lead to loss of functionality in the
entire system. An example of an ICF for the case of a MER is the communications antenna
represented by a Transmit Data function. The loss of the Transmit Data function leads to the
MER losing the ability to communicate with Earth-based human operators, leading to the MER
no longer being able to operate, even if all other MER functions have not experienced failure.
Thus, Transmit Data is defined as a critical function of the MER.
kNCFs, the second class of critical functions, are sets of functions of size
in which any
subset of at least size
must be functioning nominally for a system to not be in a critical failure
state. An example of kNCFs in a MER are the three batteries represented by Store Energy
functions. The MER functional model has N=3 Store Energy functions, and it requires at least
Store Energy functions to be operating nominally in order for the system not to be in a
failure state. Typically, the set of critical functions for a functional model of a system will consist
of multiple kNCFs and ICFs.
Step 3: Assign Failure Probabilities
The third step in FFDF is assigning failure probabilities for each function and flow in the
functional model. This includes the probability of a function failing, of the failure passing along
a flow path, and that a function on the other end of the flow path will accept the failure. The use
of separate passing and accepting probabilities allow for the model to account for failures to
occur and attempt to propagate, but allow for scenarios where the failure propagation does not
affect the next function. For example a failure originating at a Distribute Electrical function and
propagating along an Electrical Energy flow will always have the same probability of passing
along that flow, but different functions have varying probabilities of accepting that failure. A
component level example of this would be the system response in to a momentary voltage drop
in an autonomous system. Driving motors are unlikely to be affected, but on board computers
may reset. The calculation of the probability of failure propagating along a specific flow path
using these values is described in Step 6.
Selecting appropriate probability values is one of the most critical steps in the
development of a system model that is representative of reality. Generic failure probabilities can
be sourced from texts and data sets appropriate to the system being modelled. For example, the
probabilities used in the MER case study presented in this paper are based on values derived
Page 12 of 35
from (Wertz, Everett, and Puschell 2011b), which contains data on Mars rovers and other space
systems, gathered experimentally from testing, or interpolated from similar systems already in
operation, such as from PRA analysis of conceptual designs of nuclear power facilities (Gosselin
The failure probabilities are then stored. This paper advocates storing failure probability
for efficient machine-searchability and expandability. Appendix 2 lists failure probabilities for
system flows and functions used in the case study presented in this paper.
Step 4: Convert Functional Model into a Mathematic Representation
Before the functional model can be analyzed, it needs to be converted from a graphical
representation that is human-readable to a machine-readable mathematical representation (Short
and Van Bossuyt 2015a; Papakonstantinou et al. 2012; Sen, Summers, and Mocko 2013). In
FFDF, functional models are represented as a cell array containing a string and two matrices.
The string lists the class of functions represented by the cell. The first matrix contains flows into
the function in the first column and the function at which the flow terminates in the second
column. The second matrix has the same structure as the first, but instead tracks flows out of the
function. This structure allows for the tracking of failure flow during the analysis phase of FFDF.
The cell array contains the entire functional model in a format that is machine-readable. An
example subsection of a functional model of a MER is displayed below in Model 1. In the model
f0-f8 refer to flow types, and the numbers refer to function block index values. A complete list of
the values can be found in Appendix 3.
Page 13 of 35
%& 
Phase 2: Design Iteration
Step 5: Define All Flow Paths for Machine Readability
One property of functional model analysis based in FFIP is that flow paths can propagate
failure along parallel paths as well as in the opposite direction to a flow’s nominal path. A
component-level example of a parallel failure is an over-voltage failure travelling along multiple
parallel wires to several electrical devices. A component-level example of failure flows
propagating in the reverse direction of a nominal flow path is a water hammer traveling through
plumbing. Properly modelling this behavior in a functional model is important to accurately
analyze system failure probabilities. For the purpose of FFDF, a functional model is best
represented as a specialized network of nodes. While this structure allows for the accurate
representation of a functional model, models with a small number of nodes can become very
complex due to the large number of paths between nodes. An interesting computational problem
arises from the increased complexity of the network representing the functional modelling as
many traditional methods for solving failure flow paths are impractical due to the large
computational resources needed.
The case study performed in this paper adopts a modified biased wall-following, maze-
solving algorithm (Yadav, Verma, and Mahanta 2012) to navigate the functional model, while
recording the path as it is traversed. The method is limited to taking only legal paths which is
defined as paths that are acyclic and stay within the system model boundary, without passing
through the operating environment in which the system is placed. In this implementation of
FFDF, the functions and all connecting paths are put into increasing numerical order
corresponding to their position in the functional model (see Step 4, Model 1 above). The lowest-
ordered legal function in the model is navigated to, along the lowest-valued path. A function can
be legally navigated to if it has not already been “visited” along the failure path, making all legal
paths acyclic. Only acyclic paths are considered for FFDF because the method applies to
unrepairable systems, where the first failure of a critical function is considered enough to fail the
entire system. Additionally, legal paths for most cases will be constricted to not include
travelling through the operating environment as this would involve the failure propagating
through space in a potentially uncoupled manner such as in the case of UFFSR analysis
(O’Halloran, Papakonstantinou, and Van Bossuyt 2015). This process is continued until no more
legal paths are available, at which point the whole path is recorded and the algorithm returns to
Page 14 of 35
the last function with a legal path that has not yet been navigated. This is repeated until no more
legal paths exist and all failure paths have been discovered.
The functional model flow path solving algorithm used here is computationally simple,
relatively fast, and enumerates all possible paths. Other techniques were attempted, such as using
a Monte Carlo method to generate paths through Bayesian sampling, but this was
computationally expensive in order to reach a comparable level of resolution (Short and Van
Bossuyt 2015a). Topological sorting was inapplicable due to inclusion of multidirectional flows
(Kalvin and Varol 1983). A brute force method which generates a list of all potential paths,
ignoring flow logic, and then checking them against the model for legality was feasible for small
models but required prohibitive quantities of computer memory for larger models due to factorial
growth of the memory required. Future work will explore quantifying and improving the
efficiency of the flow path solving algorithm. One potential drawback of this method is that it is
restricted to only acyclic failure paths and does not consider magnitude of failure. As a result, the
model does not address the potential for non-failure inducing loops developing in the system that
eventually lead to failure. While these cyclic paths are inherently less likely to occur than acyclic
paths, future work will attempt to identify and address them.
Page 15 of 35
Step 6: Calculate System Critical Failure Probability from Initiating Events
Calculating the system critical failure probability from initiating events determines how
the failure of each individual function in a system’s functional model can lead to critical system
failure through propagation of failure flows. For the purpose of the case study presented in this
paper, it is assumed that the initiating failure event has occurred and therefore the probability of
an initiating event failure is 1, representing a 100% chance of failure for ease of understanding
the FFDF method. In practice, initiating event probabilities are selected to reflect real-world
operating conditions of the system. The simplification allows for the paper to focus on the FFDF
method without digressing into the minutiae of an environmental model.
An algorithm, shown in the formulation section below, calculates system failure
probability for each failure flow path, starting with the selected initiating event. If a failure flow
path does not contain any critical functions, it is skipped and the next path is selected. For cases
in which the selected path contains an independent critical function, or ICF, the probability that
the ICF will experience failure
is calculated by taking the product of all probabilities of
occurrence for all previous events in the path. Each event along the path is defined by two
i,1, p f
i ,2
, which describes the probability of a function in position
in the flow
passes failure to the next function in the path, and
FAcc pf
i+1,1, pf
which describes the
probability that the function in position
of the path accepts a failure passed to it from the
previous function in the path. This calculation is performed for all ICFs in the failure flow path
and can be seen in Equation 3 of Formulation 1.
If there is a kNCF in the failure flow path, a different calculation is used. The algorithm
first calculates the probability of failure for every kNCF function in the path using the same
method for finding probability of an ICF occurring and records the value, noting the initiating
event. This value is then used to calculate the probability of failure for all kNCF sets for the
initiating event
. A mathematic representation of this process is shown in Equation 4 of
Formulation 1.
The probability for every ICF failure and kNCF failure is recorded for the flow path.
When all failure flow paths originating from an initiating event has been examined, the algorithm
Page 16 of 35
takes the sum of all critical failure probabilities for the initiating event. This allows the algorithm
to account for situations leading to critical failure and determine a total probability of critical
FCritFail ,
as shown in Equation 5. The algorithm then selects the a new initiating event to
analyze by determining the next function that can fail independently of other failure events; this
process repeats until all initiating events are accounted for. A formulation for calculating the
probability of total critical system failure for an initiating event is shown below in Formulation 1.
Chapter 1 Formulation 1:
Formulation of Critical System Failure
for initiating failure event
Here we provide the mathematical formulation for
, the probability of critical
system failure for a path.
Chapter 2 Formulation 1.1: Sets
Set of all types of
: Set of all function types in the functional model
: Set of independent critical functions
: Set of all function in
critical functions set of type
: Set of all flow types in the functional model
pi ,c P
: Set of all possible paths in the model, containing
flows and
denoting class.
The first row contains all functions in order along the length of the path, and the second row
contains all flows in order.
i ,c
Set of classes of elements in a path, containing functions
and flows
pf i ,c UPfP
: Set of all unique paths originating at function
and ending at an
Page 17 of 35
f i ,c
: A set of all paths originating from a function of interest for receiving
directed failure flows
Chapter 3 Formulation 1.2:
f =¿
The probability that the function f will pass a failure along path
FAccf =¿
The probability that function f will accept a failure passed along path
Chapter 4 Formulation 1.3:
If a flow path originating from a function
contains no ICFs of kNCFs, the probability of
critical system failure is given by.
f i ,c
f i , c
If a flow path originating from a function
contains an ICF, then the probability of
critical system failure is given by
f ,i , c
i 1, p
f i , c
fi ,c
f i,f
, p
f i,φ
fi+1, f
, p
f i,φ
The probability of failure from kNCFs must be calculated for all paths containing kNCFs
originating from function
at once, and is given by,
f i ,c
i 1, p
f i ,c
The combined probability of failure for all paths originating from a function
is given by
fi ,c
The value of
is in terms of Probability of Survival on Demand (PSD), which is the
probability that a system will survive a failure event.
Steps 5 and 6 currently present the best practice as determined by the authors at this time.
However, alternative methods exist for implementation of these steps including those discussed
in Step 5 above.
Page 18 of 35
Phase 3: Interpret and Report Results
Step 7: Analyze and Interpret Results
It is important to properly interpret the results of the failure flow analysis in order to
choose the most effective Direct Failure functions to improve system survivability. From the
analysis performed in Step 6, functions that are less critical to system survivability have the
lowest probability of critical system failure
. These functions are where failure should be
directed; however, it is important to verify that the
values make sense for the system.
Due to the complexity of large functional models, errors could be made in either the initial
functional model developed in Step 1, the selection of critical functions for the system in Step 2,
or the assignment of failure probabilities in Step 3. Some potential errors to be mindful of are
ICFs that do not have a
value of 1, seemingly unimportant functions with very high
probabilities (which can occur in many systems and may not be erroneous), and identical
functions that have different probabilities of failure. Additionally, it is important to understand
that in large complex systems, emergent behaviors are likely to surface, and determining why
these behaviors arise is very important to improved survivability.
In addition to determining the probability of critical failure associated with a function, it
is important to consider what classes of failure flows can be directed to a particular function. For
example, an impact from a falling rock is difficult or impossible to direct towards an internal
system component.
Step 8: Place FFDF Direct Failure Function
Using the insight gained in Step 7, Direct Failure functions can now be inserted into the
functional model as desired. The Direct Failure function intercepts a failure flowing through the
system and directs it towards the desired sacrificial subsystem of interest, as shown in Appendix
4. Similarly to the initial development of the functional model, it is important to consider the
required model fidelity of the Direct Failure function, the interaction between the system and the
environment, and the limitations of directing failure to certain functions (e.g., a pressure vessel
cannot easily receive an electrical failure flow).
The FFDF method can be applied to a wide variety of systems to improve survival by
informing failure flow routing decisions. Survival of systems is often highly dependent on the
Page 19 of 35
health of a few functions that are more closely linked to critical system functionality, and by
using FFDF, sub-systems can be found that are sacrificial with minimal effect on system
4 Case Study
In this section, a case study is performed in which a functional model of a Sojourner class
MER (“Sojourner Rover Home Page” 2015) is modelled and analyzed using the FFDF method.
Step 1: Develop Functional Model
A functional model consisting of 50 functions and based on a Sojourner class MER is
developed. A total of 14 types of functions are used in the model. Table 1 shows a list of the sub-
systems represented in the functional model and representative functions. Appendix 1 shows the
complete functional model.
The case study functional model is a simplified version of a Sojourner class Mars Rover
and is complex enough to demonstrate FFDF while being simple enough to be easily
understandable. The case study model is a more complex version of a MER model used in
previous works (Short and Van Bossuyt 2015b; Short, Mimlitz, and Van Bossuyt 2016; Short
and Van Bossuyt 2015a).
Page 20 of 35
Table 1: Functions Used in Construction of the MER Functional Model
Sub-System Representave Funcon Quanty Used
  %'
 () '
 ( %
 * %
  * %
  '
   %
!  '
    %
$   %
 ( %
+ +#(  %,
$ "- .
+$ "- /
The current 50-function model was analyzed in approximately 10 minutes on a standard
laptop, but the scalability of the analysis was determined to be less dependent on the number of
functions than on the number of possible paths through the model. For example, a long chain of
functions in straight line would not significantly increase the power needed to solve the model,
but the same number of functions added with flows interconnecting each function could
significantly increase the power needed.
Step 2: Define Critical Functions and Flows
The functional model includes 7
critical functions (kNCFs) and 2 independent
critical functions (ICFs). The kNCFs include the Store Energy functions representing batteries,
Accumulate Energy functions representing the solar arrays, Record Visual functions representing
cameras, Store Data functions representing on-board memory, and Convert Rotation to
Translation functions representing wheels. These functions are selected to be kNCFs because
they represent capabilities of the MER that are necessary to perform its mission but possess
sufficient redundancies to allow for continued functionality with loss of some individual
functions. The two ICFs are the Process Signal function, representing the CPU, and the Transmit
Data function, representing the communication systems. These functions are chosen because if
either of them is lost, the rover will cease to operate or communicate with human controllers on
Step 3: Assign Failure Probabilities
Failure probabilities for this case study are sourced from Risk and Reliability in Space
Mission Engineering, The New SMAD (Wertz, Everett, and Puschell 2011b) and are
representative but were intentionally modified to differ from true failure data. Further, we
explicitly state that the failure probabilities and results of the analysis presented here, while
being useful for demonstration of FFDF, are not intended for use in any real systems.
Practitioners must develop their own system models and failure probability data for their specific
applications and cannot rely upon the data presented here. A complete list of the failure
probabilities used in this case study is shown in Appendix 2.
Step 4: Convert Functional Model into Mathematic Representation
The functional model is transformed from a graphical human-readable representation to a
mathematical machine-readable representation using the format described in Step 4 in the
Page 21 of 35
Methodology section. Converting a graphical functional model to a mathematical functional
model is currently achieved through a manual process and is labor intensive, but manual
conversion still allows for the relatively rapid generation of functional models compared to
previous work (Short and Van Bossuyt 2015a). In future work, an automated tool for conversion
back and forth between graphical and mathematical representations of functional models will be
Step 5: Define All Flow Paths for Machine Readability
All legal flow paths in the functional model are found using the functional model flow
path solving algorithm described in Step 5 of the methodology above. This algorithm is
computationally inexpensive and the software implementation used in this case study is able to
execute rapidly on large, complex functional models. In the MER model used for this case study,
1371 paths were found and analyzed.
Step 6: Calculate System Critical Failure Probability from Initiating Events
Critical system failures are calculated using the method described in Step 6 of the
methodology section. This is performed by first determining if a path contains an ICF or at least
k kNCFs of the same set. If a flow path meets either of these conditions, the probability of a
critical failure occurring is calculated using Equations 3 through 5. Using a relatively short path
generated in Step 5, a sample calculation is performed, as shown in Eq. 8. In this case, the failure
initiates at a Store Energy function representing a battery. Potential causes of battery failure
could include overheating, a short across the battery, or mechanical failure due to physical
impact. The Store Energy function failure propagates to the Distribute Electricity function
representing a power control board, which accepts the failure, which is then passed to a Direct
Command function representing a part of the primary computer. Finally, the failure is passed to
the Process Signal function representing the computer’s processor and the rover experiences
critical failure. Using Eq. 3 values shown in Appendix 2, the calculation is performed and shown
as a result of Eq. 8.
fi , j
fi ,f
, p
f i,φ
fi+1, f
, p
This individual path has a low probability of occurrence, but when combined with the
other 1371 paths, the probability of system failure can become significant. In the example shown
Page 22 of 35
in Eq. 8, only downstream failure flow paths were used; however, failure can propagate both
downstream and upstream. Appendix 2 shows the associated probabilities for upstream and
downstream failure propagation.
Step 7: Analyze and Interpret Results
After the functional model has been analyzed to determine which functions are likely to
lead to critical system failure, the results are then checked and interpreted for design insights. For
this case study, spot checks were performed in order to ensure that the analysis was properly
carried out.
Step 8: Place FFDF Direct Failure Function
The Direct Failure functions are then placed in locations that most improve the
probability of system survival when informing failure flow routing decisions. Additionally, it is
important that the incoming failure flow be directed to a function that can accept the failure flow.
For the case study presented in this paper, an electrical surge is considered and can be directed to
systems that have electrical energy flows.
5 Results
The case study presented above demonstrates the capability of FFDF to improve the
survivability of systems. Table 2 presents the Probability of Survival on Demand (PSD) for each
function and the quantity of the function available. Some function types are listed multiple times,
but with varying quantities and different PSD values, such as Convert Electrical to Rotational. In
these cases, the same type of function appears in multiple contexts within the functional model.
For the case of an electrical surge in the system that must be routed into a sacrificial
function, the optimal function to direct failure toward was found to be one of the two Convert
Rotation-to-Translation functions representing the center unsteered wheels in the rocker-bogie
suspension of the MER. Over the course of the mission, directing failure to one of the two
Convert Rotation to Translation functions results in a PSD of 0.1520, or approximately 15%. If
no failure is directed, it can be assumed that the failure is randomly assigned to a function
uniformly; under this class of undirected failure, the PSD is 0.1151. The worst-case scenario is
directing the failure to one of the independent critical functions (ICFs), such as the Process
Signal function, resulting in a PSD of 0. It is therefore recommended that a Direct Failure
function be placed to intercept the failure flow representing an electrical surge and direct it to
Page 23 of 35
one of the previously described Convert Rotation to Translation functions. This results in an
approximately 4% increase in system survivability over the length of the mission.
Another function towards which it is advantageous to direct failure is one of the thirteen
Collect Energy Solar functions each of which have a PSD of 0.1498. While these functions have
a slightly lower probability of system survival when sacrificed, there are significantly more
available in the system signifying that several can be sacrificed over the length of the mission if
necessary. One drawback of this is that the Collect Energy Solar functions are kNCFs, so if too
many fail, the MER will no longer be able to function. This is why the Collect Energy Solar
function’s PSD value is as low as it is despite the high level of system redundancy.
Table 2: Results of FFDF Analysis through FFIP shown in Probability of Survival on Demand
(PSD), with the highest PSD sacrificial function bolded.
Funcon PSD Quanity
  ,0%.12 %'
 ,0%.12 '
 ,0%3'3 %
 ,0%.// %
+% ,0,2/. 4
+3 ,0%.14 '
$% ,0,2/. '
$3 ,0%5,, %
+$% ,0,11, .
Convert Rotaon to Translaon 2 0.1520 2
 ,0,2/' %
 67 ,0,,,, %
  ,0,2/' %
 ,0,2/' '
 ,0,24% %
! ,0,22. '
$67 ,0,,,, %
* ,0%%5%
The Convert Rotation to Translation functions representing the steered wheels in the
rocker-bogie suspension has a PSD of 0.0990, which is almost half the PSD value of the
unsteered wheels. This appears to be a result of the fact that there are two flows connecting the
steered wheels to the rest of the system versus the singular flow for the unsteered wheels.
Page 24 of 35
Another observable behavior is that the more isolated a function is (in terms of both
number of flows connecting it to its neighbors and proximity to critical functions), the less likely
it is to lead to critical system failure. This holds logically, because if failure is propagating along
paths, failure flows that must take fewer and longer paths to propagate to a critical function will
be less likely to cause critical system failure. Related to this behavior is the seemingly counter-
intuitive behavior that a function with lots of parallel flows leading to it is more likely to fail.
Analysts might surmise that failure should be less likely to occur due to the apparent
redundancy; however, the opposite is true because the function is a bottleneck in the system with
a large number of potential paths for accepting failure, but with no redundancy of its own.
Additionally, if this system were to fail, the failure could propagate along many more flows,
leading to higher probability of critical function failure.
As a result of the heightened probability of system survivability from directed failure to
the Convert Rotation to Translation and Accumulate Energy Solar functions, it is recommended
the Direct Failure functions be placed into the system in order to direct failure to these functions.
Appendix 4 shows a graphical representation of this. As the mission length increases, survival
probability diminishes, but the disparity between directed and undirected failure increases due to
their different initial hazard rates.
6 Discussion
In the case study, FFDF is shown to be effective for improving the survival of a
Sojourner class Mars Exploration Rover (MER) by directing a failure flow representative of an
electrical surge into a Convert Rotation-to-Translation function representing an unsteered wheel.
As stated in the Results section above, the probability of survival can be increased from PSD
0.11 to 0.15 by directing failure to one of the two Convert Rotation-to-Translation functions or to
one of the thirteen Collect Energy Solar functions. While the Convert Rotation-to-Translation
function has a marginally better survivability at PSD 0.1520 compared to the 0.1498 of the
Collect Energy Solar function, it may be advantageous to direct the failure to the Collect Energy
Solar functions because there is more redundancy. While it will result in a slightly higher
probability of failure, 0.22%, there are more Collect Energy functions that can be sacrificed
before critical system failure occurs. One potential avenue of future work is the analysis of FFDF
where multiple failures occur over time and multiple Direct Failure functions are inserted in an
Page 25 of 35
effort to determine how the loss of a function and related functions can affect the loss of another
function and related functions later in the mission. Further discussion of this can be found in
Section 7.1.
The FFDF method can have positive impacts in many system design efforts in which
system failure or downtime is highly undesirable, including space exploration, transportation,
and power generation. For example, a power generation system design approached with FFDF
will be more reliable and have higher system up-time, which is important for power generation
contracts and grid load balancing. FFDF can also allow for rapid automated design and analysis
of an entire power grid, including functions for power generation, distribution, and regulation
with a focus on continuous and uninterrupted power.
7 Conclusion and Future Work
The FFDF method is effective for improving system survivability at the conceptual phase
of system design. FFDF presents a method that analyzes a conceptual system design to
determine the most desirable locations at which to place Direct Failure functions that route
failure flows to sacrificial subsystems or functions and away from critical functions. FFDF is
performed through the completion of three phases. The first phase encompasses the generation of
a functional model to represent a system of interest. This phase consists of actions that build on
existing functional modelling techniques, and proposes a convention for the development of
machine interpretable functional models for analysis. The second phase consists of analysis of
the functional model using FFIP and similar methods. The final phase consists of interpreting the
results of the analysis to determine where it is best to deliver system failure. The end result of
FFDF is deeper insight into how system failure can be prevented through protecting critical
system functions in the early conceptual phase of system design.
7.1 Future work
Future development of FFDF will involve improvement of the analysis software for
efficiency and usability. Specifically, the development of a user-friendly Graphical User
Interface (GUI) for the creation of functional models. In addition to making FFDF more
approachable to new users, the GUI will allow for the generation of a wide variety of functional
models through crowd sourcing. The shared models may then provide a basis for the
development and analysis of increasingly complex systems through FFDF and other related
Page 26 of 35
methods. Additionally, potential problems with scalability of highly interconnected functional
models could be addressed through a pre-solving technique that identifies sections that can be
simplified and reducing the effective size and complexity of the functional model prior to
One interesting potential application of FFDF is the design and analysis of individuals in
a swarm of robots designed to explore an unknown space 6$8##03,,.9:+0
3,%37. For this mission, the swarm could be modelled as a single system-of-systems. The
system-of-systems model could then be analyzed to determine how control and management
decisions of the swarm affect swarm health and capability. In this case, a relatively small
increase in individual survivability can lead to greater survivability of the swarm in its attempt to
complete a mission.
Finally, the implementation of user friendly and streamlined methods for inclusion of
FFDF into risk analysis techniques for decisions making such as Active Mission Success
Estimation is currently being pursued (Short and Van Bossuyt 2016). This will enable functional
models generated and analyzed through FFDF to be applied to the analysis of large and complex
mission scenarios such as space mission design or as a basis for development of autonomous
system behavior when facing risk.
Page 27 of 35
Appendix 1
Store Data
Store Data
Store Data
Electric to
Rotao n
Electric to
Rotao n
Electric to
Rotao n
Electric to
Rotao n
Electric to
Electric to
Collectable Energy
Electrical Energy
Digital Signal
Control Signal
Posion Informaon
Visual Informaon
Rotaonal Work
Translaon Work
Steering Work
Electric to
Rotao n
Electric to
Rotao n
Electric to
Rotao n
Electric to
Rotaon to
Rotao n to
Rotao n to
Rotaon to
Rotaon to
Rotao n to
Rotao n
Rotao n
Rotao n
Warm Electronics
Box Space
Page 28 of 35
Appendix 2
Flow Type
Probability of Passing
Failure Downstream
Probability of Passing
Failure Upstream
 ,0%, ,0,,
 ,0., ,0,3
  ,05, ,0,3
  ,05, ,0,3
 ,0.4 ,0,,
! ,0.4 ,0,,
"# ,05, ,0%5
$"# ,05, ,0%5
"# ,035 ,0%5
Probability of
Accepng Failure
 ,05,
 ,0%3
 ,03.
 ,03,
+ ,0%/
$ ,0%/
+$ ,0%/
 ,0..
  ,0,%
 ,0,%
 ,033
! ,033
$ ,0..
Page 29 of 35
Appendix 3
Index Flow Type
f1 
f2 
f3  
f4 
f5 !
f6 "#
f7 $"#
f8 "#
Index Funcon Type Index Funcon Type
% ;+ 3/ +<<4
3 % 34 +<<2
' 3 32 +<<1
. ' 31 +<<%,
5 . ', $%
/ 5 '% $3
4 / '3 $'
2 4 '' $.
1 2 '. +<<$%
%, 1 '5 +<<$3
%% %, '/ +<<$'
%3 %% '4 +<<$.
%' %3 '2 +<<$5
%. %' '1 +<<$/
%5 % ., 
%/ 3 .%  
%4 ' .3  67
%2  .' %
%1  .. 3
3, +<<% .5 '
3% +<<3 ./ 
33 +<<' .4 !%
3' +<<. .2 !3
3. +<<5 .1 !'
35 +<</ 5, $67
Page 30 of 35
Appendix 4
Store Data
Store Data
Store Data
Electric to
Electric to
Electric to
Electric to
Electric to
Electric to
Collectable Energy
Electrical Energy
Digital Signal
Control Signal
Posion Informao n
Visual Informaon
Rotaonal Work
Translaon Work
Steering Work
Failure Flow
Electric to
Electric to
Electric to
Electric to
Rotaon to
Rotaon to
Rotaon to
Rotaon to
Rotaon to
Rotaon to
Warm Electronics
Box Space
Direct Failure
Page 31 of 35
Blanchard, Benjamin S., and Walter J. Fabrycky. 1990. Systems Engineering and Analysis. Vol.
4. Prentice Hall Englewood Cliffs, New Jersey.
Bohm, Matt R., Robert B. Stone, and Simon Szykman. 2005. “Enhancing Virtual Product
Representations for Advanced Design Repository Systems.” Journal of Computing and
Information Science in Engineering 5 (4): 360–72.
Browning, Tyson R. 2001. “Applying the Design Structure Matrix to System Decomposition and
Integration Problems: A Review and New Directions.” IEEE TRANSACTIONS ON
David, Pierre, Vincent Idasiak, and Frederic Kratz. 2010. “Reliability Study of Complex
Physical Systems Using SysML.” Reliability Engineering & System Safety 95 (4): 431–
Distefano, Salvatore, and Antonio Puliafito. 2007. “Dynamic Reliability Block Diagrams:
Overview of a Methodology.” In ESREL, 7:1059–68.
Eck, Dingmar van, Daniel A. McAdams, and Pieter E. Vermaas. 2007. “Functional
Decomposition in Engineering: A Survey.” In ASME 2007 International Design
Engineering Technical Conferences and Computers and Information in Engineering
Conference, 227–36. American Society of Mechanical Engineers.
Ericson, C. 1999. Fault Tree Analysis–A History from the Proceeding of the 17th International
System Safety Conference. Orlando.
Force, US Air. 1981. “ICAM Architecture Part II, Vol. IV., Function Modelling Manual
(IDEF0).” AFWAL-TR-81-4023, OH: Wright-Patterson Air Force Base, USA.
Garvey, Paul R., and C. Ariel Pinto. 2009. “Introduction to Functional Dependency Network
Analysis.” In The MITRE Corporation and Old Dominion, Second International
Symposium on Engineering Systems, MIT, Cambridge, Massachusetts.
Garvey, Paul R., C. Ariel Pinto, and Joost Reyes Santos. 2014. “Modelling and Measuring the
Operability of Interdependent Systems and Systems of Systems: Advances in Methods
and Applications.” International Journal of System of Systems Engineering 5 (1): 1–24.
Gosselin, S. R. 2006. Probabilities of Failure and Uncertainty Estimate Information for Passive
Components: A Literature Review. Division of Fuel, Engineering, and Radiological
Research, Office of Nuclear Regulatory Research, US Nuclear Regulatory Commission.
Guariniello, Cesare, and Daniel DeLaurentis. 2017. “Supporting Design via the System
Operational Dependency Analysis Methodology.” Research in Engineering Design 28
(1): 53–69.
Haimes, Yacov Y., Barry M. Horowitz, James H. Lambert, Joost R. Santos, Chenyang Lian, and
Kenneth G. Crowther. 2005. “Inoperability Input-Output Model for Interdependent
Infrastructure Sectors. I: Theory and Methodology.” Journal of Infrastructure Systems 11
(2): 67–79.
Page 32 of 35
Hirtz, Julie, Robert B. Stone, Daniel A. McAdams, Simon Szykman, and Kristin L. Wood. 2002.
“A Functional Basis for Engineering Design: Reconciling and Evolving Previous
Efforts.” Research in Engineering Design 13 (2): 65–82.
Huang, Edward, Randeep Ramamurthy, and Leon F. McGinnis. 2007. “System and Simulation
Modeling Using SysML.” In Proceedings of the 39th Conference on Winter Simulation:
40 Years! The Best Is yet to Come, 796–803. IEEE Press.
Hutcheson, Ryan S., Daniel A. McAdams, Robert B. Stone, and Irem Y. Tumer. 2006. “A
Function-Based Methodology for Analyzing Critical Events.” In ASME 2006
International Design Engineering Technical Conferences and Computers and
Information in Engineering Conference, 1193–1204. American Society of Mechanical
Jensen, David, Irem Y. Tumer, and Tolga Kurtoglu. 2009. “Flow State Logic (FSL) for Analysis
of Failure Propagation in Early Design.” In ASME 2009 International Design
Engineering Technical Conferences and Computers and Information in Engineering
Conference, 1033–43. American Society of Mechanical Engineers.
“JPL Team X.” 2016. Accessed April 1.
Kalvin, Alan D, and Yaakov L Varol. 1983. “On the Generation of All Topological Sortings.”
Journal of Algorithms 4 (2): 150–62. doi:10.1016/0196-6774(83)90042-1.
Kumamoto, Hiromitsu, Henley, and Ernest J. 1996. Probabilistic Risk Assessment and
Management for Engineers and Scientists. Institute of Electrical & Electronics Engineers
(IEEE Press).
Kurtoglu, Tolga, and Irem Y. Tumer. 2007. “Ffip: A Framework for Early Assessment of
Functional Failures in Complex Systems.” In The International Conference on
Engineering Design, ICED. Vol. 7.
———. 2008. “A Graph-Based Fault Identification and Propagation Framework for Functional
Design of Complex Systems.” Journal of Mechanical Design 130 (5): 051401.
Kurtoglu, Tolga, Irem Y. Tumer, and David C. Jensen. 2010. “A Functional Failure Reasoning
Methodology for Evaluation of Conceptual System Architectures.” Research in
Engineering Design 21 (4): 209–34.
Lightsey, Bob. 2001. “Systems Engineering Fundamentals.” DTIC Document.
Long, Jim. 2002. “Relationships between Common Graphical Representations in Systems
Engineering.” Vitech White Paper, Vitech Corporation, Vienna, VA, 70.
Lucero, Briana, Vimal K. Viswanathan, Julie S. Linsey, and Cameron J. Turner. 2014.
“Identifying Critical Functions for Use across Engineering Design Domains.” Journal of
Mechanical Design 136 (12): 121101.
Materese, Robin. 2002. “A Functional Basis for Engineering Design: Reconciling and Evolving
Previous Efforts.” Text. NIST. February 1.
Mimlitz, Short, and Van Bossuyt. 2016. “Towards Risk-Informed Operation of Autonomous
Vehicles to Increase Resilience in Unknown and Dangerous Environments.” In ASME
Page 33 of 35
2016 International Design Engineering Technical Conferences and Computers and
Information in Engineering Conference.
Mohr, R. R. 2002. “Failure Modes and Effects Analysis.” JE Jacobs Sverdrup,.
Navarro, I&#xf1, aki, Mat&#xed, Fernando A, I&#xf1 Navarro, aki, Mat&#xed, and Fernando
A. 2012. “An Introduction to Swarm Robotics, An Introduction to Swarm Robotics.”
International Scholarly Research Notices, International Scholarly Research Notices
2013, 2013 (September): e608164. doi:10.5402/2013/608164, 10.5402/2013/608164.
O’Halloran, Bryan M., Nikolaos Papakonstantinou, and Douglas L. Van Bossuyt. 2015.
“Modeling of Function Failure Propagation across Uncoupled Systems.” In Reliability
and Maintainability Symposium (RAMS), 2015 Annual, 1–6. IEEE.
Papakonstantinou, Nikolaos, Seppo Sierla, David C. Jensen, and Irem Y. Tumer. 2012.
“Simulation of Interactions and Emergent Failure Behavior during Complex System
Design.” Journal of Computing and Information Science in Engineering 12 (3): 031007.
Rumbaugh, James, Ivar Jacobson, and Grady Booch. 2004. Unified Modeling Language
Reference Manual, The. Pearson Higher Education.
Sen, Chiradeep, Joshua D. Summers, and Gregory M. Mocko. 2013. “Physics-Based Reasoning
in Conceptual Design Using a Formal Representation of Function Structure Graphs.”
Journal of Computing and Information Science in Engineering 13 (1): 011008.
Short, Adam R., and Douglas L. Van Bossuyt. 2015a. “Rerouting Failure Flows Using Logic
Blocks in Functional Models for Improved System Robustness: Failure Flow Decision
Functions.” In International Conference on Engineering Design 2015.
Short, Mimlitz, and Van Bossuyt. 2016. “Autonomous System Design and Controls Design for
Operations in High Risk Environments.” In ASME 2016 International Design
Engineering Technical Conferences and Computers and Information in Engineering
Short, and Douglas L. Van Bossuyt. 2015b. “Risk Attitude Informed Route Planning in a
Simulated Planetary Rover.” In ASME 2015 International Design Engineering Technical
Conferences and Computers and Information in Engineering Conference,
V01BT02A048–V01BT02A048. American Society of Mechanical Engineers.
———. 2016. “Active Mission Success Estimation through PHM-Informed Probabilistic
Modelling.” Accessed March 4.
“Sojourner Rover Home Page.” 2015. Accessed December 15.
Stone, Robert B., Irem Y. Tumer, and Michael Van Wie. 2005. “The Function-Failure Design
Method.” Journal of Mechanical Design 127 (3): 397–407.
Stone, Robert B., and Kristin L. Wood. 2000. “Development of a Functional Basis for Design.”
Journal of Mechanical Design 122 (4): 359–70.
Truszkowski, Walt, Mike Hinchey, James Rash, and Christopher Rouff. 2004. “NASA’s Swarm
Missions: The Challenge of Building Autonomous Software.” IT Professional 6 (5): 47–
Page 34 of 35
Wertz, James Richard, David F. Everett, and Jeffery John Puschell. 2011a. “Risk and
Reliability.” In Space Mission Engineering: The New SMAD. Microcosm Press.
———. 2011b. Space Mission Engineering: The New SMAD. Microcosm Press.
Yadav, Sandeep, Kamal Kumar Verma, and Swetamadhab Mahanta. 2012. “The Maze Problem
Solved by Micro Mouse.” International Journal of Engineering and Advanced
Technology (IJEAT) ISSN, 2249–8958.
Page 35 of 35
... Approaches have subsequently been presented to use graph grammars to change the structure of the model, and/or use a cost-risk analysis scoring function to compare between design alternatives [143] [142]. Additionally, an approach has been presented for designing the operational decision-making in the model to determine when to, for example, route degraded flows to sacrificial subsystems [256]. While these approaches show many of the design changes that can be made within a functional model, and can be used to compare between design alternatives, they do not use this knowledge to formally optimize a design problem. ...
... model that make them difficult to optimize together. Consider the space of possible variables to explore shown in Table 5.1, which compiles newly-identified model variables with variables identified in previous function-based fault modelling and optimization approaches (see: [143,256,108,188]). ...
... Ability to represent differences in behaviors of functions. Conditional Logic [256] Predicting design cost of flexibility required to allow different decisions to be made. ...
It is desirable for complex engineered systems to perform missions efficiently and economically, even when these missions' complex, variable, long-term operational profiles make it likely for hazards to arise. It is thus important to design these systems to be resilient so that they will actively prevent and recover from hazards when they occur. To most effectively design a system to be resilient, the resilience of each design alternative should be quantified and valued so that it can be incorporated in the decision-making process. However, considering resilience in early design is challenging because resilience is a dynamic and stochastic property characterizing how the system performs over time in a set of unlikely-but-salient hazardous scenarios. Quantifying these properties thus requires a model to simulate the system's dynamic behavior and performance over the set of hazardous scenarios. Thus, to be able to incorporate resilience in the design process, there is a need to develop a framework which implements and integrates these models with design exploration and decision-making. This dissertation fulfills this need by defining resilience to enable fault simulations to be incorporated in decision-making, devising and implementing a modelling framework for early assessment of system resilience attributes, and exploring optimization architectures to efficiently structure the design exploration of resilience variables. Additionally, this dissertation provides a validity testing framework to determine when the resilient design process has been effective given the uncertainties present in the design problem. When each of these parts are used together, they comprise an overall framework that can be used to consider and incorporate system resilience in the early design process.
... 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]. ...
... Next, the results of the above analysis are reviewed to determine if the various failure scenarios and the severity of the outcomes (or risk if probability of occurrence data is available) are of sufficient concern to warrant additional safeguards, redundancies, defense in depth, diversity, mitigating functions [15,16], or other means of reducing or eliminating vulnerable parts of the system and SoS. A threshold value for severity should be established to help screen for the most concerning scenarios. ...
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.
... 1. Building for resilience -To plan and prepare for, absorb, respond to, and recover from disasters and adapt to new conditions (Ganin et al. 2016). 2. Multi-layered defense -To design a system to absorb or respond to threats using multiple layers of defensive barriers (Nunes-Vaz et al. 2011) 3. Sacrificial part -To design a system where functions and flows that are critical to system operation are protected through the sacrifice of less critical functions and flow exports (Short et al. 2018) 4. Evolutionary architecture -an approach to design and development that focuses on creating systems that can be easily changed and adapted over time (Ford et al. 2017) The second subcategory of structural strategies operate on social organizations rather than the physical system and prepare it for uncertainty. Examples of such strategies are: 1. Contingency planning -establishing thorough plans, procedures, and technical measures that can enable a system to be recovered as quickly and effectively as possible following a service disruption (Swanson et al. 2010) 2. Delegate or centralize control -improving the system by reassigning powers within the organization, e.g. ...
Full-text available
Uncertainty is a pervasive challenge in decision analysis, and decision theory recognizes two classes of solutions: probabilistic models and cognitive heuristics. However, engineers, public planners and other decision-makers instead use a third class of strategies that could be called RDOT (Risk-reducing Design and Operations Toolkit). These include incorporating robustness into designs, contingency planning, and others that do not fall into the categories of probabilistic models or cognitive heuristics. Moreover, identical strategies appear in several domains and disciplines, pointing to an important shared toolkit. The focus of this paper is to develop a catalog of such strategies and develop a framework for them. The paper finds more than 90 examples of such strategies falling into six broad categories and argues that they provide an efficient response to decision problems that are seemingly intractable due to high uncertainty. It then proposes a framework to incorporate them into decision theory using multi-objective optimization. Overall, RDOT represents an overlooked class of responses to uncertainty. Because RDOT strategies do not depend on accurate forecasting or estimation, they could be applied fruitfully to certain decision problems affected by high uncertainty and make them much more tractable.
... Short et al. [51] developed the failure flow decision function (FFDF) methodology to enable designers to model failure flow decision-making problems. The authors used the failure flow of information and failure propagation methodology to improve system survivability while aiding decision-making. ...
Full-text available
System reliability is treated as a parameter and not modeled in the early concept design stages. We illustrate a reliability model for system reliability in early concept design using knowledge from similar systems, technology readiness levels (TRL), and functional analysis methods using an unmanned ground vehicle. We integrate the reliability model with performance and cost models to demonstrate the impact of reliability in early concept design. The resultant tradespace comparison with and without early reliability assessment illustrates that reliability modeling can identify infeasible solutions in early system design. This will allow system designers to focus development on the most promising concept designs.
... 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.
... Refs [30,31] and Failure Modes and Effects Analysis (FMEA) methods [32]) and modelbased methods (in which the effects of a hazard are encoded in a model or simulation e.g., [33][34][35][36]). Decision-making approaches for early design methods also vary, with some approaches relying solely on the designer's judgement of the analysis [30,31] and others seeking to either optimize or satisfy constraints for modelled design metrics, such as reliability [34] or mission success probability [37]. Additionally, cost-based frameworks for risk consideration have been presented [38,39] to explicitly balance the risk-prevention of fault-mitigating features against their design and operational costs. ...
... This work has been extended is a variety of ways. 62 Krus and Grantham-Lough propose a method identify failure propagation through common interface; however, this method does not fully investigate failure propagation paths. 73 One overarching limitation of this body of research is that it lacks an approach to quantify failure propagation prior to components being selected. ...
Full-text available
An open area of research for complex, cyber‐physical systems is how to adequately support decision making using reliability and failure data early in the systems engineering process. Having meaningful reliability and failure data available early offers information to decision makers at a point in the design process where decisions have a high impact to cost ratio. When applied to conceptual system design, widely used methods such as probabilistic risk analysis (PRA) and failure modes effects and criticality analysis (FMECA) are limited by the availability of data and often rely on detailed representations of the system. Further, existing methods for system reliability and failure methods have not addressed failure propagation in conceptual system design prior to selecting candidate architectures. Consideration given to failure propagation primarily focuses on the basic representation where failures propagate forward. In order to address the shortcomings of existing reliability and failure methods, this paper presents the function failure propagation potential methodology (FFPPM) to formalize the types of failure propagation and quantify failure propagation potential for complex, cyber‐physical systems during the conceptual stage of system design. Graph theory is leveraged to model and quantify the connectedness of the functional block diagram (FBD) to develop the metrics used in FFPPM. The FFPPM metrics include (i) the summation of the reachability matrix, (ii) the summation of the number of paths between nodes (i.e., functions) i and j for all i and j, and (iii) the degree and degree distribution. In plain English, these metrics quantify the reachability between functions in the graph, the number of paths between functions, and the connectedness of each node. The FFPPM metrics can then be used to make candidate architecture selection decisions and be used as early indicators for risk. The unique contribution of this research is to quantify failure propagation potential during conceptual system design of complex, cyber‐physical systems prior to selecting candidate architectures. FFPPM has been demonstrated using the example of an emergency core cooling system (ECCS) system in a pressurized water reactor (PWR).
The continued growth of system complexity is challenging traditional qualitative, heuristics‐based approaches to architecting system emergence. As these emergent attributes are products of the architecture and established early in the system development lifecycle, where ambiguity is most pronounced, a shift to a model‐based approach is viewed as essential to understanding system interdependencies and the impacts of tradeoff decisions. This paper discusses how model‐based systems engineering methods and a coupled architecture‐simulation can be used to model system reliability. Employing a probabilistic model of system element failure, the coupled simulation is shown to predict system reliability for various architecture configurations early in the system design process. The advantages this quantitative system performance assessment provide to stakeholder decision‐making are reviewed, and the simulation model is extended to demonstrate how the complexity‐resilience tradeoff can impact system reliability.
This research focuses on developing models to estimate the system reliability of Unmanned Ground Vehicles using knowledge and data from similar systems. Reliability is often a stand‐alone requirement and not always fully included in performance and life cycle cost models. Traditional reliability approaches require detailed knowledge of a system and are used in later design sta ges as well as development, operational test and evaluation, and operations. The critical role of reliability and its impact on acquisition program performance, cost, and schedule motivates the need for improved system reliability models in the early design stages. This research seeks to integrate reliability, performance, and cost models in a trade‐off analysis framework in the early acquisition stages. This research uses functional analysis methods to estimate reliability Pre‐Milestone A and assess the impact of reliability on performance and cost models of early system concepts. This research us es technology readiness level (TRL), which is indexed, to assess different levels of reliability for design. An integrated cost and performance model will inform decision ‐makers on the impact of reliability before choosing a system concept for further development.
This work analyzes the role of bioinspired product architecture in facilitating the design of robust engineering systems. Prior works have proposed design guidelines to facilitate the implementation of bioinspired product architectures for engineered systems. This work shows that implementing a bioinspired product architecture may improve a system's robustness to random module failures, but may degrade the system's effectiveness in the absence of any module failure. To demonstrate such a trade-off between the robustness and the undisrupted effectiveness of a system, this study quantitatively compares biological systems to their functionally-equivalent modular systems. The modular equivalents of biological systems are first derived by utilizing Functional Modeling. The application of the bioinspired product architecture guidelines is then modeled as a transition from the modular product architecture of the modular equivalents to the actual product architecture of the biological systems. The effectiveness and the robustness of the systems are analyzed after the application of each guideline by modeling the systems as multi-flow directed networks. Such an analysis is performed by introducing metrics that quantify a system's expected effectiveness and the degradation in the system's expected effectiveness with increasing severity of random disruptions. The findings are validated by designing and analyzing a bioinspired COVID-19 breathalyzer as an engineering case study.
Conference Paper
Full-text available
Autonomous systems operating in dangerous and hard-to-reach environments such as defense systems deployed into enemy territory, petroleum installations running in remote arctic and offshore environments, or space exploration systems operating on Mars and further out in the solar system often are designed with a wide operating envelope and deployed with control systems that are designed to both protect the system and complete mission objectives, but only when the on-the-ground environment matches the expected and designed for environment. This can lead to overly conservative operating strategies such as preventing a rover on Mars from exploring a scientifically rich area due to potential hazards outside of the original operating envelope and can lead to unanticipated failures such as the loss of underwater autonomous vehicles operating in Earth's oceans. This paper presents an iterative method that links computer simulation of operations in unknown and dangerous environments with conceptual design of systems and development of control system algorithms. The Global to Local Path Finding Design and Operation Exploration (GLPFDOE) method starts by generating a general mission plan from low resolution environmental information taken from remote sensing data (e.g.: satellites, plane flyovers , telescope observations, etc.) and then develops a detailed path plan from simulated higher-resolution data collected " in situ " during simulator runs. GLPFDOE attempts to maximize system survivability and scientific or other mission objective yield through iterating on control system algorithms and system design within an in-house-developed physics-based autonomous vehicle 1 Corresponding author. and terrain simulator. GLPFDOE is best suited for autonomous systems that cannot have easy human intervention during operations such as in the case of robotic exploration reaching deeper into space where communications delays become unacceptably large and the quality of a priori knowledge of the environment becomes lower fidelity. Additionally, in unknown extraterrestrial environments, a variety of unexpected hazards will be encountered that must to be avoided and areas of scientific interest will be found that must be explored. Existing exploratory platforms such as the Mars Exploratory Rovers (MERs) Curiosity and Opportunity either operate in environments that are sufficiently removed from immediate danger or take actions slowly enough that the signal delay between the system and Earth-based operators is not too great to allow for human intervention in hazardous scenarios. Using the GLPFDOE methodology, an autonomous exploratory system can be developed that may have a higher likelihood of survivability, can accomplish more scientific mission objectives thus increasing scientific yield, and can decrease risk of mission-ending system damage. A case study is presented in which an autonomous Mars Exploration Rover (MER) is generated and then refined in a simulator using the GLPFDOE method. Development of the GLPFDOE methodology allows for the execution of more complex missions by autonomous systems in remote and inaccessible environments.
Conference Paper
Full-text available
Operation of autonomous and semi-autonomous systems in hostile and expensive-to-access environments requires great care and a risk-informed operating mentality to protect critical system assets. Space exploration missions, such as the Mars Exploration Rover systems Opportunity and Curiosity, are very costly and difficult to replace. These systems are operated in a very risk-averse manner to preserve the functionality of the systems. By constraining system operations to risk-averse activities, scientific mission goals cannot be achieved if they are deemed too risky. We present a quantifiable method that increases the lifetime efficiency of obtaining scientific goals via the implementation of the Goal-Oriented, Risk Attitude-Driven Reward Optimization (GORADRO) method and a case study conducted with simulated testing of the method. GORADRO relies upon local area information obtained by the system during operations and internal Prognostics and Health Management (PHM) information to determine system health and potential localized risks such as areas where a system may become trapped (e.g.: sand pits, overhangs, overly steep slopes, etc.) while attempting to access scientific mission objectives through using an adaptable operating risk attitude. The results of our simulations and hardware validation using GORADRO show a large increase in the lifetime performance of autonomous rovers in a variety of environments, terrains, and situations given a sufficiently tuned set of risk attitude parameters. Through designing a GORADRO behavioral risk attitude set of parameters, it is possible to increase system resilience in unknown and dangerous environments encountered in space exploration and other similarly hazardous environments.
Full-text available
In this paper, we introduce the system operational dependency analysis methodology. Its purpose is to assess the effect of dependencies between components in a monolithic complex system, or between systems in a system-of-systems, and to support design decision making. We propose a parametric model of the behavior of the system. This approach results in a simple, intuitive model, whose parameters give a direct insight into the causes of observed, and possibly emergent, behavior. Using the proposed method, designers, and decision makers can quickly analyze and explore the behavior of complex systems and evaluate different architecture under various working conditions. Thus, the system operational dependency analysis method supports educated decision making both in the design and in the update process of systems architecture, without the need to execute extensive simulations. In particular, in the phase of concept generation and selection, the information given by the method can be used to identify promising architectures to be further tested and improved, while discarding architectures that do not show the required level of global features. Application of the proposed method to a small example is used to demonstrate both the validation of the parametric model, and the capabilities of the method for system analysis, design and architecture.
Conference Paper
Full-text available
Algorithms used in rovers for route planning often focus on finding the shortest path between two points, but rarely take into account the risk to the physical roving system of taking a path. One issue presented by route planning optimized for risk is varying risk attitudes, which can lead to vastly different routes being chosen. A risk attitude is a preference concerning acceptable levels of risk to perform a specific action. The field of Prognostics and Health Management (PHM) aims to predict and prevent mechanical failure in electrical and mechanical systems, and can be used to inform route planning by assessing risk associated with taking an action. A method has been developed and is presented in this paper for Risk Attitude Informed Route-planning (RAIR) that takes into account the calculated risk, the benefit, and risk attitude and selects the optimal route. The risks to the rover will be calculated by using rover PHM data, terrain information, and Function Failure Identification Propagation (FFIP) to determine risk of specific routes. The route is navigated incrementally by selecting the best route across a small segment and then determining the best route from the new position until the rover has reached the final destination. Results of experiments utilizing a simulated planetary rover navigating between points using RAIR are presented in this paper and the effectiveness of the method is discussed. Improved route planning through RAIR enables more autonomous navigation of hazardous and remote environments that accurately reflects the desired risk attitude without direct human planning or interaction than is currently available, thus reducing cost and time for exploratory rover missions to accomplish mission objectives.
Conference Paper
Full-text available
Functional modelling methods used in the early conceptual phases of complex system design allow system designers to better understand and refine system architecture from a functional perspective. A family of methods exist to model functional failures and failure flows. These failure flow modelling methods provide the opportunity to understand potential system failure sources and redesign systems for more robustness. One area lacking from the family of function failure and flow methodological family is the ability to model failure flow decision-making. This paper presents the Function Flow Decision Functions (FFDF) methodology that allows system designers to model failure flow decision-making where critical functions and flow exports are protected from failure flows by sacrificing less critical functions and flow exports. By sacrificing less critical functions and flow exports, mission-critical functions and flow exports can be preserved in order to accomplish the primary mission objectives of a system. A case study based upon the Mars Exploration Rover platform is presented in this paper.
Full-text available
Critical considerations in engineering enterprise systems are identifying, representing, and measuring dependencies between suppliers of technologies and providers of services to consumers and users. The importance of this problem is many-fold. Primary is enabling the study of ripple effects of failure in one capability on other dependent capabilities across the enterprise. Providing mechanisms to anticipate these effects early in design enables engineers to minimize dependency risks that, if realized, can have cascading negative effects on the ability of an enterprise to deliver services to users. The approach to this problem is built upon concepts from graph theory. Graph theory enables (1) a visual representation of complex interrelationships between entities and (2) the design of analytical formalisms that trace the effects of dependencies between entities as they affect many parts and paths in a graph. In this context, an engineering system is represented as a directed graph whose entities are nodes that depict direction, strength, and criticality of supplier-provider relationships. Algorithms are designed to measure capability operability (or inoperability) due to degraded performance (or failure) in supplier and program nodes within capability portfolios that characterize the system. Capturing and analyzing dependencies is not new in systems engineering. New is tackling this problem (1) in an enterprise systems engineering context where multidirectional dependencies can exist at many levels in a system's capability portfolio and (2) by creating a flexible analysis and measurement approach applicable to any system's capability portfolio, whose supplier-provider relationships can be represented by graph theoretic formalisms. The methodology is named Functional Dependency Network Analysis (FDNA). Its formulation is motivated, in part, by concepts from Leontief systems, the Inoperability Input-Output Model (IIM), Failure Modes and Effects Analysis (FMEA), and Design Structured Matrices (DSM). FDNA is a new analytic approach. One that enables management to study and anticipate the ripple effects of losses in supplier-program contributions on a system's dependent capabilities before risks that threaten these suppliers are realized. An FDNA analysis identifies whether the level of operability loss, if such risks occur, is tolerable. This enables management to better target risk resolution resources to those supplier programs that face high risk and are most critical to a system's operational capabilities. KEY WORDS: Risk, capability risk, capability portfolio, dependencies, operability, inoperability, engineering systems, Leontief matrix, design structured matrix (DSM), failure mode and effects analysis (FMEA), inoperability input-output model (IIM), functional dependency network analysis (FDNA).
This research defines the basis for a new quantitative approach for retrieving useful analogies for innovation based on the relevant performance characteristics of functions. The concept of critical functionality is the idea of identifying only a certain set of pertinent design functions observed in a single domain that significantly define the functionality of the product. A critical function (CF) is a function within a functional model whose performance directly relates to a key performance parameter (KPP) of the system as a whole. These CFs will enable multiple analogies to be presented to a designer by recognizing similar functionality across distant design domains and incorporating key performance criteria. The ultimate focus of this research project is to create a performance-metric-based analogy library, called the design analogy performance parameter system (DAPPS). By focusing on a select set of "critical" functions, more design domains can be included in the database facilitating analogy retrieval founded on the qualification of KPPs.