이건 Confirmation Review보다 한 단계 위,
즉 Assessment Authority(예: TÜV, OEM FSA 위임자) 시점에서
TSC(Technical Safety Concept)가 “통과(PASS)” 가능한지 판단하기 위한 체크리스트야.
관점 고정하고 갈게:
- ❌ “규격 문구 충족했는가?”
- ❌ “문서가 잘 써졌는가?”
- ✅ “이 TSC만을 근거로 Functional Safety 달성을 선언할 수 있는가?”
ISO 26262
Functional Safety Assessment (FSA) Checklist
Technical Safety Concept (TSC)
Assessment Authority View
ASIL C / D 기준
Part 4 중심 + Part 8, Part 9 강하게 연계
0. FSA 수행 전 Gate (Fail Fast 구간)
항목판단
| FSA 수행자의 독립성 충족 (ISO 26262-2) | ☐ |
| Item Definition, FSC 공식 승인 완료 | ☐ |
| TSC가 Safety Case의 일부로 정의됨 | ☐ |
| ASIL 결정 및 분해 전략 고정됨 | ☐ |
❗ 여기서 하나라도 NO → FSA 중단 가능
1. TSC의 안전 주장(Safety Claim) 적합성
1.1 Claim의 존재와 명확성
체크 항목판단
| TSC 수준의 Safety Claim 명시 | ☐ |
| Claim이 Safety Goal 달성을 직접 주장 | ☐ |
| Claim이 “설계 존재”가 아닌 “안전 달성” 주장 | ☐ |
📌 Assessor 질문:
“이 TSC는 무엇이 ‘안전함’을 보장한다고 주장합니까?”
2. FSC → TSC 변환의 기술적 타당성
체크 항목판단
| 모든 FSC 요구사항이 TSC로 변환됨 | ☐ |
| 추상 기능 요구가 기술 메커니즘으로 구체화 | ☐ |
| 변환 과정에 논리적 비약 없음 | ☐ |
❌ FSC 문장 재진술
✅ 기술 설계 논리
3. Technical Safety Requirements (TSR)의 FSA 적합성
3.1 TSR 품질
체크 항목판단
| TSR이 단일 의미로 해석 가능 | ☐ |
| 검증 가능성(Testability) 확보 | ☐ |
| Fault, timing, reaction 포함 | ☐ |
| ASIL 명확히 할당 | ☐ |
3.2 TSR 충분성
체크 항목판단
| 모든 Safety Goal을 TSR이 커버 | ☐ |
| TSR 누락으로 인한 무방어 Hazard 없음 | ☐ |
📌 Assessor 질문:
“이 TSR 하나가 빠지면 어떤 Safety Goal이 깨집니까?”
4. Safety Architecture의 기술적 충분성
체크 항목판단
| Safety architecture가 기술적으로 설명 가능 | ☐ |
| Fault detection → reaction 경로 명확 | ☐ |
| Redundancy 독립성 입증 | ☐ |
| Fault containment boundary 명확 | ☐ |
❗ 그림만 있고 설명 없으면 FSA Fail 가능
5. Fault Handling & Safe State 논리 완결성
체크 항목판단
| 모든 relevant fault에 반응 정의 | ☐ |
| Safe state 정의가 정량적 | ☐ |
| Transition 조건 명확 | ☐ |
| Fail-safe / Fail-operational 전략 일관 | ☐ |
📌 Assessor 질문:
“Fault 발생 후 몇 ms 안에 무엇이 바뀝니까?”
6. ASIL Allocation & Decomposition 적합성
(Part 9 핵심 판단 영역)
체크 항목판단
| ASIL 할당 근거 명확 | ☐ |
| ASIL 분해 조건 충족 (독립성 등) | ☐ |
| Independence 증명 논리 존재 | ☐ |
| 분해 후 ASIL 관리 전략 명확 | ☐ |
⚠️ ASIL 분해 논리 약하면 즉시 FAIL 가능
7. Safety Mechanism의 완전성 & 강건성
체크 항목판단
| Single Point Fault 대응 | ☐ |
| Latent Fault 대응 | ☐ |
| Common Cause Fault 고려 | ☐ |
| Diagnostic Coverage 논리 타당 | ☐ |
📌 Assessor 질문:
“이 메커니즘이 실패하면 누가 감시합니까?”
8. System-level Safety Analysis 반영성
(Part 9 필수)
체크 항목판단
| System FMEA / FTA 수행됨 | ☐ |
| 분석 결과가 TSC에 반영 | ☐ |
| 미완화 위험이 명시적으로 관리 | ☐ |
❌ 분석은 있는데 설계 반영 없음
→ FSA Major Finding
9. HW / SW Interface Safety Adequacy
체크 항목판단
| Safety responsibility 분리 명확 | ☐ |
| Interface fault 고려됨 | ☐ |
| HWSC / SWSC로의 분해 논리 명확 | ☐ |
📌 Assessor 질문:
“이 고장은 HW입니까, SW입니까, 둘 다입니까?”
10. Verification Strategy의 FSA 적합성
(Part 8 연계)
체크 항목판단
| TSR별 검증 전략 정의 | ☐ |
| 검증 독립성 요구 충족 | ☐ |
| Negative testing 고려 | ☐ |
11. Consistency & Completeness Check
체크 항목판단
| FSC와 TSC 간 모순 없음 | ☐ |
| TSC ↔ HWSC / SWSC 일관 | ☐ |
| Safety Case 주장과 일치 | ☐ |
12. Evidence의 “Assessment Grade” 충족 여부
체크 항목판단
| 기술적 근거 제시 가능 | ☐ |
| 계산 / 분석 / 근거 명확 | ☐ |
| 방어 가능한 설명 가능 | ☐ |
❌ “설계 의도입니다”
→ FSA에서 무효
13. Assessment Authority 핵심 질문 (PASS/FAIL 기준)
질문Yes / No
| 이 TSC만으로 Safety Goal 달성 주장 가능? | ☐ |
| 구현 팀이 이 문서로 안전 구현 가능? | ☐ |
| ASIL 논리가 공격에 견딜 수 있음? | ☐ |
| OEM / TÜV 앞에서 PASS 선언 가능? | ☐ |
14. Functional Safety Assessment 결론
- ☐ PASS
- ☐ PASS with Conditions
- ☐ FAIL
Major Issue 요약
- Issue ID:
- Related Safety Goal:
- ASIL Impact:
- Required Action:
🔑 Assessment Authority의 한 줄 판정 기준 (TSC)
“이 TSC는 ‘안전하다고 말하는 문서’가 아니라
‘이 설계 외에는 안전할 수 없는 이유를 증명하는 문서’인가?”
YES → PASS
NO → FAIL
'기능안전_기본이론' 카테고리의 다른 글
| Safety analysis_confirmation review (0) | 2026.01.09 |
|---|---|
| Integration test strategy_confirmation review (0) | 2026.01.09 |
| TSC_confirmation review (0) | 2026.01.09 |
| Part2_confirmation review (0) | 2026.01.09 |
| Part7_Functional safety assessment (0) | 2026.01.09 |