视觉画布设计
canvas-design
基于设计原则创作静态视觉作品,用于海报与品牌图形。
pfmea-process【文档与办公】Build a PFMEA worksheet, process risk analysis, or AP table using the AIAG-VDA FMEA Handbook 2019 7-step approach. Covers Structure Analysis, Function Analysis, Failure Analysis, Risk Analysis (Action Priority H/M/L), Optimization, and Documentation. Required by IATF 16949 and OEM customer-specific requirements for new processes, process changes, and…
独立 GitHub 快照 · 自动分类 · 以原作者文档为准
Identify and prioritise process risk before production — using the AIAG-VDA 2019 7-step approach — so that high-priority failure modes are eliminated or controlled before they reach the customer, and the result feeds directly into the Control Plan and Work Instructions.
Define the scope:
Prepare:
Map the process hierarchy:
Process Item (e.g., Steering Column Assembly Line)
└── Process Step (e.g., Station 3 — Torque tightening)
└── Work Element (e.g., Pneumatic driver, torque wrench)
For each process step, identify the 4M inputs: Man, Machine, Method, Material.
This structure becomes the "what can go wrong" framework in Step 4.
Consistency check: Every Process Step defined here must have at least one Function defined in Step 3. A process step with no function is incomplete — it cannot be analysed for failure in Step 4.
For each process step and work element, define:
Functional chain:
Work Element function → Process Step function → Product Characteristic
(tool applies torque) → (bolt is tightened to spec) → (joint meets strength requirement)
For each function, identify the failure chain: Failure Effect → Failure Mode → Failure Cause
Work in this direction (Effect first, then Mode, then Cause):
Failure Effect (FE): what is the impact on the customer (internal or end user)?
Failure Mode (FM): how does this process step fail to perform its function?
Failure Cause (FC): what causes the failure mode?
Multiple causes per failure mode are normal — each FC gets its own row.
Failure Cause validation: Failure Causes must be supported by objective evidence or structured root cause analysis (e.g., 5-Why). Unverified assumptions — "probably," "may be," "could be" — must not be entered as final Failure Causes. For post-escape PFMEA updates, the FC must match the validated root cause from the 8D or CAPA, not a revised opinion.
For each FC row, assign three ratings:
| S | Effect |
|---|---|
| 10 | Safety — affects operator safety without warning |
| 9 | Regulatory non-compliance |
| 8 | Loss of primary function (end user) |
| 7 | Reduced primary function |
| 6 | Loss of comfort / convenience function |
| 5 | Reduced comfort / convenience function |
| 4 | Appearance issue — noticed by most |
| 3 | Appearance issue — noticed by some |
| 2 | Appearance issue — noticed by discriminating |
| 1 | No effect |
Severity rates the EFFECT, not the mode or cause. S=10 or S=9 means you must act regardless of O and D.
| O | Failure Rate |
|---|---|
| 10 | ≥ 1 in 2 |
| 9 | 1 in 8 |
| 8 | 1 in 20 |
| 7 | 1 in 80 |
| 6 | 1 in 400 |
| 5 | 1 in 2,000 |
| 4 | 1 in 15,000 |
| 3 | 1 in 150,000 |
| 2 | 1 in 1,500,000 |
| 1 | Failure eliminated by prevention control |
O considers prevention controls already in place (poka-yoke, SPC, incoming inspection of material).
| D | Detection |
|---|---|
| 10 | No detection control |
| 9 | Control unlikely to detect |
| 8 | Control may detect |
| 7 | Control has low chance of detection |
| 6 | Control may detect — moderate |
| 5 | Control likely to detect |
| 4 | Control has good chance of detection |
| 3 | Control almost certain to detect |
| 2 | Control certain to detect — automatic rejection |
| 1 | Failure mode cannot occur (prevented) |
D considers detection controls already in place (gauging, inspection, poka-yoke).
Use the AP table (see action-priority-ap skill for full table):
| AP | Meaning | Required action |
|---|---|---|
| H (High) | Action required | Assign responsible owner + target date. Escalate if no improvement possible. |
| M (Medium) | Action recommended | Team should evaluate — reduction may be beneficial |
| L (Low) | No action required | Document rationale for no action |
Critical rule: S = 9 or 10 → AP is always H regardless of O and D.
Ratings discipline: All S/O/D ratings must be agreed by the cross-functional team — not assigned unilaterally by one engineer. Where team members disagree, document the rationale for the rating chosen. Ratings without team consensus are not acceptable for PPAP submission or customer OEM review.
For every H-AP item: define a corrective action.
For each action:
Priority for action type:
Avoid the common trap of only improving detection (lowering D) — this catches defects but doesn't prevent them.
Tracking discipline: All actions must be logged in the PFMEA and tracked to closure with objective evidence (completed action description + implementation date + revised S/O/D ratings). Open H-AP items past their target date must be escalated to management with a documented reason for delay and a revised target date. A PFMEA with overdue open H-AP items is not acceptable for PPAP submission or OEM audit.
Final PFMEA deliverables:
PFMEA → Control Plan linkage: Every detection control in the PFMEA must have a corresponding entry in the Control Plan. Every prevention control must be reflected in the Work Instruction.
Before releasing the PFMEA:
At the start of each use, ask the user:
"How would you like to receive the output? A — Structured Markdown (formatted tables and sections, ready to copy) B — Plain tables (simplified structure for Excel or Word) C — Narrative report (flowing text for a formal document or email)
Default: A."
Adapt all output sections to the chosen format. If the platform or session context already defines a format preference, skip this question.
| Version | Date | Author | Change |
|---|---|---|---|
| 1.0 | 2026-06-01 | @RBraga01 | Initial release |
| 1.1 | 2026-06-03 | @RBraga01 | Expanded 7-step workflow with AP gate requirements and PPAP integration |