Taxonomy & Theory > FFIP Reasoning Framework

FFIP: The Functional Failure Identification and Propagation Framework

Origin and authorship

FFIP (Functional Failure Identification and Propagation) is a design-stage failure-reasoning framework introduced by Tolga Kurtoglu (then a graduate research assistant, University of Texas at Austin) and Irem Y. Tumer (Associate Professor, Oregon State University; also affiliated with NASA Ames Research Center) beginning around 2007-2008, most centrally in:

Kurtoglu, T. and Tumer, I. Y. (2008). "A Graph-Based Fault Identification and Propagation Framework for Functional Design of Complex Systems." Journal of Mechanical Design, 130(5).
Kurtoglu, T., Tumer, I. Y., and Jensen, D. (2010). "A Functional Failure Reasoning Methodology for Evaluation of Conceptual System Architectures." Research in Engineering Design, 21(4):209-234.

The framework was subsequently extended by a group of collaborators including David C. Jensen (later University of Arkansas), Christopher Hoyle (Oregon State University), and others, with case studies including nuclear power plant designs and NASA testbeds. This body of work is largely an Oregon State University / NASA Ames Research Center research program, distinct from (but chronologically overlapping and thematically continuous with) the Australian PHM Technology / MADe lineage documented in made-functional-basis-connection.md. There is no direct citation of FFIP found in PHM Technology's 2008 MADe paper — the two research programs appear to have developed independently from the same academic ancestor (the Functional Basis), rather than one citing the other — though MADe's underlying reasoning (functional concept maps altering flows to represent failure propagation) is conceptually a close cousin of FFIP's Function Failure Logic.

The problem FFIP solves

Traditional failure analysis (FMEA/FMECA, fault trees) needs a fairly mature, physically-detailed design before it can meaningfully estimate failure probabilities and propagation paths. FFIP's motivating idea, per Kurtoglu et al., is to push failure reasoning back to the conceptual design stage, before physical components are chosen, by reasoning purely over the functional model (the Functional-Basis verb/flow representation) plus a qualitative behavioral simulation — so designers can "design out functional failures where possible and design in the capability to detect and mitigate failures early on in the design process," before high-cost commitments are made.

The three components of FFIP

Per the framework's description (consistent across multiple summaries of Kurtoglu & Tumer's papers):

A graphical system model — functions and flows expressed as function-flow block diagrams, using the same Functional Basis vocabulary (Hirtz/Stone/Wood) documented in functional-basis-taxonomy.md. This maps functions to physical/software components in a structural representation.
A behavioral simulation — the nominal and faulty behavior of each component is stored as a state machine in a component library. Each state is a behavioral mode where qualitative intervals of input-flow attributes (e.g., "high," "low," "none") are converted to output-flow attributes. Example (from Jensen et al. 2014): a fuel line's nominal mode passes its input flow level straight through to output; its "blockage" fault mode instead forces the output flow level to zero.
Functional Failure Logic (FFL), the reasoning layer — this is FFIP's central contribution. FFL relates the input/output attribute changes seen in the component simulation to an expected change in the function mapped to that component, producing a health-state verdict for every function in the system.

Function Health States — the core abstraction

FFIP's output is not a probability or a physical measurement; it is a categorical judgment about whether each function in the system is still doing what the designer intended. Per Jensen, Bello, Hoyle & Tumer (2014), there are four states:

Healthy — the function affects the flow as intended.
Degraded — the function affects the flow, but not as intended.
Lost — the function does not affect the flow at all.
No Flow — there is no flow for the function to act on in the first place (usually itself a consequence of an upstream failure) — treated as a special case/subtype of Lost.

A fault scenario is a set of component fault-mode assignments (one state per component); the simulation propagates these through the causal function-flow graph; the system state is the resulting vector of health states across every function in the model. This is conceptually identical to what MADe calls a "Functional Concept Map" propagation (see made-functional-basis-connection.md) — both frameworks independently arrived at "represent a failure as an altered flow attribute, then propagate that alteration along the function-flow graph" as the core reasoning move, because both are built on the same underlying Functional Basis vocabulary that makes a function's "correctness" formally checkable against its declared flow.

Two advantages FFIP researchers claim over predecessor methods

Cross-domain functional abstraction — because functions and flows are domain-agnostic (the same vocabulary covers mechanical, electrical, hydraulic, and software elements), FFIP can trace a fault that originates in software and propagates into hardware consequences, something structural/CAD-based failure analysis struggles with.
Simulation-based, not rule-lookup-based — because behavior is a simulated state machine rather than a static fault tree, FFIP can analyze multiple simultaneous and cascading faults, not just single point failures, by simply triggering more than one component's fault-mode transition in the same scenario.

Relationship to Failure Modes and Effects Analysis

FFIP is explicitly positioned by its authors as a way to get FMEA-like insight at a stage where a traditional FMEA is not yet possible (no bill of materials, no failure-rate data) — it substitutes a qualitative, function-level behavioral simulation for the empirical failure-rate data that a mature-design FMEA would use. Grantham-Lough, Stone, and Tumer's related "Risk in Early Design" method (2009, Journal of Engineering Design 20(2):144-173) uses historical failure rates tied to function/flow types for a similar early-stage purpose, representing an alternative, statistics-based branch of the same research lineage (contrasted with FFIP's behavior-simulation-based branch) per Jensen et al. (2014).