FMECA and Model-Based Diagnostics: Turning Failure Analysis Into Troubleshooting

Failure analysis and diagnosis answer different questions

Failure analysis asks what could fail, what the consequences would be, and how the design should address those risks. Troubleshooting asks what is causing the symptoms observed in a particular system now.

The two activities need some of the same system knowledge, but they do not produce interchangeable outputs. A completed failure-analysis worksheet is not automatically a service diagnostic model.

The opportunity is to reuse the engineering knowledge deliberately: connect modeled failure modes and their effects to observable evidence, executable tests, and appropriate next actions.

FMEA and FMECA are related, not identical

Failure mode and effects analysis (FMEA) examines failure modes and their effects. Failure modes, effects, and criticality analysis (FMECA) adds a criticality assessment according to the method used.

IEC 60812:2018 explains how FMEA, including the FMECA variant, is planned, performed, documented, and maintained. Teams should use the method and edition required by their own engineering, contractual, or regulatory context.

Severity, occurrence, detection assessments, and criticality measures have specific meanings within those methods. A risk-priority value or a high-severity rating is not, by itself, proof that a component caused the present incident. Diagnostic evidence must still distinguish that hypothesis from other explanations.

Translate analysis rows into diagnostic knowledge

Start with a reviewed failure mode and ask what additional information makes it usable during troubleshooting.

Failure-analysis input	Diagnostic translation
Item and intended function	Identify the relevant component, configuration, and operating state.
Failure mode	Define the behavior represented by the diagnostic hypothesis.
Local and system effects	Map how the fault could affect observations and dependent functions.
Detection method or existing control	Define the executable test, prerequisites, expected results, and limitations.
Cause information	Distinguish a failure mechanism from the component or assembly the service team can isolate.
Severity and criticality	Inform safe prioritization and escalation, without substituting for evidence.
Recommended action	Separate a design improvement from a validated service test or repair procedure.

The translation requires engineering judgment. A worksheet entry such as “detected during maintenance” does not specify a test threshold, the equipment needed, or what a failed test rules in or out.

Worked example: a switching device that does not close

Illustrative example, not a customer analysis or an asserted software-import capability. A simplified pump drive includes a switching device that should deliver the required input when commanded.

An analysis row might describe:

• Function: switch the pump's electrical supply when the operating command requires it.
• Failure mode: the switching path remains open.
• Local effect: the required pump input is absent.
• System effect: expected flow is not achieved.
• Detection opportunity: compare the valid command, the available upstream supply, and the approved output test.

The symptom “no flow” does not isolate that switching device. A missing upstream supply can produce the same effect, and a pump or measurement fault can also explain the system symptom.

A diagnostic model needs those alternatives and the relevant dependencies. If the supply test passes and the valid command is present, an approved output test can provide evidence about the switching path. If the supply is absent, the same output observation may say little about the switching device itself.

Finally, the model's resolution matters. Is the replaceable item the switching device, a control board, or a larger assembly? An isolated functional path does not automatically identify an internal part that the service procedure cannot test separately.

Define tests the service team can actually execute

For each proposed diagnostic test, document:

1. The product configuration and operating conditions to which it applies.
2. Required inputs, tools, access, and operator qualifications.
3. The approved procedure and safety prerequisites.
4. Expected outcomes and the hypotheses each outcome addresses.
5. What to do if the observation is unavailable, inconsistent, or inconclusive.
6. The verification procedure after the resulting repair.

For safety-critical functions, the response to a fault may require isolation or escalation before diagnostic work continues. An informative test is not automatically an acceptable field test.

The NASA Systems Engineering Handbook provides broader context for verification and validation. In this application, the diagnostic method needs both correct implementation and evidence that it supports the intended users and operational decisions.

Close the loop from service back to design

Service findings can reveal a failure mode omitted from the original analysis, an inaccurate effect relationship, an ambiguous test, or an unsupported operating condition.

Record the actual configuration, symptom, tests, confirmed repair, and post-repair result. Review that evidence before revising the failure analysis, diagnostic model, or service instructions. A part replacement alone is not always confirmation of the original diagnosis, especially if connectors, software, or operating conditions changed at the same time.

Keep the relevant revisions aligned. A model based on an earlier wiring or firmware configuration can apply the wrong dependencies even if the original reasoning was sound.

What should not be assumed

A diagnostic tool cannot recover engineering knowledge that was never captured reliably. Incomplete analysis, broad failure descriptions, and poorly defined tests leave ambiguity.

Nor should a generic workflow explanation be read as a claim that a particular product automatically imports every FMECA format, preserves every criticality method, or generates validated procedures without review. Confirm the specific supported workflow during a technical demonstration.

For the next step, read finding diagnostic gaps before launch and the practical guide to model-based diagnostics. Explore iTech's capabilities or discuss your analysis-to-service workflow.