DFMEA와 PFMEA관계

ISO 26262 기능 안전 표준에서 DFMEA(설계 FMEA)와 PFMEA(공정 FMEA)는 상호 보완적인 관계이며, 설계 의도가 제조 과정에서 변질되지 않고 기능 안전 목표를 달성하도록 연결됩니다. 

1. DFMEA와 PFMEA의 핵심 관계

• DFMEA (Design Intent): "제품이 어떻게 고장 날 수 있는가?"에 집중하며, 안전 목표(Safety Goal) 달성을 위한 설계적 대책을 수립합니다.
• PFMEA (Manufacturing Reality): "제조 과정에서 설계 의도를 어떻게 해칠 수 있는가?"에 집중하며, 공정 산포나 오류로 인해 DFMEA에서 정의한 안전 특성이 훼손되지 않도록 관리합니다. 

2. 실무적인 정보 흐름 및 활용 

실무적으로 두 분석은 다음과 같이 정보를 주고받으며 결과를 만들어냅니다.

정보 흐름 주요 내용 및 실무적 활용

DFMEA → PFMEA (전달)	특별특성(CC/SC) 전달: DFMEA에서 정의된 치명적 특성들이 PFMEA로 전달되어 공정상 필수 관리 항목이 됩니다. 심각도(Severity) 공유: DFMEA의 고장 영향 심각도 점수는 PFMEA에서도 동일하게 적용되어 공정 위험도 평가의 기준이 됩니다.
PFMEA → DFMEA (피드백)	제조 한계 반영: 공정상 도저히 관리 불가능한 오조립 위험이 발견되면, DFMEA팀에 피드백하여 '실수 방지(Poka-yoke)'가 가능한 설계로 변경을 요청합니다.
공동 활용	검출 전략 수립: DFMEA에서 설계로 막지 못한 위험을 PFMEA의 검사 공정(비전 검사, EOL 테스트 등)에서 최종 확인하도록 전략을 짭니다.

3. 결과물 생성 과정 (ISO 26262 맥락)

1. ASIL 등급의 전파: DFMEA에서 결정된 ASIL 등급에 따라 PFMEA의 공정 관리 수준이 결정됩니다. (예: ASIL D 부품은 더 엄격한 전수 검사 및 공정 인터록 요구)
2. Control Plan(관리계획서) 도출: PFMEA의 결과는 최종적으로 생산 현장의 관리 지침인 Control Plan으로 이어지며, 이는 DFMEA의 안전 요구사항이 실제 제품에 구현되었음을 보증하는 근거가 됩니다.
3. Traceability(추적성) 확보: ISO 26262 심사 시, "설계 시 고려된 안전 메커니즘이 공정에서 어떻게 누락 없이 관리되는가"를 DFMEA와 PFMEA 간의 연결성으로 증명해야 합니다. 

실무적으로 DFMEA는 "올바른 설계"를 보장하고, PFMEA는 "설계대로 올바르게 생산"함을 보장하여 최종적으로 차량의 기능 안전을 완성합니다. 

 

근데 그 DFMEA는 이미 요구사항 개발 단계에서 SYS, SW, HW각 수준에서의 안전 분석 활동의 자료(FTA, FMEA, DFA, FMEDA)를 통틀어 말하는거 아니야?

 

 

 

실무적으로 혼동하기 쉬운 부분입니다. 결론부터 말씀드리면, DFMEA는 ISO 26262에서 요구하는 전체 안전 분석 활동 중 하나일 뿐이며, 모든 분석을 통칭하는 용어는 아닙니다.

하지만 질문하신 의도처럼 "설계 단계의 위험을 분석한다"는 측면에서 실무자들은 이를 묶어서 생각하는 경향이 있습니다. 이를 명확히 구분하면 다음과 같습니다.

1. DFMEA와 다른 분석 도구의 차이 (ISO 26262 관점)

ISO 26262에서는 정성적 분석(Qualitative)과 정량적 분석(Quantitative)을 요구하며, DFMEA는 대표적인 정성적 분석 도구입니다.

• FMEA (DFMEA): 주로 Bottom-up 방식입니다. "부품 하나가 고장 나면 시스템에 어떤 영향을 줄까?"를 분석하며, 단일 지점 고장(Single Point Failure)을 찾는 데 탁월합니다. (SYS, HW, SW 각 수준에서 개별적으로 수행됨)
• FTA (Fault Tree Analysis): Top-down 방식입니다. "브레이크가 안 듣는 최악의 상황(Top Event)이 발생하려면 어떤 하위 고장들이 조합되어야 하는가?"를 분석합니다. 조합 고장(Multiple-point Failure) 분석에 필수적입니다.
• DFA (Dependent Failure Analysis): 두 기능이 서로 독립적이어야 하는데, 하나의 원인으로 동시에 망가지는 '공통 원인 고장'을 분석합니다.
• FMEDA: HW 수준에서 수행하며, DFMEA에 '고장률(FIT)' 데이터를 입혀 정량적으로 목표 달성 여부를 계산하는 활동입니다.

2. 실무적으로 왜 섞여서 인식되는가?

실무에서 "DFMEA 자료를 가져와라"고 할 때, 위 활동들이 엮이는 이유는 다음과 같은 데이터의 흐름 때문입니다.

1. 계층 구조: SYS FMEA의 결과가 HW FMEA의 입력값이 되고, SW FMEA와 인터페이스를 맞춥니다. 이 전체 설계 분석 과정을 통칭해 'DFMEA 활동'이라 부르기도 합니다.
2. Safety Analysis Report: ISO 26262 심사 대응 시, DFMEA, FTA, DFA 결과를 하나의 안전 분석 보고서로 묶어서 제출하는 경우가 많습니다.
3. 상호 보완: FTA를 하다가 발견 못한 고장 모드를 DFMEA에서 찾고, DFMEA에서 분석된 심각도를 FTA의 Top Event 설정에 활용합니다.

3. PFMEA와의 관계에서 본 DFMEA (핵심 답변)

질문하신 PFMEA와의 관계를 따질 때 말하는 "DFMEA"는, SYS/HW/SW 분석을 통해 도출된 '최종적인 설계 요구사항 및 특별특성(CC/SC)'의 집합체를 의미합니다.

• SYS/HW/SW FMEA 등: "이 반도체는 열에 취약하니 방열 설계가 필요해", "이 로직은 오류 시 Safe-state로 가야 해" 등의 설계 대책 수립.
• PFMEA로 넘어가는 것: 위 단계에서 도출된 결과 중 "제조 공정에서 반드시 지켜야 할 항목(예: 납땜 불량 방지, 특정 토크 체결, SW 버전 리라이팅 등)"이 PFMEA의 분석 대상이 됩니다.

요약하자면:
DFMEA는 안전 분석 활동의 일부(도구)이며, FTA/DFA/FMEDA와는 분석 방향과 목적이 다릅니다. 다만, PFMEA 입장에서는 이 모든 설계 분석 활동의 결과물(안전 특성)이 '설계팀이 준 숙제(DFMEA 결과)'로 보이기 때문에 통칭해서 인식될 수 있습니다.