Failure Analysis in Conceptual Phase toward a Robust Design: Case Study in Monopropellant Propulsion System

As a system becomes more complex, the uncertainty in the operating conditions increases. In such a system, implementing a precise failure analysis in early design stage is vital. However, there is a lack of applicable methodology that shows how to implement failure analysis in the early design phase to achieve a robust design. The main purpose of this paper is to present a framework to design a complex engineered system resistant against various factors that may cause failures, when design process is in the conceptual phase and information about detailed system and component is unavailable. Within this framework, we generate a population of feasible designs from a seed functional model, and simulate and classified failure scenarios. We also develop a design selection function to compare robust score for candidate designs, and produce a preference ranking. We implement the proposed method on the design of an aerospace monopropellant propulsion system.


I. INTRODUCTION
The number of parts in complex engineered systems is increasing rapidly. For instance, the components only in an integrated system is expected to be double every year as Gordon Moore predicted properly. Therefore, the interaction between various parts of the system, and between the system and external factors gets more complicated as technology and market demand is changing. The complicated interactions cause different type of uncertainties, and unexpected uncertainties can cause undesired behavior of the system or even catastrophic failures.
An important concept in designing complex engineered systems, is to ensure that the behavior of the system in undesired and uncertain situations is determined early in the design phase, prior to the manufacturing and operational life of the system. It requires to conduct a failure analysis in the conceptual design phase when the component model of the system and design specifications have not been developed yet. Failure analysis in early design phase help the designers to find strategies to improve the design to enable the system cope with the uncertainties during the operational life, as well as reduce the design revisions in further design steps shapers [1] To study the failure behavior of a system in the early design stage, modeling and simulation of the failure scenarios are the necessary steps. In many complex engineered systems, the characterization of the system is represented using a component model. However, when developing a new design, or in the early design phase, there is no component-level model available, and typically the set of components is not selected. Because of this, we came up with the idea of using functional model to study the system's failure behavior in early design phase, to achieve a robust design.
An overall description of our proposed design methodology is provided as follows. Developing a functional model is the first step. To develop a functional model for a complex engineered system, all the functions and flows and operational modes should be defined based on the system requirements and expert knowledge. Each function can have different operational modes: nominal, degraded, and failed. Next step is simulation of the system failure behavior. We have developed an open access tool in Python to simulate failure scenarios using functions, flows, and modes. The unique failure scenarios provide information on the probability of having undesired end states. Applying the cost-risk model, the designer evaluates the cost of a design versus the robustness of the design against a failure. If the design fulfills the requirements, the process ends. Otherwise, a new design is generated by modifying the functional model. The program runs until the search algorithm achieves the design with the optimal robust score. Fig. 1 shows the flowchart for our proposed method. Green boxes represents the steps that are required to be done by designers and blue boxes are produced by software. This paper provides an applicable framework that shows the designers how to implement failure analysis and achieve a robust design in early design phase, when information about components is not available. We illustrate how to develop a functional model, simulate failure behavior of the system, and evaluate robustness of a design in early design phase. We implement the proposed approach in early design phase of an aerospace monopropellant propulsion system and achieve the design with optimal cost and resistance against failure. The material of this paper is organized as follows: Section 2 proposes a clear and consistent definition of robust design, and carefully disentangles it from reliability and resilient design. Section 3 describes different failure analysis methods and our logic to select functional model to study the failure behavior of the system. Section 4 illustrates how to represent a design applying a functional model. Section 5 proposes a cost-risk function to evaluate cost of a design and it's robustness against failure. Section 6 presents generating different designs and search algorithm. In section 7, we apply the proposed method to find the robust design for an aerospace monopropellant propulsion system. Section 8 is the result and finally, section 9 provides conclusion and summary.

II. ROBUST DESIGN
Failure analysis is the first step to design a complex engineered system and the strategies to make it a robust system must be designed into the system from the beginning, because as we go forward in the design process making changes is more complicated and expensive [1].
Design strategies used for advancing reliability are implemented for the purpose of advancing robustness in a system; however, there is meaningful difference between these concepts. Reliability is the ability of a system to perform nominally for a specific period of time. In fact, reliability is the probability of success or availability of a component/system for a specified period of time [2]. Reliability concentrates more on "why and how" components or systems may fail or have failed. Fault Tree Analysis (FTA), Failure Modes and Effects Analysis (FMEA), and event tree analysis are known techniques to study reliability [3]. Practice has shown that the main issue of these techniques is the requirement of the component-level detail of the system from the beginning of the design process.
Robustness is where the system's performance is minimum sensitive to internal and external uncertainties that can cause failure [4][5][6]. The ability to overcome such uncertainties should be embedded into the system from the beginning. Uncertainty is the lack of ability to determine something precisely [7,8]. Uncertainty management is an important concept in the design process of complex engineered systems. Reducing uncertainty when designing a system results in more efficient system with less cost.
Resilience can be defined as a system's ability to recover from a failure. Recovery from a failure is an alternative to reducing uncertainty. There are different ways to recover from uncertain events, including flexibility, Monitoring and Automated Contingency Management (ACM).
Flexibility is the ability of a system to respond to changes in initial requirements and objectives, after it starts operating, in a timely and cost-efficient way [9]. Keshavarzi et al, developed a strategy to apply flexibility in designing a complex engineered system to cope with epistemic uncertainty during the system operation lifetime [10,11]. An ACM system adapts automatically and allows some degradation in the system performance when failure occurs with the goal of still achieving the mission [12][13][14][15]. For example, taking photos with less resolution is applying ACM when the mission dictates possessing an image. Yodo et al. provide a literature survey of existing studies in engineering resilience from a system design perspective, with the focus 536 on engineering resilience metrics and the strategies to quantify those metrics [16]. To improve reliability, robustness or resiliency of a design, failure analysis is a necessary step. In most existing failure analysis methods, system designers need a precise model of system components to be able to study complex behavior of the system. However, in early phase of design process, specific set of components have not yet been selected and such detailed models of the complete system is not available.
Because of this lack of methods to study failure behavior in the early design phase, the idea of representing the complex system by only its intended functionality is proposed as part of our methodology. The following section discusses failure analysis using functional models.

III. FAILURE ANALYSIS
An engineered system is defined as an assemblage of subsystems, hardware/software components, and people designed to perform a set of tasks to satisfy specified functional requirements and constraints [17]. The traditional approach for designing an engineered system is to establish a pre-defined set of requirements based on market studies and best estimate extrapolations of the current state and then find the optimal design to satisfy the requirements [18]. However, these approaches are inadequate to respond to changes in initial requirements and uncertain events. This can lead to failure if the system is faced with significantly different conditions than the ones predicted.
As a system becomes more complex, the uncertainty in the operating conditions increases. In such a system, implementing a precise failure analysis in early design stage is vital [19]. There are different types of failure analysis techniques for complex systems [20][21][22][23][24][25][26][27], like probabilistic methods [28,29], or reliability techniques [30,31], or approaches based on observations analysis [32]. Studies have shown that the early design stage is the best time to catch potential failures and anomalies [33]. However, in the early design phase, decisions about the specific set of components is not made, and a component model is not available. The idea of using functional model, instead of component model, to design a complex system is of increasing interest. A functional model in systems engineering is a structured representation of the functions to meet system requirements.
The goal of developing a functional model is to describe the system behavior and determine vulnerable parts of the design, resulting in potential system improvement, particularly helpful in the early design stage when the detailed component model of the system is not available.
Methods have been developed to combine functional modeling with failure analysis. Stone and Tumer developed the Function Failure Design Method (FFDM) which was the bridge between failure analysis and functional modeling.
They applied functional models to represent the system design and identify potential failure states for each function [34,35]. Grantham et al., estimated the failure likelihood for each functional in the system. Lough et al., classified functions to high-risk to low-risk based on the consequence of failures [36,37]. The idea of providing function-based failure analysis provided some improvements in the design of complex engineered systems; however, these methods limit the designers of the system to considering only one single-fault impact analysis at a time.
To overcome this restriction and to enable the designer to consider multiple function failures effect, the Function Failure Identification and Propagation (FFIP) method was presented [38][39][40][41][42][43][44][45][46][47]. The FFIP method identifies failure propagation paths by defining states of function health. This approach uses a separate behavioral model simulation to show failure propagation paths and failure effects. Typically, the modeling language Modelica is applied to simulate failure scenarios [48,49]. However, system models cannot be automatically constructed from a description of the functional structure of a system and therefore it may not be useful in FFIP where multiple designs are investigated.
McIntire et al. have created IBFM tool (Inherent Behavior of Functional Models), to simulate failure scenarios applying functions, modes, flows between the functions and conditions for transition between the functions. With this tool, designers can create a functional model of the system in the early design stage and simulate the failure propagation paths for the system without developing a separate behavioral model [50].
In our presented framework, we apply the IBFM tool to simulate the failure scenarios for different design topologies.
The following section describes the method to develop a functional models to represent a system. Fig. 1. The first step in the proposed method is to study the requirements and expectations from the system and define the functions and flow. We use a graph to represent the system functionality and its interaction with the environment. We implement the method in Python, because Python is free access and provides other tools like NetworkX which can be utilized to represent the functional model graphically. Graphs provide the designers the ability to represent functional models with complicated structure [51]. Each graph edge (arrow) represents a flow of material, energy, or information within the system and each graph node (rectangle) represents a function that acts on the flows intersecting it. Fig. 2 provides an example of a graph representation of a functional model consisting of a single internal function and three functions. Fig. 3. In this paper, the flow has a direction, and uses two variables to define the flow: an effort variable, and a rate variable. For example, a liquid flow can be modeled as either a liquid pressure (effort) or a liquid volume flow rate (rate). The function at one end of the flow controls the effort state, while the function at the other end controls the flow rate. In our approach effort and rate variables take qualitative values, such as Zero, Low, Nominal, and High. In the IBFM approach, all modes and conditions are qualitative, rather than quantitative. The conditions that regulate a function transitioning from one mode to another mode are also flow specific. For example, the operational mode of the function "Regulate Gas Pressure" has a "Gas High-Pressure" condition that leads to a failed mode. The "Gas High-Pressure" condition is only used by functions that have a "Gas" flow. Functions, flows, modes, and conditions are defined to construct a functional model to be fed to the IBFM tool to simulate all system failure scenarios. The simulation of each fault scenario begins at the nominal state, and then changes the mode of one or more functions to a degraded or failed mode. The end state of each scenario is recorded for further analysis. The number of unique paths that have a particular undesired end state is used in the costrisk model described in the following session.

V. ROBUST VALIDATION
In this part, a cost-risk model is proposed to evaluate the robustness of different designs for a complex engineered system. The idea of this cost-risk model is rooted in the riskbased utility theory [52]. This model studies the tradeoffs between cost of designing a system that is resistant against a failure, versus the cost of designing the system without robustness while accepting the inherent risk of failure. The key element is that the "cost of risk" can be quantified, such that the trade-off between adding system cost versus accepting risk can be made. The proposed model is composed of three cost elements: the baseline cost of the design, the cost of mitigation, and the cost of risk, given by Equation (1).
Cost of mitigation C R : Consequential cost of the risk P R : Probability of risk P M : Probability of mitigation : Probability of mitigation failure N: Number of undesirable end states C D is the cost of design when there are no strategies to make the design robust. C M , represents the cost of changing the design to make it robust to a particular failure. In the next section, we describe four strategies to change a functional model to represent different designs for a system. Independent of the quality of performance, there is a certain cost to operate a system, defined as operation cost, C O .
With respect to defining the "cost of risk", we define a risk as a triplet of its impact or consequence, its probability of failure occurrence, and it's probability of being mitigated. In Equation (1), C R is the impact or consequential cost of the risk; in our approach, it is quantified as the cost of having a failure (in units of dollars). Secondly, P R is the probability of having a specific undesired end state or failure behavior and is quantified using the results of failure simulation. It is quantified as the number of unique scenarios with a particular undesired end state (or fault) divided by total number of unique scenarios. Lastly, P M is the probability that a design resist against a failure due to a mitigation action (a mitigation action is assumed to have a cost of C M ). Probability of mitigation is also calculated from the failure simulation result by adding the mitigation action to the functional model and rerunning the simulation. N is the number of system undesired end states or failure behavior that the system is designed to resist. Except for the nominal scenario when all functions perform nominally, other end states are failure scenarios and undesired. However, an undesired end state does not imply that a failure is present, it may just reflect an end state that prevents the system from nominal operation or from completing a mission. For instance, when designing a car, having a flat tire is undesirable, but may not be classified as a safety hazard or failure of the system; however, an engine fire is both an undesirable state and a safety hazard.
Applying the cost-risk model, the designer can determine the tradeoff between robustness and cost of a design; the cost-risk model is treated as an objective function in an optimization framework. In the optimization formulation, the objective is to minimize total cost (i.e., Equation (1)), subject to any system-level constraints. Treating the search for the best system-level design as an optimization problem necessitates identifying a termination condition for the search. In application, the search would most likely be done by a heuristic or stochastic search method, given the discrete nature of the functional model representation of the system. Since these methods cannot be guaranteed to converge to the optimum in finite time, the search must be ended based on a heuristic [53]. Termination Conditions for the proposed framework can be defined as: • An upper limit on the number of evaluations (designs) is reached. • An upper limit on the time of evaluations of the fitness function (cost-risk model) is reached.
• The chance of achieving significant changes is very low.
If the design meets one or more of the termination conditions, it gets selected, otherwise a new design is generated and evaluated.

VI. GENERATE ALTERNATIVE DESIGN
As noted in previous part, the cost-risk approach is implemented as a search problem, in which the objective is to find the lowest cost design. An issue to address is how to change/modify a functional model to produce other feasible designs in the search process. The challenge is identifying alternate functional models which are technically feasible, i.e., functional models which preserve the key system functions and the associated flows. Therefore, a method is needed to ensure that functional models evaluated in the search process are technically feasible. We propose four strategies to generate new design based upon a few simple rules used by designers of aerospace systems. The design modification rules can be placed into four categories as follows:

A. Redundancy and Health Management
In this technique, redundancy or health management is added to the functional model. The redundancy could be the addition of a redundant function, or it could be added in the form of partial redundancy. In the case of partial redundancy, we may be able to fulfill the needed functionality using secondary functions. For example, we may be able to use a pressure sensing function to also indirectly fulfill a flow rate sensing function in the case that the flow rate sensing function is faulted. Adding redundancy or health management will affect C M and P M in Equation (1). The tradeoff will in general be one in which mitigation cost is added to increase the probability of mitigation (and thus reduce the cost of risk).

B. Conceptual Order
Changing the order of functions is another way to generate a new design at the conceptual level of the design. This change affects the probability of the risk, P R , by focusing on failure avoidance; i.e., arranging the functions is such a way that failure propagation path is changed and thus the probability of a risk is changed.

C. Utilizing Wasted Flows
In this method, any flows that transfer material or energy to the environment (i.e., are not used by the system directly) are utilized as additional inputs for other functions where applicable. This improves the failure avoidance aspect of the design. For example, one could use waste heat to supplement a heating function as a mitigation function (C M and P M ), or one could lower the cost of design of a heating function (C D ) by coupling waste heat from a different function with the heating function.

D. Combining/Splitting Functions
Two or more functions can be combined (or split) to make a new design and potentially improve the failure avoidance of a system. This could affect both C D and P R . whether combining two or more functions into a single function (or splitting a single function into two or more functions) improves or worsens the cost-risk objective function must be determined by the results of failure simulation. Combining functions may lead to elimination of a failure path (thus reducing P M ), or may make the new combined function more likely to fail (thus increasing P M ).
We can generate a large space of alternative models by using the functions, however a small portion of the space can be technically feasible. For instance, by having every possible order of functions from initial mono propellant propulsion system model, we can generate a large space of designs, however having thrust function before heating gas is meaningless. Therefore, we narrow down the design space to small number of models that could be considered for the system. In the following section, we apply the proposed approach in early phase of designing a monopropellant propulsion system. The goal is to design the system to be 539 539 robust to events that can cause failure while managing the cost.

VII. CASE STUDY: MONOPROPELLANT PROPULSION SYSTEM
A monopropellant propulsion system refers to a chemical propulsion fuel which does not require a separate oxidizer and thus can be used in space. Monopropellant designs are typically used in the aerospace industry because they make the engine lighter, less expensive, and more reliable. In this case study, the monopropellant is hydrogen peroxide ( ).
It is important when designing a monopropellant propulsion system to consider environmental condition in space. With no gravity assistance, the system should be able to push the propellant towards the catalyst. The concept for this system design is to apply expanded gas to push the monopropellant over a catalyst and produce thrust. This system can be divided into three main subsystems: gas, propellant, and catalyst.
When there is a command for a change of the spacecraft velocity, the inert gas is heated to expand. The expanded gas is fed through regulation and control functions to reach the right quantity, pressure and temperature. The expanded gas places pressure on the propellant (hydrogen peroxide) and guides it to the catalyst. When the propellant passes the catalyst, combustion occurs and changes the velocity of the spacecraft. Fig. 3, presents the general idea for a monopropellant propulsion system design.

A. Failure Behavior
Assume a spacecraft with monopropellant propulsion engine has a mission to travel to a planet in outer space and from external orbit to the middle orbit and then to the lower orbit and take some images and get back to earth. Fig. 4, shows different scenarios. When the thrust is commanded, if all functions are nominal, the system performs as expected. In Fig. 4, the green dot shows the spacecraft accomplished the mission. However, there are scenarios in which something can go wrong with one or more functions and the result is not as expected. Blue, yellow and red dot in Fig.4, represents the scenarios that spacecraft ended up with an undesired situation. This would cause the engine to provide too much (yellow dot), too little (blue dot) or no thrust (red dot). In practice, it means the aerospace system passes the commanded orbit, or does not reach it. In rare catastrophic failures, the system might explode (i.e. loss of system). Therefore, the final behavior of failure analysis for a monopropellant propulsion system is classified to 5 groups: • Mission Accomplished (Desired) • Too Much Thrust (Undesired) • Too Little Thrust (Undesired) • No Thrust (Undesired) • Loss of the System (Undesired)   Fig. 5, to avoid too much information in one graph. The following session describes how to define the design in Python and simulate failure behavior.

A. Functions Definition
The monopropellant propulsion system model in Fig. 5, contains 29 functions and 129 modes. One example of our function and modes definition for the monopropellant propulsion system in Python is as follow: function ImportHeat mode 1 Operational NominalHeatSource mode 2 Degraded LowHeatSource mode 3 Degraded HighHeatSource mode 4 Failed NoHeatSource The first line contains the keyword function, followed by the desired name of the function. The indented lines contain all of the modes of the function. Each line describing a mode begins with the keyword mode, followed by a unique within-function alphanumeric identifier, followed by the function health associated with the mode, followed by the name of the mode. Available mode health states are Operational, Degraded, and Failed modes. Failed modes are the ways, in which the system might fail. A single mode in each function definition is followed by the keyword Nominal, which by default assigns that mode to be the initial mode of the function at the beginning of simulation.

B. Flows Definition
Flows are defined in a single line. Our strategy to define a flow is to mention the keyword flow, then the type of flow, followed by the name of the category of the flow which can be Material, Energy, or Signal. All flows are derived from one of mentioned three categories of flows.
flow Heat Energy

C. Modes Definition
Modes definition is more complicated, as all of the mode's behaviors must be explicitly described. Operational, degraded, and failed modes are required to be defined for each function. A simple mode definition example is the nominal gas source mode: mode NominalGasSource InertGas output effort = Nominal The first line consists of the appropriate keyword, in this case mode, followed by the desired name of the mode. Each indented line consists of a single assignment statement. The expression to the left of the assignment operator = is evaluated to determine the flow variable being assigned to. The expression on the right of the assignment operator determines the state of the flow variable. Every flow in the statement must be referred to using three words: the flow type name, its direction, either input or output, and its variable, either effort or rate. More complex behaviors may be defined by using operators. A single unary operator is used in the definition of the "NoGasSource" mode: mode NoGasSource InertGas output effort = Zero This mode definition makes use of a constant state. Available states are Zero, Low, Nominal, High, and Highest. The definition of the drifting low pressure sensing mode uses two unary operators: mode DriftingLowPressureSensing import NominalConductingRegulatedGas SignalDesiredPressure output effort = RegulatedGas input effort -- The first one, the keyword import, copies all of the statements from the definition of the mode directly following the keyword. In this case, the two statements from the "NominalConductingRegulatedGas" mode are copied into "DriftingLowPressureSensing". The second one, the decrement operator --, decreases the value of the state by one qualitative level.

D. Conditions Definition
Condition definitions are similar to mode definitions. They name the condition being defined, and explicitly describe the behavior, but they only include a single behavior statement. Rather than being an assignment, the statement is a logical test. For example, the condition to test for a function being exposed to high temperature is: condition HighTemperature Heat output effort > Nominal Logical operators may be combined to form more complex tests. All binary operators are evaluated from left to right.
We simulate all failure scenarios using our developed IBFM tool. We tabulate the unique scenarios terminating with particular undesired end states. The final behavior of the system as shown in Fig. 4

E. Alternative System Designs
The baseline design, shown in Fig. 3, represents a functional model developed for a monopropellant system in the early design phase. In this design, the desired final behavior is the mission accomplishment, in which all gas, propellant, and catalyst functions operate nominally. Any improvements in the functional model influence the final behavior of the system. In other words, the baseline model is not designed to be robust. Therefore, different system topologies with focusing on improvement the robustness of the system can be investigated. Improvement strategies include applying different levels of redundancy, re-configurability or integrated health management sensors in the system design.
For each design, the failure scenarios can be classified into five end states. Fig. 6, represents the Pie Chart for a candidate design for monopropellant propulsion system.

Fig. 6. Classification of failure scenarios for basic monopropellant design
In this case study, we simulate the failure behavior of the initial design and compare it to six alternative functional models representing different designs for the monopropellant propulsion system. In each alternative design, changes are applied in the functional model to improve the robustness of the design against some particular failures.
The first modification of the baseline design includes a redundant gas rate sensing function. In this design, if no signal is coming from the primary sensing function, a secondary sensing function can supply the required information. The second modification of the initial design is an identical system with redundant gas pressure sensing. The third modification of the initial design combines the adjusting pressure and rate into one function. The fourth design uses output heat to expand inert gas (by contrast, in the baseline, the heat is exported from the system and disappears into space). The fifth design incorporates the redundant sensing for propellant. The sixth design applies the output thrust heat to preheat the propellant. In this way, the propellant plays the role of a cooling system. The following section presents the result of failure simulation for all six alternative designs and evaluate them based on our proposed robust score function.

VIII. RESULT
Seven candidate designs for the monopropellant propulsion system are examined. In each design, the functional model has been modified to be more robust to a particular failure or undesired end state. Failure behavior has been simulated for all six alternative designed in Table 1. The amount of CPU time required to simulate each scenario increases as the complexity and the number of faults injected to the model increases. For instance, the time of simulation for injecting two simultaneous faults is less than the time of simulation for injecting three simultaneous faults. In this study, we investigate injecting up to 3 faults (all possible three failures) in each one of the functional models. Fig. 7, displays the classified simulated scenarios for the seed and the six design topologies is shown in Fig. 7. In this histogram, the number of successful and failed scenarios simulated for each design is demonstrated. The probability of risk in each design is applied to the costrisk model of Equation (1). The mitigation cost C M is the cost of changing the basic design to make it more robust to a particular failure or undesired end state.
The operation cost C O for all candidate designs is assumed to remain the same because on-ground systems cost is the main operation cost for a monopropellant propulsion system. It's assumed that regardless of how the system is performing, there is an on-ground system to monitor, control and run the spacecraft. For other design studies, the operating cost may vary by design concept. It is assumed that the aircraft completes three missions per year, and for each mission the operation cost is $500 million. The number of failed scenarios versus the total number of scenarios for each design defines the probability of risk, P R .

Design 3
Combine adjusting gas pressure and rate into one function

Design 4
Use output thrust heat to expand inert gas

Design 5
Redundant propellant pressure sensing

Design 6
Use output thrust heat to expand inert gas and preheat propellant The probability of the mitigation, P M , is the probability that the mitigated part does not work when needed. These probabilities are quantified based on the IBFM simulation and cost numbers are estimated based on the space system cost models and data provided by Miller et al. [54]. The total cost reflects the tradeoff between designing a robust system and the cost of doing so. The lower the total cost, the higher the rank of the design would be. Table 2 represents the results of robust evaluation for developed designs for monopropellant propulsion system. It tabulates all the elements of Equation (1). Since there were only seven designs to consider, an exhaustive optimization algorithm was used; however, an evolutionary or other stochastic algorithm could be used to search larger design spaces.
As shown the table, Design 6 has the optimal trade-off between robustness and cost. In this design the propellant acts as a cooling system. The heat produced by propulsion is used to preheat the propellant and expand the inert gas. Utilizing this source of energy helps the successful combustion process. This design was selected because it had the lowest value of the cost-risk objective function. The next best design is Design 3, which combines the gas pressure and rate control into a single function. This may indicate that since both functions are critical to operation, and a failure of either function is highly detrimental to the system, it is better to address them with a single function with a single failure rate.

IX. CONCLUSION
This paper proposed a framework to design a complex engineered system in early design phase with the ability to resist against failure. We discussed the lack of current methods to address failure analysis and robustness of a system in the early design phase. Current design methods require a detailed component model of a system to be able to simulate and study the failure behavior of the system. However, such methods are not applicable in early design phase when the set of components is not selected yet and design is in the conceptual step. Ideally, the strategies to make a robust design should be implemented in early design phase, because as we go forward in the design process, making changes is more expensive and challenging. In our proposed method, we showed how to represent a complex engineered system with a functional model in early design phase. We illustrated how to define functions, modes, flows and conditions to simulate the failure behavior of the system and how to generate different designs for a system using a functional model. Finally, our developed robust score function provides the ability to evaluate the trade-off between cost and robustness of a particular design and search for the optimal one among candidate designs.
We applied the proposed method in early phase of designing an aerospace monopropellant propulsion system. The results show that the presented method is a practical design framework to conduct failure analysis and develop robust complex engineered systems in the early design phase, when the complete knowledge of the system components and specifics is not available. A future research is needed to investigate the proposed approach in a design problem where the design space is large and there is a large number of feasible candidate designs. Graph grammars could be implemented to help generate a large number of design alternatives.