좋아, 이건 Confirmation Review 담당자 입장에서 가장 까다롭고 중요한 영역이야.
아래 체크리스트는 OEM / Assessment Authority가 실제로 “Safety analysis가 안전 주장으로서 성립하는가”를 판단할 때 쓰는 수준으로 만들었어.
🎯 목표
“이 Safety Analysis 세트(FMEA / DFA / FMEDA)가
SYS–HW–SW 전 레벨에서
Safety Goal을 논리적으로 지지하는가?”
ISO 26262
Safety Analysis Documents
Confirmation Review Checklist
(FMEA / DFA / FMEDA, SYS / HW / SW 통합 관점)
ASIL B ~ D 기준
0. Confirmation Review 전제 조건 (Gate)
항목판단
| Confirmation Reviewer 독립성 충족 (ISO 26262-2) |
☐ |
| Safety Analysis 범위가 Safety Plan에 정의됨 |
☐ |
| 분석 대상 아이템 및 ASIL 명확 |
☐ |
| Safety Case 내 Evidence로 식별됨 |
☐ |
❗ 하나라도 NO → Review 중단 가능
1. Safety Analysis 체계성 (Overall Consistency)
항목판단
| SYS / HW / SW 분석이 계층적으로 연결됨 |
☐ |
| 동일 고장에 대해 상위–하위 분석 간 모순 없음 |
☐ |
| 분석 기법 선택 근거 명확 |
☐ |
📌 Reviewer 핵심 질문
“이 분석들은 ‘각자 따로’가 아니라 ‘하나의 논리’인가?”
2. System-Level Safety Analysis (SYS FMEA / DFA)
2.1 SYS FMEA 기본 구조
항목판단
| System element 정의 명확 |
☐ |
| 기능 단위로 분석 수행 |
☐ |
| Boundary 조건 명시 |
☐ |
2.2 System Failure Mode 정의
항목판단
| Failure Mode가 기능 상실/오동작 관점 |
☐ |
| “no output / wrong output / timing” 포함 |
☐ |
| 환경·운용 조건 고려 |
☐ |
❌ 부품 고장 나열 → SYS FMEA 아님
2.3 System Effect & Safety Goal 연계
항목판단
| System Effect가 Vehicle-level 영향까지 연결 |
☐ |
| Safety Goal 직접 또는 간접 연결 |
☐ |
| ASIL 할당 논리 명확 |
☐ |
2.4 DFA (Dependent Failure Analysis)
항목판단
| 공통 원인 고장(CCF) 식별 |
☐ |
| Shared resource 분석 |
☐ |
| Independence 가정 검증 |
☐ |
📌 Reviewer 질문
“이 두 고장이 정말 독립적이라는 근거는?”
3. Hardware Safety Analysis (HW FMEA / FMEDA)
3.1 HW FMEA 구조 적합성
항목판단
| HW architecture 반영 |
☐ |
| Safety-related HW 표시 |
☐ |
| Component-level 분석 수행 |
☐ |
3.2 Hardware Failure Mode 적절성
항목판단
| 물리적 고장 메커니즘 반영 |
☐ |
| 데이터시트 기반 failure mode 사용 |
☐ |
| Single-point / Latent fault 구분 |
☐ |
3.3 FMEDA 구성 적합성
항목판단
| Failure rate source 명시 |
☐ |
| Diagnostic coverage 계산 근거 명확 |
☐ |
| Safe / Detected / Undetected 분류 명확 |
☐ |
❗ “툴이 계산했다” → ❌
→ 논리 설명 필수
3.4 Safety Mechanism 분석
항목판단
| 메커니즘이 고장과 직접 연결 |
☐ |
| Detection latency 고려 |
☐ |
| Reaction 경로 정의 |
☐ |
📌 Reviewer 질문
“이 고장을 이 메커니즘이 왜 잡는다고 보는가?”
4. Software Safety Analysis (SW FMEA / DFA)
4.1 SW 분석 범위 정의
항목판단
| Safety-related SW component 식별 |
☐ |
| Execution context 정의 |
☐ |
| Interaction 대상 명확 |
☐ |
4.2 SW Failure Mode 적절성
항목판단
| 논리 오류 / 타이밍 오류 포함 |
☐ |
| Deadlock / starvation 고려 |
☐ |
| Interface misuse 포함 |
☐ |
❌ “SW는 고장 안 남” → Major Finding
4.3 SW DFA (Interference)
항목판단
| Memory / timing interference 분석 |
☐ |
| Shared resource 고려 |
☐ |
| Freedom from interference 근거 |
☐ |
5. Cross-Level Consistency (SYS–HW–SW)
항목판단
| SYS Failure Mode가 HW/SW로 분해됨 |
☐ |
| HW/SW 고장이 SYS Effect로 환원됨 |
☐ |
| 누락된 고장 없음 |
☐ |
📌 Reviewer 질문
“이 SYS 고장은 HW/SW 어디에서 발생 가능한가?”
6. Fault Model & Assumptions (Part 9)
항목판단
| Fault model 명확히 정의 |
☐ |
| 가정 사항 명시 |
☐ |
| 가정 검증 책임 명확 |
☐ |
❗ “Assumed correct by design” → ❌
7. ASIL & Decomposition 반영 여부
항목판단
| ASIL 적용 일관성 |
☐ |
| ASIL decomposition 조건 충족 |
☐ |
| Independence 증거 존재 |
☐ |
8. Production & Operation 영향 고려 (Part 7)
항목판단
| 생산 고장 반영 |
☐ |
| Calibration 오류 고려 |
☐ |
| Field misuse 가능성 |
☐ |
9. Safety Analysis 결과 활용성
항목판단
| Safety requirements 도출 근거 제공 |
☐ |
| Test case 입력으로 사용 가능 |
☐ |
| Safety Case 주장과 직접 연결 |
☐ |
10. Documentation Quality (Audit 관점)
항목판단
| 분석 논리 추적 가능 |
☐ |
| Reviewer 이해 가능 |
☐ |
| Copy-paste 흔적 없음 |
☐ |
11. Typical Confirmation Review Findings
유형설명
| 기능 안전 아닌 신뢰성 FMEA |
안전 영향 없음 |
| FMEDA 수치만 존재 |
논리 부재 |
| SYS–HW–SW 단절 |
논리 붕괴 |
| DFA 형식만 존재 |
내용 없음 |
12. Confirmation Review Conclusion
- ☐ Accept
- ☐ Accept with Findings
- ☐ Reject
핵심 판단 문장
“이 Safety Analysis는
안전을 ‘계산’한 것이 아니라
‘설명’하고 있다.”
YES → Accept
NO → Finding / Reject
🔑 실무에서 가장 중요한 한 문장
Safety Analysis는
‘고장을 찾는 문서’가 아니라
‘왜 이 시스템이 안전하다고 믿을 수 있는지’를 설명하는 문서다.