**TSC(Technical Safety Concept)**는 OEM Confirmation Review에서 가장 공격적으로 보는 문서 중 하나고,
“있다 / 없다”가 아니라 논리·완결성·ASIL 방어력을 본다.
아래 체크리스트는 ISO 26262 Confirmation Review 관점에서
👉 TSC 문서 자체를 리뷰하기 위한 전용 체크리스트야.
(Part 4 중심 + Part 8, Part 9 연계 고려)
ISO 26262
Confirmation Review Checklist
Technical Safety Concept (TSC)
ASIL C / D 기준
System / HW / SW 인터페이스 포함
0. Confirmation Review 기본 조건
체크 항목확인
| Confirmation Reviewer 독립성 확보 | ☐ |
| Review 대상 TSC 문서 식별 (버전/범위) | ☐ |
| Item Definition, FSC 승인 완료 | ☐ |
| Safety Case 내 TSC 역할 명확 | ☐ |
❗ FSC 미승인 상태의 TSC는 Review 불가
1. TSC의 목적 및 범위 명확성
체크 항목확인
| TSC 목적이 명확히 기술됨 | ☐ |
| System boundary 명확 | ☐ |
| HW / SW / External 요소 구분 | ☐ |
| Assumption 및 Exclusion 명시 | ☐ |
OEM 질문:
“이 TSC가 커버하지 않는 위험은 무엇입니까?”
2. FSC → TSC 변환 논리의 타당성
체크 항목확인
| 모든 FSC 요구사항이 TSC로 추적 가능 | ☐ |
| Safety mechanism 기술 수준으로 구체화 | ☐ |
| FSC의 추상 논리가 TSC에서 구현 논리로 전환됨 | ☐ |
| 누락된 FSC 요구 없음 | ☐ |
❗ FSC 문장 복사 = Finding
3. Technical Safety Requirements (TSR) 품질
체크 항목확인
| TSR이 명확·단일 의미 | ☐ |
| 검증 가능(Testable) | ☐ |
| ASIL 할당 명확 | ☐ |
| HW / SW 할당 명확 | ☐ |
| Timing, fault reaction 포함 | ☐ |
OEM 공격 질문:
“이 요구사항을 어떻게 검증할 수 있습니까?”
4. Safety Architecture 설명의 충분성
체크 항목확인
| Safety architecture 다이어그램 존재 | ☐ |
| Redundancy 구조 설명 | ☐ |
| Monitoring / Supervision 경로 명확 | ☐ |
| Fault containment 경계 명확 | ☐ |
❗ “그림만 있음” → Finding
5. Fault Handling & Safe State 정의
체크 항목확인
| 각 fault에 대한 시스템 반응 정의 | ☐ |
| Safe state 정의 명확 | ☐ |
| Fail-safe / Fail-operational 구분 | ☐ |
| Transition 조건 명확 | ☐ |
OEM 질문:
“이 고장이 나면, 언제, 무엇이, 어떻게 안전해집니까?”
6. ASIL Allocation & Decomposition (Part 9 연계)
체크 항목확인
| ASIL 할당 근거 명확 | ☐ |
| ASIL 분해 조건 충족 | ☐ |
| 독립성 논리 설명 | ☐ |
| 분해 후 ASIL 관리 전략 존재 | ☐ |
⚠️ ASIL 분해는 증명 없으면 바로 Major Finding
7. Safety Mechanism의 완전성
체크 항목확인
| 모든 Safety Goal에 대응하는 mechanism 존재 | ☐ |
| Single Point Fault 대응 | ☐ |
| Latent Fault 대응 | ☐ |
| Common Cause Fault 고려 | ☐ |
8. System-level Safety Analysis 반영성
(Part 9)
체크 항목확인
| System FMEA / FTA 결과 반영 | ☐ |
| 분석 결과가 TSR로 연결 | ☐ |
| 미완화 위험 명시 | ☐ |
OEM 질문:
“이 분석 결과는 TSC 어디에 반영되어 있습니까?”
9. HW/SW Interface 명확성
체크 항목확인
| Safety responsibility 분리 명확 | ☐ |
| Interface failure 고려 | ☐ |
| HW ↔ SW safety requirement 연결 | ☐ |
❗ Interface 모호 = OEM 최애 Finding
10. Supporting Process 적용성 (Part 8)
10.1 Requirements Management
체크 항목확인
| Bi-directional traceability | ☐ |
| 변경 영향 분석 수행 | ☐ |
10.2 Verification Strategy
체크 항목확인
| TSR별 검증 방법 정의 | ☐ |
| Independence 요구 반영 | ☐ |
11. Consistency Check (TSC 내부 + 타 문서)
체크 항목확인
| FSC와 모순 없음 | ☐ |
| HWSC / SWSC와 일관 | ☐ |
| Safety Case 주장과 일치 | ☐ |
12. Evidence 수준 평가
체크 항목확인
| 설계 근거 명시 | ☐ |
| 계산/분석 결과 존재 | ☐ |
| OEM 요청 시 설명 가능 | ☐ |
❌ “설계 의도”
✅ “기술적 근거”
13. Common OEM Confirmation Review Findings (TSC)
항목확인
| TSR이 모호함 | ☐ |
| ASIL 분해 논리 부족 | ☐ |
| Fault reaction 시나리오 부족 | ☐ |
| Interface 책임 불명확 | ☐ |
14. Confirmation Review 핵심 판단 질문
질문Yes / No
| 이 TSC만 보고 구현이 가능한가? | ☐ |
| Safety Goal이 기술적으로 달성 가능한가? | ☐ |
| ASIL 논리가 공격에 견딜 수 있는가? | ☐ |
| OEM/TÜV 앞에서 방어 가능한 문서인가? | ☐ |
15. Confirmation Review Conclusion
- ☐ Acceptable
- ☐ Acceptable with Findings
- ☐ Not Acceptable
주요 Finding
- Finding ID:
- Related Clause:
- Safety Impact:
- Required Action:
🔑 Confirmation Reviewer의 한 줄 판단 기준 (TSC)
“이 문서는 ‘안전하다’고 말하는 문서가 아니라
‘왜 안전할 수밖에 없는지’를 증명하는 문서인가?”
YES → 통과
NO → Finding
'기능안전_기본이론' 카테고리의 다른 글
| Integration test strategy_confirmation review (0) | 2026.01.09 |
|---|---|
| TSC_Functional safety assessment (0) | 2026.01.09 |
| Part2_confirmation review (0) | 2026.01.09 |
| Part7_Functional safety assessment (0) | 2026.01.09 |
| Part7_confirmation review (0) | 2026.01.09 |