Taxonomy & Theory > FFIP Reasoning Framework

FFIP Applied: Electrical Power System and Nuclear Power Plant Case Studies

Purpose of this document

The conceptual mechanics of FFIP (function health states, the FFL reasoner) are documented in ffip-framework.md. This file walks through a fully worked FFIP case study — an Electrical Power System (EPS) testbed — to make the abstract propagation logic concrete, and briefly notes the framework's other published applications, including a nuclear power plant design.

The worked example below is drawn from Jensen, Bello, Hoyle & Tumer (2014), "Reasoning about System-Level Failure Behavior from Large Sets of Function-Based Simulations" (Oregon State University, open-access accepted manuscript, published in Artificial Intelligence for Engineering Design, Analysis and Manufacturing). This paper does not redefine FFIP — it explicitly builds on and reuses the FFIP method from Kurtoglu & Tumer (2008) and Kurtoglu, Tumer & Jensen (2010) — but its worked example is the clearest publicly available walkthrough of FFIP mechanics in action.

The example system: a fault-tolerant Electrical Power System (EPS)

The EPS testbed is based on the Advanced Diagnostics and Prognostics Testbed at NASA Ames Research Center (Poll, 2007). It has two battery banks, two load banks (AC and DC), four relays, breakers, inverters, and a software relay controller. The controller's job is to keep as much load powered as possible by opening/closing relays based on voltage and relay-position sensor readings, with an explicit rule that no two batteries may ever be connected together (which would cause an overcurrent).

The system recognizes three system-level operational states:

Nominal — both load banks powered.
Degraded — only one load bank powered.
Lost — neither load bank powered.

The software controller's truth table defines seven possible control states (State 1 through State 7) mapping battery-to-load routing combinations, e.g. "Batt1 → Load1, Batt2 → Load2" (nominal) versus "Batt1 → Load2, Batt2 → Load1" (a nominal cross-connected fallback) down to "No Action" (total loss).

How the FFIP simulation ran

Component behavior was modeled as Stateflow state machines in MATLAB Simulink. A scenario begins with all components nominal; at time step 25, one component's mode is switched to a fault mode (e.g., Battery 1 → "Failed-Disconnected," which removes its current/voltage output); a second fault can be injected at time step 50. The controller's software logic reacts in the simulation exactly as it would in the real system, attempting to reroute power; if no valid routing solves the fault, "the software controller defaults to opening all relays as a failure safety measure." After 100 time steps, the final health state of every one of the system's 58 component-level functions is recorded as the result of that scenario.

This produces, per scenario, a vector of 58 categorical values (Healthy / Degraded / Lost / No Flow, encoded 1-4). Running every single-fault mode (193 scenarios) plus every ordered pair of faults (two orderings, since which fault hits first can change the outcome) produced 37,299 total simulated fault scenarios, which collapsed to 3,509 functionally-unique system states after removing duplicates (e.g., many different pairs of load-side sensor faults produced identical downstream effects because the controller never consulted those particular sensors).

What the propagation revealed

Applying two independent clustering techniques to the 3,509 unique system states — a modified k-means using a "functional distance" metric (Healthy↔Degraded = 1 unit, Healthy↔Lost = 2 units, Lost≡No Flow = 0 units apart) and a Latent Class Analysis (LCA) treating the health states as a probabilistic model — both methods converged on the same finding: the EPS's failure behavior collapses into five or six recurring failure "classes", not 3,509 unique behaviors. Concretely, clusters corresponded to things like "first load bank lost" or "second battery bank disconnected," each involving a whole cascade of downstream functions (breakers, inverters, fan/pump/light relays) failing together as a bundle — because they are all causally downstream of the same upstream fault in the function-flow graph.

Practically useful outcome: comparing the seven designed software-control states (Table 1 in the paper) against the discovered failure clusters showed the existing control logic handled four of the six discovered failure-behavior classes but had no specific recovery action for two of them — a concrete, actionable design gap surfaced purely by FFIP-style function-flow propagation simulation, before any physical prototype existed.

The nuclear power plant application

FFIP-based analysis has also been demonstrated on a substantially more complex system: nuclear power plant design, per Papakonstantinou, Jensen, Sierla & Tumer (2011), "Capturing interactions and emergent failure behavior in complex engineered systems and multiple scales" (ASME Design Engineering Technical Conferences), and Sierla, Tumer, Papakonstantinou, Koskinen & Jensen (2012), "Early integration of safety to the mechatronic system design process by the functional failure identification and propagation framework," Mechatronics (doi:10.1016/j.mechatronics.2012.01.003). These papers are cited in Jensen et al. (2014) as evidence that "the FFIP analysis has also been demonstrated on a more complicated system (nuclear power generation)," though the accepted-manuscript excerpt retrieved for this knowledge base does not include the nuclear plant's own methodological detail — only the EPS worked example is presented at length in the source retrieved here. A separate paper, "An Example of Functional Failure Identification in the Design of a Nuclear Power Plant," exists in the FFIP literature (identified via ResearchGate search) but full text was not retrievable for this knowledge base; readers wanting the nuclear case study's specifics should consult that paper directly.

Why the clustering step exists (beyond FFIP itself)

FFIP by itself just gives designers a single fault scenario's health-state vector at a time. The genuine contribution of Jensen, Bello, Hoyle & Tumer (2014) is showing that once you batch-run FFIP across a large combinatorial set of fault scenarios, data-mining/clustering the outputs converts a mountain of individual simulation results into a small number of named system-level failure modes an engineer can actually reason about and design against — effectively automating a step that otherwise requires an expert's tacit system knowledge to perform by hand. This is presented as a way to bridge "top-down" safety methods (like Leveson's STAMP, which start from unsafe system states and work down) and "bottom-up" methods like FFIP (which start from component faults and simulate upward) — the clusters are where the two meet.