Dfmea for a first prototype: a design fmea walkthrough, and where AI helps
A design FMEA is the cheapest place to break your product. Run on a first prototype, it tells you which failures matter, what to change before the next build, and which tests the prototype must pass. Here is how we run a DFMEA for prototypes using the AIAG-VDA steps, why Action Priority beats a simple RPN, and where AI genuinely speeds it up.
October 29, 202610 min read
Written by Konstantin Dolgan, Ph.D., NPDP
Founder & CEO, Product Development Engineer
Published October 29, 2026
What is a Dfmea, and How is it Different from a Pfmea?
A DFMEA is a design failure mode and effects analysis: a structured review of how a product's design could fail to perform its functions, the effects of each failure, and the causes.
The international standard IEC 60812:2018 describes FMEA as a systematic method for identifying modes of failure together with their effects, locally and globally, so that treatments can be identified, and it applies to hardware, software, processes including human action, and their interfaces (IEC 60812:2018).
A PFMEA (process FMEA) asks the same questions about manufacturing and assembly instead of the design.
SAE International's FMEA standard, SAE J1739, covers both: DFMEA for design, PFMEA for manufacturing and assembly processes, plus a supplemental FMEA for monitoring and system response (SAE J1739, revised January 2021).
SAE superseded that revision with J1739_202605 in May 2026 (SAE J1739_202605), and the scope still covers DFMEA, FMEA-MSR, and PFMEA. For a first prototype, start with the DFMEA. The PFMEA becomes important when you prepare for pilot builds.
One limit is worth knowing up front. IEC 60812 notes that, as a generic standard, it does not give specific guidance for safety applications. A DFMEA is one tool in a reliability and safety program, not the whole program.
Why Run a Dfmea on your First Prototype?
Before a prototype exists, a DFMEA is mostly educated guessing. After the first functional prototype, you have parts to examine, assemblies that did or did not go together, and early test results. That is the moment the analysis becomes useful and still cheap to act on, because nothing is tooled yet.
How we time it on projects:
- Concept stage: a light, half-page risk list is enough. For the concept-stage version of this method, see our guide to design failure mode analysis.
- First functional prototype: run the full DFMEA described here. Its output drives the changes and the test plan for the next build.
- Each later build and each review: update the same DFMEA with test results, and bring it to every engineering design review as part of the review package.
- Before design freeze: confirm that every high-priority item is closed or justified. See design freeze.
The 7 Dfmea Steps, Applied to a Prototype
The AIAG and VDA FMEA Handbook, released in 2019 by the Automotive Industry Action Group and the German automotive association VDA, organizes FMEA in seven steps (AIAG; AIAG & VDA FMEA Handbook). It was written for automotive suppliers, but the structure works for any hardware product. This is how we apply each step to a first prototype.
Step | What it means for a first prototype | Output |
|---|---|---|
1. Planning and preparation | Decide what the DFMEA covers (whole product, or one risky subsystem), who is on the team, and when it must be done (before the next build is ordered) | Scope, team, deadline |
2. Structure analysis | Break the prototype into system, subsystems, and parts, including bought-in parts you treat as black boxes. A block or boundary diagram and the BOM help | Structure tree, interfaces |
3. Function analysis | Write what each element must do, with requirements attached ("seal must keep water out at the rated spray test") | Functions and requirements |
4. Failure analysis | For each function, write the failure chain: failure mode, its effect, and its cause | Failure chains |
5. Risk analysis | List current prevention controls (design rules, calculations, simulation) and detection controls (tests), then rate severity, occurrence, and detection with the handbook tables and look up Action Priority | S, O, D and AP for each chain |
6. Optimization | Assign actions for high and medium priority items: change the design, add a test, or justify current controls. Each action gets an owner and a date | Action list |
7. Results documentation | Record what changed and why, and share it with the team, investors, or the manufacturer as needed | DFMEA report, updated test plan |
Steps 2 and 3 are where prototype teams save the most time. If the functions and requirements are vague, the failure modes will be vague too. If you are not sure the requirements are testable yet, fix that first.
A Dfmea Example from a Prototype (Illustrative)
Here is what a few rows look like for a hypothetical battery-powered handheld device. It is an illustration of the format, not data from a real project, and it leaves out the S, O, D ratings on purpose: those depend on your product, your users, and the rating tables you adopt.
Element and function | Failure mode | Effect | Cause | Prevention control (design) | Detection control (prototype test) |
|---|---|---|---|---|---|
Enclosure seal: keep water out | Water reaches the PCB | Device shuts down or corrodes | Gasket compression too low at one corner | Compression calculation, gasket design guide | Spray test on prototype units, then inspect the board |
USB-C port: carry charge current | Intermittent charging | User cannot charge | Solder joints crack from plug forces | Through-hole or shell-anchored connector, board support near the port | Repeated insertion and side-load test, then continuity check |
Battery pack: supply power safely | Cell overheats | Burn or fire risk | Charge current set too high in firmware | Charger IC limits, firmware review against cell datasheet | Charge test with thermocouples at worst-case ambient |
Snap fits: hold housing closed | Snap breaks on reassembly | Housing loose, ingress | Sharp root, brittle material | Root radius rule, material choice | Repeated open and close cycles on printed and machined parts |
Notice that the last column is a list of tests. That is the main payoff of a DFMEA for prototypes.
Action Priority VS Rpn: How to Decide What to Fix First
For decades, many teams multiplied severity, occurrence, and detection (each rated 1 to 10) into a risk priority number, or RPN, and acted on anything above a cutoff.
The AIAG and VDA FMEA Handbook replaced RPN with Action Priority (AP) tables (AIAG).
The handbook explains why: RPN gives equal weight to severity, occurrence, and detection, so very different combinations can produce similar numbers, and it states that using an RPN threshold is not a recommended practice for deciding when action is needed.
AP was built to give more emphasis to severity first, then occurrence, then detection (AIAG & VDA FMEA Handbook, section on Action Priority).
A quick arithmetic example shows the problem. A cosmetic issue rated S 3, O 10, D 4 has an RPN of 120. A safety issue rated S 10, O 4, D 2 has an RPN of 80. Sorting by RPN puts the cosmetic issue first. Action Priority does not, because severity dominates.
What the AP levels mean, per the handbook:
- High: the team must identify an action to improve prevention or detection, or justify and document why current controls are adequate.
- Medium: the team should identify an action, or at the company's discretion justify and document why controls are adequate.
- Low: the team could identify actions.
The handbook also recommends that potential severity 9 to 10 effects with high or medium AP be reviewed by management. On a startup project, "management" is usually the founder, and that review is worth the hour.
From Dfmea to Prototype Test Plan
SAE describes its 2021 revision of J1739 as adding more information about how information flows from the DFMEA to validation planning (SAE J1739). In practice, that flow is simple:
- Every detection control in the DFMEA becomes a named test in the prototype test plan, with a pass criterion tied to a requirement.
- Every high-priority action either changes the design for the next build or adds a test that proves the current design is good enough.
- Test results flow back into the DFMEA: occurrence ratings are updated with what you actually saw, and new failure modes found in testing are added.
The DFMEA is not the test plan itself, but it tells you what the test plan must cover. For the test stages that follow, see stages of product testing and their purposes, design-for-fail-fast structured failure testing, board bring-up for the electronics, and hardware beta testing once units go to real users.
Where AI Helps with a Dfmea, and Where it Does not
AI is good at the parts of a DFMEA that are about listing and summarizing, and weak at the parts that are about judgment. Published research is early, but it points the same way.
- Drafting content: IBM researchers built a system that uses large language models, guided by experts and by examples retrieved from a library of existing FMEAs, and found it could correctly generate over half of an FMEA's key content. Without good examples, results were far weaker, and the authors stress that reliability engineers must supervise the output (Lynch et al., FMEA Builder, arXiv 2411.05054). Their FMEAs are for equipment maintenance, not product design, so treat this as a direction, not a benchmark for your product.
- Mining failure data: a 2025 Design Society paper fed public NHTSA vehicle recall data to an AI chatbot and found that results grounded in that data were more specific and used more appropriate technical terms than results without it. The author calls designer review of the output a crucial step to catch AI hallucinations (Renu, ICED25, Proceedings of the Design Society).
- Rating risk: a 2025 RAMS paper on ChatGPT-assisted FMEA found the model could suggest relevant failure modes, but its predictions of severity, occurrence, and detection values were inconsistent (Enhancing FMEA with ChatGPT, RAMS 2025).
How we split the work:
DFMEA task | Where AI can help | What engineers must own |
|---|---|---|
Structure and functions (steps 2 and 3) | Draft a structure tree and function list from the BOM, drawings, and requirements | Whether the structure and requirements are right and complete |
Failure modes and causes (step 4) | Suggest failure modes and causes you may have missed; summarize similar products' recalls and complaints | Which failure chains are physically possible for this design |
Public failure data | Cluster and summarize records from CPSC recalls (consumer products) or FDA MAUDE (medical devices) | Interpreting them correctly: FDA says MAUDE reports are not intended to evaluate adverse event rates, so they are not occurrence data |
Ratings and Action Priority (step 5) | Flag inconsistent ratings across similar rows | Every S, O, and D rating, and the AP decision |
Actions and test plan (steps 6 and 7) | Draft test procedures and reports from the action list | Design changes, pass criteria, and sign-off |
NIST's Generative AI Profile names the main risk of AI-generated output confabulation: confidently stated but erroneous or false content.
It also warns about automation bias and about exposing trade secrets through AI tools (NIST AI 600-1).
For a DFMEA, that means two rules: never let an AI tool set a severity rating, and check a tool's data terms before uploading CAD, schematics, or test data. For a tool-by-tool view, see AI tools for hardware prototyping in 2026.
Dfmea for Medical and safety-critical Prototypes
If the product is a medical device, a DFMEA is a useful input, but the governing framework is risk management under ISO 14971:2019, which covers identifying hazards, estimating and evaluating risks, controlling them, and monitoring the controls across the whole device life cycle (ISO 14971:2019).
Plan the DFMEA so it feeds that file instead of living beside it. See our guide to FDA QMSR for medical device founders. For robots and other machines with their own safety standards, see robotics product development.
Common Dfmea Mistakes on Prototype Projects
- Starting at failure modes. Skipping structure and function analysis produces long, vague lists.
- Writing causes as "operator error" or "bad part." A useful cause points to a design decision you can change.
- Sorting by RPN and stopping at a cutoff. Use Action Priority so high-severity items are not buried.
- Treating it as paperwork. If the DFMEA did not change the design or the test plan, it was not used.
- Never updating it. Test results, field feedback from beta units, and every engineering change order should flow back into it.
- Letting AI fill in the ratings. Use AI for drafts and data mining; keep ratings and decisions with engineers.
Dfmea for Prototypes Checklist
Plan
- Scope set: whole product or the riskiest subsystems first
- Team includes mechanical, electrical, firmware, and someone who knows the users
- Deadline set before the next prototype build is ordered
Analyze
- Structure tree and interfaces drawn from the current BOM
- Every function has a measurable requirement
- Failure chains written as mode, effect, cause
- Prevention and detection controls listed for each chain
- S, O, D rated with one agreed set of tables; AP looked up, not calculated
Act
- Every high AP item has an action, owner, and date, or a documented justification
- Severity 9 to 10 items with high or medium AP reviewed by the project lead
- Detection controls copied into the prototype test plan with pass criteria
AI and data
- AI used for drafts and data summaries only, with engineer review of every row
- Tool data terms checked before uploading design files
- Public recall or complaint data used to find failure modes, not to estimate rates
Close the loop
- Test results update occurrence ratings and add new failure modes
- DFMEA brought to each design review and checked before design freeze
- PFMEA started before pilot builds; see what breaks from prototype to pilot production
How LA NPDT Runs Dfmea on Prototypes
LA NPDT does design, engineering, and prototyping in-house at our facility in Ruston, Louisiana: 3D printing, CNC machining, urethane casting, and bridge tooling, plus electronics and firmware.
That matters for a DFMEA, because the people rating a failure mode can walk over to the prototype, take it apart, and run the detection test the same week. We use AI to speed up the first draft and to sort through public failure data, and we keep the ratings, the priorities, and the design decisions with our engineers.
Our view is practical: a DFMEA earns its time only when it changes the next prototype or the test plan. If it does neither, it is too generic.
If you have a first prototype and want an engineer's view of what could fail and what to test next, see our product development services and rapid prototyping, or book a free initial consultation. Phone: +1 318-200-0526.
First prototype on the bench?
Talk with an engineer about what could fail, what to change before the next build, and what to test. Phone: +1 318-200-0526.
Sources
Frequently asked questions
What is a Dfmea?
A DFMEA (design failure mode and effects analysis) is a structured review of how a product's design could fail to perform its functions, the effect of each failure, and its causes. The team then prioritizes the risks and changes the design or adds tests before tooling.
When Should You Do a Dfmea on a Prototype?
Run a full DFMEA right after the first functional prototype exists and before the next build is ordered. Update it with test results after every build, bring it to each design review, and close high-priority items before design freeze.
What are the 7 Steps of a Dfmea?
The AIAG and VDA FMEA Handbook uses seven steps: planning and preparation, structure analysis, function analysis, failure analysis, risk analysis, optimization, and results documentation.
What is the Difference Between Action Priority and Rpn?
RPN multiplies severity, occurrence, and detection, giving each equal weight. Action Priority uses lookup tables that weigh severity first, then occurrence, then detection, and assigns high, medium, or low priority for action. The AIAG and VDA handbook replaced RPN with Action Priority.
What is the Difference Between Dfmea and Pfmea?
A DFMEA analyzes how the product design can fail. A PFMEA analyzes how the manufacturing and assembly process can fail. Prototype teams start with the DFMEA and add a PFMEA before pilot production.
Can AI Do a Dfmea?
AI can draft structures, functions, and failure modes and summarize recall or complaint data, which saves time. Studies so far show it misses content and rates risk inconsistently, so engineers must review every row and own the ratings and decisions.
Services related to this guide
- Best prototyping companiesDevelopment firms, instant-quote bureaus and local shops — who fits which job.
- Free prototype cost calculatorFive to eight questions, an instant cost range for a first prototype.
- Prototype development companiesWhich firms take a sketch to a working prototype — and which only fabricate parts.
- Rapid prototypingWorking prototypes in days, from 3D printing to vacuum casting.
