Features/MCP Workflows/Excel/Design FMEA from architecture

Design FMEA from architecture

A Design FMEA is a walk of your architecture asking what breaks and what happens next. The architecture is already in the model, so this does the walk for you and brings a practitioner's instincts to it.

ExcelRead-only

The problem this solves

FMEAs live in a spreadsheet cut off from the design, so they go stale as soon as the architecture changes. They are also done under time pressure, and it shows: detection ratings drift optimistic, shared power and data buses get overlooked, and the RPN ranking says more about who filled in the row than about risk.

How it works

Draft a Design FMEA from your architecture and export it to Excel.

01
Walk the architecture
Every part, port, and connection is walked. Shared buses, supplies, and environments are flagged as common-cause candidates.
02
Derive failure modes
For each part: loss of function, degraded function, unintended function, and modes that come from what it actually connects to.
03
Rate honestly
Severity, occurrence, and detection, each with the reasoning written down. Detection is argued rather than assumed, which is where most FMEAs quietly fail.
04
Rank and export
RPN calculated, top ten flagged, and the whole table exported to Excel for your review.

The prompt

Walk the architecture of [model name] and draft a Design FMEA the way an experienced practitioner would: single-point failures first, suspicion of common-cause failures across shared buses and supplies, honest detection ratings. For each part: failure modes, effects, severity, occurrence, detection, RPN. Export as Excel and flag the top 10 RPNs.

Replace the [bracketed] placeholders with your model and project names.

Example output

The structure and functions sheet of a generated Design FMEA, listing each part with its level, the function attributed to it, where in the model that function came from, and the requirements allocated to it.
Functions are taken from the model, never invented: each one cites the Action, connection flow, part attribute or allocated requirement it came from. Parts the model cannot justify a function for are listed as such at the bottom rather than filled in.
The worksheet of a generated Design FMEA, showing current detection controls, a detection rating, the justification for it, RPN, the recommended action, whether the mode is a single point failure, and its common cause group.
Detection is argued rather than assumed. Each rating names the test case behind it, or says plainly that the model holds no detection evidence, and the rows carry through to a single-point-failure flag and a common-cause group.

What you get

Design FMEA table (.xlsx)
Common-cause failure candidates
Top 10 RPN list with reasoning
Dalus + Excel

The FMEA is produced as an Excel workbook matching the columns your safety process already uses. Attach your existing FMEA and the agent follows its format and rating scales.

Outputs are drafts for expert review. This workflow supports, and does not replace, qualified safety and certification engineering.

Common questions

Is this a certifiable FMEA?
No. It is a draft for expert review, and the output says so. It removes the blank-page and transcription work; a qualified safety engineer still owns the analysis.
Does it connect to hazards and requirements?
Yes. Failure modes can be linked to the hazards and requirements already in the model, which is what keeps the FMEA alive when the design changes.
What about ISO 26262 or IEC 61508 formats?
Ask for the terminology and rating scales of the standard you work to. For clause-level work, attach your licensed copy of the standard.

More Excel workflows

Excel requirements import

Import every row of your spreadsheet as a requirement, with your IDs kept exactly.

Bill of materials from the architecture

An engineering BOM out of the part hierarchy, with every empty field counted rather than filled.

Budget and margin report

Any resource rolled up the hierarchy, with the margin stated against how real the data underneath is.