Skip to main content

Design and Process FMEA

What it does​

Generates a complete Design FMEA — failure modes, effects, causes, controls, RPN, recommended actions — for any artifact in the hierarchy.

DFMEA for a flight-computer MCU board: a tree of systems, functions and failure modes each carrying an RPN badge, alongside a detail pane showing the selected subsystem's functions with their individual RPNs and failure-mode counts

The tree carries RPN at every level, so the worst branch is visible without opening anything — here the Communication Interfaces subsystem at max RPN 144. Note the banner: AI output is labelled an unverified draft requiring human acceptance, and the analysis is retained as a controlled record.

Why it matters​

A traditional DFMEA workshop runs 2–3 days with 4–6 engineers. Creopus drafts the same artifact in under 5 minutes, then engineers spend an hour refining instead of three days creating.

How it works​

  1. Open a subsystem or assembly in the hierarchy.
  2. On its Artifacts tab, choose DFMEA under Generate from Requirements — or open the DFMEA tool, pick the node, and choose Generate with AI (or Build it yourself to start blank or import a CSV).
  3. AI reads linked artifacts (requirements, block diagram, BOM) and proposes failure modes per component/function.
  4. Each row includes: failure mode, effect, severity, cause, occurrence, current controls, detection, RPN, recommended actions.
  5. Submit for review. Reviewers can request specific failure modes be reconsidered or expanded.

Key capabilities​

  • Cross-artifact awareness — uses requirements + BOM + block diagram as input.
  • Live RPN and Action Priority — RPN = S×O×D recalculates as you edit, alongside the AIAG-VDA Action Priority, so a high-severity item can't hide behind a low RPN.
  • Severity-based filtering for review priority.
  • Implement on review — accept a reviewer comment and AI patches the FMEA row.

Process FMEA​

PFMEA is a separate tool alongside DFMEA, for failure modes in the manufacturing and assembly process rather than the design. Same structure, same review workflow, same hierarchy linking — but scoped to process steps rather than components and functions.

Use DFMEA for "what can go wrong with this design", PFMEA for "what can go wrong when we build it".

Where findings go next​

An FMEA is only worth the actions that come out of it, so the failure modes do not stay trapped in the document:

  • Risk Register — carry high-RPN failure modes into the Risk Register as programme-level risks, so a design finding reaches the people tracking programme risk. There is no one-click import yet: add the risks yourself, or name them in the Risk Register's generation prompt or a follow-on.
  • Control Plan — the Control Plan tool's Derive from PFMEA adds a control row for every High/Medium Action-Priority (or safety-critical / special-characteristic) PFMEA cause, carrying its controls and risk ID.
  • CAPA — a failure mode that has actually occurred can be escalated into a Corrective and Preventive Action record with its own status workflow, linked back to its source.

This is the difference between an FMEA that gets filed and one that gets acted on.