[ISO 26262 3강(실무)] 기능 요구사항 → 기술 요구사항(Technical Safety Requirements) 분해

---

Title: ISO 26262 중급 강좌 3강 – 기능 요구사항에서 기술 요구사항으로의 분해
Description: ISO 26262 중급 강좌 3강에서는 Safety Goal을 기반으로 기능 요구사항을 기술 요구사항(Technical Safety Requirements)으로 분해하는 방법과 HW 제약사항, 경계 정의, Fail-safe·Redundancy 개념을 다룹니다.
Keywords: ISO 26262, Technical Safety Requirement, 기능안전, Fail-safe, Redundancy, Diagnostic Coverage

---

⚙️ ISO 26262 중급 강좌 3강

기능 요구사항 → 기술 요구사항(Technical Safety Requirements) 분해

이제 우리는 Safety Goal(SG)과 Functional Safety Requirement(FSR)를 정의했습니다.
하지만 여기서 멈출 수는 없습니다!
실제 시스템과 하드웨어 설계를 위해서는 이 요구사항을 Technical Safety Requirement(TSR)로 세분화해야 합니다.

이번 강의에서는 요구사항 분해 실무 기법, HW 제약사항 고려, 그리고 Fail-safe / Redundancy / Diagnostic Coverage 관점의 분석을 다룹니다. 🚀

---

1. TSR이란 무엇인가? 🧩

Technical Safety Requirement (TSR)는 ISO 26262-4에서 정의된 개념으로,

“시스템, 하드웨어, 소프트웨어 수준에서 안전 목표를 달성하기 위해 필요한 기술적 요구사항”

을 의미합니다.

즉, FSR이 “무엇을 해야 하는가”를 정의한다면, TSR은 “어떻게 구현할 것인가”를 구체화합니다.
이 과정에서 반드시 고려해야 할 요소가 있습니다.

• HW 제약사항 (Hardware Constraints)
  – 전원, 전류, 온도, 타이밍, 인터페이스 등의 한계
• 시스템 경계 (Electrical / Logical Boundary)
  – ECU 간 데이터 경계, 센서 입력과 제어 출력의 구분
• 실현 가능성 (Feasibility)
  – 실제 설계 가능한 수준까지 요구사항을 구체화

📚 참고: ISO 26262-4:2018 Clause 6.4.3 – Technical safety requirements definition

---

2. 요구사항 분해 절차 🧠

요구사항은 상위 안전 목표(SG) → 기능 요구사항(FSR) → 기술 요구사항(TSR)으로 내려갑니다.
이때 각 단계의 연결은 반드시 Traceability로 관리되어야 하죠.

아래는 실제 브레이크 ECU 사례를 통해 본 분해 예시입니다.

단계	요구사항 예시	비고
SG	“제동력 상실 시 차량 정지 가능 상태 유지”	ASIL C
FSR	“이중 회로 제동 구조로 50% 제동력 유지”	시스템 수준
TSR	“ECU는 이중 전원 공급 회로 및 고장 감지 로직 포함”	HW/SW 수준

👉 즉, TSR은 전기적, 논리적 구현 수준에서의 명확한 설계 가이드라인이 됩니다.

---

3. Fail-safe, Redundancy, DC 개념 ⚡

Fail-safe는 고장 발생 시 시스템이 안전한 상태로 전환되도록 하는 설계 철학입니다.
예: 브레이크 ECU 고장 시 “안전 모드 진입 및 잔여 제동력 유지”

Redundancy(이중화)는 주요 구성요소를 복제하여 단일 고장(Single Point Fault)의 영향을 최소화합니다.
예: 전원 공급 라인 이중화, 듀얼 센서 구성

Diagnostic Coverage(진단 커버리지, DC)는 시스템 내 고장 탐지 비율을 의미하며,

DC = 검출 가능한 고장 수 / 전체 고장 수

값이 높을수록 안전성이 향상됩니다.
ASIL D 수준에서는 일반적으로 DC ≥ 90%가 요구됩니다.

 

---

4. 실습 예제 💻

주제: 요구사항 분해 워크숍
목표: Safety Goal → Technical Safety Requirement로 분해

시나리오:

• ASIL C 수준의 브레이크 ECU 시스템
• 고장 시 “제동 불능”을 방지해야 함
• 전원 공급 안정성과 제동 신호 진단 필요

체크리스트:

• Safety Goal 식별
• FSR 작성 (안전 기능 정의)
• TSR 도출 (전원, 진단, 경계 명확화 포함)
• Traceability 매트릭스 작성

예시 결과:

SG-02: 제동 불능 방지 및 안전 정지 확보
FSR-02-1: 제동 신호 이상 검출 시 Fail-safe 모드 진입
TSR-02-1-1: ECU 전원 이중화 (Primary + Backup Battery)
TSR-02-1-2: 브레이크 신호 입력 채널 CRC 검증 로직 추가
TSR-02-1-3: 진단 결과 주기적 모니터링 및 Fault Flag 출력

---

5. 전기적 / 논리적 경계 정의 🧭

TSR 단계에서 가장 중요한 작업 중 하나는 시스템 경계(Boundary) 정의입니다.

구분	예시	주의점
전기적 경계	전원 공급, GND, Sensor Input, Actuator Output	EMI, 전압 Drop 고려
논리적 경계	데이터 버스, 통신 인터페이스 (CAN, LIN)	메시지 CRC, Timeout 처리 필요

 

경계가 불명확하면 고장 원인 구분이 어렵고, 기능안전 검증 시 누락 위험이 커집니다.

 

💡 Tip: Polarion이나 PREEvision 등의 도구를 활용하면 Boundary Mapping을 시각적으로 관리할 수 있습니다.

---

6. OEM / Tier1 / Tier2 관점 정리 📊

역할	주요 책임	구현 수준
OEM	시스템 수준에서 Safety Goal 및 TSR 승인	차량 통합 기준
Tier1	ECU 수준 TSR 작성, 전기적 경계 정의	HW/SW 상세 설계
Tier2	부품 단위 기술 요구사항 반영	칩, 센서 레벨

 

👉 핵심: OEM은 목표를 설정하고, Tier1은 구현을 구체화하며, Tier2는 하드웨어 제약에 맞게 기술적 완성도를 높입니다.

---

핵심 정리 📝

• TSR은 “어떻게 구현할 것인가”를 명확히 하는 기술적 요구사항이다.
• HW 제약사항, 시스템 경계, Fail-safe, Redundancy, DC를 반드시 고려해야 한다.
• 요구사항 간 Traceability 확보는 심사 시 핵심 근거가 된다.
• OEM/Tier1/Tier2 간 역할 구분을 통해 기술적 요구사항의 일관성을 유지해야 한다.

---

👉 다음 강의 예고: 하드웨어 아키텍처 설계 기법과 고장 안전 설계 사례