이번에는 “Integration Test Strategy 문서”에 대해 Confirmation Review를 수행하는 체크리스트를 만들게.
관점은 명확히 ISO 26262 Confirmation Review 담당자 (Assessment Authority 아님) 기준이야.
즉, 질문의 초점은
❌ “테스트 잘 짰는가?”
❌ “테스트 커버리지 높나?”
✅ “이 전략이 ISO 26262에서 요구하는 ‘안전 통합 검증’의 최소 조건을 충족하는가?”
ISO 26262
Confirmation Review Checklist
Integration Test Strategy
(Part 4 / Part 5 / Part 6 + Part 8 / Part 9 연계)
ASIL B~D 기준
0. Confirmation Review 전제 조건 (Gate)
| Confirmation Reviewer 독립성 충족 (ISO 26262-2) | ☐ |
| Integration Test Strategy가 Safety Plan 산출물로 정의됨 | ☐ |
| 적용 범위(System / HW / SW) 명확 | ☐ |
| 대상 ASIL 명확히 선언 | ☐ |
❗ 하나라도 NO → Confirmation Review 수행 불가 가능
1. 문서 목적 & 범위의 명확성
| 통합 테스트의 목적이 “안전 요구 검증”으로 명시 | ☐ |
| 단위 시험/시스템 시험과의 경계 정의 | ☐ |
| 대상 통합 레벨 명확 (e.g. SW-HW, ECU-ECU) | ☐ |
📌 Reviewer 질문:
“이 테스트 전략은 ‘어디까지’ 검증하려는 건가?”
2. Safety Requirement 연계성 (Traceability)
| TSR / HSR / SSR 중 어떤 레벨을 검증하는지 명확 | ☐ |
| 각 요구사항 → 통합 테스트 매핑 존재 | ☐ |
| Safety Goal 미연결 테스트 없음 | ☐ |
❌ 기능 요구만 테스트
→ Confirmation Review Finding
3. Integration 대상 구성 정의
| 통합 대상 컴포넌트 식별 | ☐ |
| Safety-related component 표시 | ☐ |
| 인터페이스 정의 문서 참조 | ☐ |
📌 Reviewer 질문:
“어떤 인터페이스 고장을 통합 단계에서 잡겠다는 건가?”
4. Fault Model 기반 테스트 전략 여부
(Part 9 핵심)
| Fault model 정의 | ☐ |
| Fault가 통합 단계에서 타당한 이유 설명 | ☐ |
| 단위시험과 중복/누락 분석 | ☐ |
❗ Fault 기반 접근 없으면 ISO 26262 취지 위반
5. Safety Mechanism 통합 검증 전략
| Safety mechanism 동작 검증 포함 | ☐ |
| 메커니즘 간 상호작용 테스트 포함 | ☐ |
| Fault → detection → reaction 체인 검증 | ☐ |
📌 Reviewer 질문:
“메커니즘이 서로 간섭할 가능성은 어디서 검증하나?”
6. HW–SW Integration Test 전략 (중점 항목)
| HW fault가 SW에서 감지되는 경로 검증 | ☐ |
| SW reaction이 HW safe state로 연결됨 | ☐ |
| 타이밍 요구 검증 전략 포함 | ☐ |
❌ 기능 OK, 타이밍 미검증
→ Major Finding 가능
7. ASIL 요구사항 반영 여부
| ASIL에 따른 테스트 깊이 차별화 | ☐ |
| ASIL 분해된 요구사항 모두 포함 | ☐ |
| Independence 요구 반영 | ☐ |
8. Negative / Robustness Test 전략
| Fault injection 전략 포함 | ☐ |
| Invalid input / sequence 고려 | ☐ |
| Stress 조건 포함 여부 | ☐ |
📌 Reviewer 질문:
“정상일 때 말고, 망가졌을 때도 테스트하나?”
9. Test Environment & Tool Control (Part 8)
| 테스트 환경 정의 (HIL, SIL 등) | ☐ |
| Safety test tool 신뢰성 근거 | ☐ |
| Tool qualification 필요성 평가 | ☐ |
❌ “HIL로 합니다”만 있음 → 불충분
10. Test Coverage 주장 타당성
| 커버리지 정의 기준 명확 | ☐ |
| Safety coverage와 기능 coverage 구분 | ☐ |
| 미커버 영역 justification | ☐ |
11. Pass/Fail Criteria & Escalation
| Safety 관련 명확한 Pass/Fail 정의 | ☐ |
| Fail 시 조치 프로세스 정의 | ☐ |
| Safety manager 개입 조건 명시 | ☐ |
12. Configuration & Change Management
| 테스트 대상 구성 관리 | ☐ |
| 요구사항 변경 시 영향 분석 | ☐ |
| 재시험 기준 명확 | ☐ |
13. Consistency Check (문서 간)
| Safety Plan과 일관성 | ☐ |
| Verification Plan과 충돌 없음 | ☐ |
| Safety Case 주장과 정합 | ☐ |
14. Evidence 생성 전략
| 결과가 Safety Case 증거로 사용 가능 | ☐ |
| 로그 / 결과물 형식 정의 | ☐ |
| 추적성 확보 가능 | ☐ |
15. Confirmation Review 결론
- ☐ Accept
- ☐ Accept with Findings
- ☐ Reject
Typical Confirmation Review Findings
- Fault 기반 테스트 전략 부재
- Safety mechanism 통합 검증 누락
- HW–SW reaction chain 미검증
- ASIL 차별화 없음
🔑 Confirmation Reviewer 관점 한 줄 요약
“이 Integration Test Strategy는
‘통합 후에야 드러나는 안전 고장’을
의도적으로 잡기 위해 설계되었는가?”
YES → Accept
NO → Finding / Reject
'기능안전_기본이론' 카테고리의 다른 글
| DFMEA와 PFMEA관계 (0) | 2026.01.09 |
|---|---|
| Safety analysis_confirmation review (0) | 2026.01.09 |
| TSC_Functional safety assessment (0) | 2026.01.09 |
| TSC_confirmation review (0) | 2026.01.09 |
| Part2_confirmation review (0) | 2026.01.09 |