How MADe Implements the Functional Basis: Primary-Source Evidence

Why this document matters

Everything else in this knowledge base's taxonomy section is inferred connection between academic research and MADe's design. This document is different: it is a direct quote from PHM Technology's own 2008 technical paper that names the academic source MADe's functional vocabulary is built on. This closes the loop between the "Functional Basis" academic literature (see functional-basis-taxonomy.md) and MADe's actual product.

The paper — "The Maintenance Aware Design environment: Development of an Aerospace PHM Software Tool" — was authored by Andrew Hess, Jacek S. Stecki, and Shoshanna D. Rudov-Clark and marked "Proprietary Information — May 2008." Jacek Stecki is PHM Technology's co-founder, Chief Technology Officer, and originator of the MADe technology, with a research background at Monash University's Centre for Machine Condition Monitoring (correcting a common assumption that MADe traces to the University of Melbourne — the university lineage is Monash, in Melbourne, Australia). MADe was, at the time of this paper, "currently being developed for application to aerospace systems" with beta testing "due to commence in mid-2008," and its first customer was the Joint Project Office of the Joint Strike Fighter (JSF) program.

The direct citation

Describing MADe's Functional System Models, the paper states:

"Functional models are built by selecting generic MADe library components, known as functional areas, and linking them to create a block diagram. The links represent functional relationships between the components, and these functional relationships are expressed using the functional ontology developed by Stone and Wood [2]. The functional description is a two-part verb-noun statement which is formed by selecting one verb and one or more nouns from a standard list of terms."

Reference [2] in the paper's bibliography is:

Stone, R. B. and K. L. Wood (2000). "Development of a Functional Basis for Design." Journal of Mechanical Design 122(4): 359-370.

This is the direct academic ancestor of — and, after the 2002 NIST reconciliation, essentially synonymous with — the Functional Basis taxonomy documented in functional-basis-taxonomy.md. In other words: MADe's Functions Editor is a software implementation of the Stone & Wood / Hirtz et al. Functional Basis, not an independently invented vocabulary.

Worked example from the paper

The paper illustrates the verb-noun selection UI with a drive shaft: the user picks the function verb "Transmit" (found under the Channel class, alongside Allow degree of freedom, Export, Guide, Import, Rotate, Translate, Transport — exactly the Channel secondary/tertiary terms from the reconciled Functional Basis) and the flow noun "Mechanical" energy, yielding the function description "Transmit rotational energy." The paper's screenshot of the MADe Functions/Function Flows selection panel shows:

• Functions panel: Branch, Channel (Allow degree of freedom, Export, Guide, Import, Rotate, Transfer, Translate, Transport), Connect, Control Magnitude, Convert, Provide — matching the eight Functional Basis primary classes almost verbatim (MADe uses "Provide" where the 2002 paper's final reconciled term is "Provision").
• Function Flows panel: Material; Energy (Acoustic, Chemical, Electrical, Electromagnetic, Hydraulic, Magnetic, Mechanical, Pneumatic, Radioactive, Vibrational); Signal — again matching the reconciled flow taxonomy's secondary Energy categories, with "Vibrational" appearing as a MADe-specific addition not present in the 2002 paper's table.

How the taxonomy feeds MADe's reasoning engine

Per the same 2008 paper, this vocabulary is not just descriptive labeling — it is the substrate the failure-propagation engine operates on:

"MADe automatically converts the block diagram to a directed graph, known as a concept map, which is used to propagate flows through the system. The links between functions represent the causal relations between functional components and these are given strength weightings. Functional failures describe the deviation of the behaviour of a component from its intended purpose. This is achieved by stating the changes to the output flows specified in the function. Functional failures are propagated through the system model via the system Functional Concept Map which alters the input and output flows of each component in turn according to the causal linkages between the components and the system hierarchy levels."

This is the mechanistic core of why the Functional Basis vocabulary was necessary in the first place: because every function is defined as "verb acting on a flow," a failure can be formally defined as a deviation in that flow (the flow is missing, degraded, or wrong-type) — which is precisely the conceptual move that academic FFIP research (see ffip-framework.md) made a few years later and gave a name to ("Function Health States": Healthy / Degraded / Lost / No Flow).

MADe's parallel hardware/bond-graph track

MADe models systems two ways simultaneously: functional models (verb-noun, used for conceptual-stage FMEA) and hardware models (physical components like valves, batteries, and lines, converted automatically into bond-graph simulation models with dynamic state equations). The paper's hydraulic-relief-valve case study shows MADe generating actual bond-graph state equations from a hardware block diagram and running time-domain simulations of an "energy perturbation" (e.g., a failed flexible coupling) propagating through a Puma helicopter landing-gear system, producing a propagation analysis table of positive/negative/zero energy-level changes at each downstream component. This bond-graph layer is where the Functional Basis's "power conjugate" (effort/flow) pairs documented in functional-basis-taxonomy.md — torque/angular-velocity, pressure/volumetric-flow, temperature/heat-rate, etc. — become load-bearing: they are literally the variables MADe's automatically-generated bond graphs simulate.

Criticality and reliability layer

The same functional/hardware model backbone supports MADe's FMECA criticality analysis: Risk Priority Number (RPN), Criticality Number, and Failure Assessment Index, calculated per MIL-STD-1629A and the Reliability Analysis Center's FMECA report (CRTA-FMECA). Criticality is propagated from component level to system level using Failure Concept Maps (FCM) — the same causal-graph mechanism as the Functional Concept Map, but carrying occurrence/severity/detectability data instead of flow-state data. MADe calls the system-level-propagated occurrence value the "apparent occurrence" of a failure mode — "so named because it is the occurrence as viewed from the system-wide perspective."

Sensor optimization layer (MADe PHM)

Once a functional/failure model exists, MADe's PHM module uses it to solve a minimum sensor set problem: it builds a fault/symptom table (every fault mapped to its observable "diagnostic set" of energy-perturbation symptoms) and runs a minimization algorithm to find the smallest sensor set that still observes every fault — i.e., a fault is "observable" if at least one member of its diagnostic set is instrumented. This is the direct engineering payoff of having a formal, propagatable functional model: sensor placement becomes a graph-coverage optimization problem instead of an engineer's guess.

Bottom line

The taxonomy documented elsewhere in this knowledge base's taxonomy/ folder is not background trivia — it is, per PHM Technology's own primary documentation, the literal vocabulary MADe's UI exposes and the substrate its propagation/criticality/sensor-optimization algorithms compute over.