TSR내 FHTI 작성은 어떤 경우에?

기능안전에서 TSC 문서 내에 각 TSR에 safe sate가 적혀 있다면 FHTI(FDTI + FRTI)는 반드시 적혀져 있어야 하지 않아? 그렇게 생각하는 이유는 나는 safe state가 안전 메커니즘을 통해 고장을 감지하고 safe state를 가는 거라고 봤고, 그 과정에 FHTI의 개념이 당연히 포함될 수 밖에 없고 FHTI로 배정된 시간의 적절성이 확인되어야 한다고 생각해서 그런거야, 혹시나 내 말에 틀린 점이 있니?

 

짚으신 논리 자체는 크게 맞습니다. Safe state가 정의되어 있다면, 그 상태에 도달하기까지의 시간적 제약(=FHTI: Fault Handling Time Interval, 즉 FDTI+FRTI)은 반드시 고려되어야 하고, 그 적절성이 검증되어야 합니다. 다만 “TSC 문서 내 모든 TSR에 반드시 FHTI가 기재되어야 한다”는 표현은 약간의 뉘앙스 차이가 있습니다.

🔑 핵심 정리

• Safe state: 시스템이 위험을 회피하기 위해 도달해야 하는 상태.
• FDTI (Fault Detection Time Interval): 고장을 감지하는 데 걸리는 시간.
• FRTI (Fault Reaction Time Interval): 감지 후 safe state로 전환되는 데 걸리는 시간.
• FHTI (Fault Handling Time Interval = FDTI + FRTI): 고장 발생부터 safe state 도달까지의 총 시간.
• FTTI (Fault Tolerant Time Interval): 고장 발생부터 위험한 이벤트가 발생하기까지 허용 가능한 최대 시간.

🧩 왜 FHTI가 필요할까?

• Safe state가 정의되어 있다는 것은 **“고장을 감지하고 → 반응하여 → 안전 상태로 전환”**하는 시나리오가 있다는 뜻입니다.
• 따라서 FHTI는 FTTI보다 짧아야 하며, 그렇지 않으면 안전 메커니즘이 제 역할을 못하게 됩니다.
• 즉, TSR에 safe state가 명시되었다면, 그 safe state에 도달하는 데 필요한 시간 제약(FHTI)을 정의하고 검증하는 것이 필수적입니다.

⚖️ 다만 주의할 점

• 모든 TSR이 항상 FHTI를 직접적으로 기재해야 하는 것은 아닙니다.
  어떤 TSR은 단순히 에방적 요구사항(예: 특정 조건에서 기능 제한)일 수 있고, 이 경우 safe state로의 전환 개념이 직접적
  으로 필요하지 않을 수 있습니다.
  하지만 고장 감지 후 safe state로 전환하는 요구사항이라면, 반드시 FHTI를 정의하고 그 값이 FTTI 내에 들어오는지 확인해야 합니다.
• ISO 26262 관점에서는 FTTI → FDTI/FRTI 분해 → FHTI 검증이라는 흐름이 중요합니다. 즉, traceability 상에서 FHTI가 빠지면 안전성 입증이 불완전해집니다.

✅ 결론

• 당신의 생각은 기본적으로 옳습니다. Safe state가 정의된 TSR이라면 FHTI는 반드시 고려되어야 하고, 그 적절성이 검증되어야 합니다.
• 다만 모든 TSR에 기계적으로 FHTI를 적어야 한다기보다는, safe state 전환을 포함하는 TSR에 대해서는 반드시 FHTI를 정의해야 한다고 보는 것이 ISO 26262의 의도와 더 가깝습니다.

 

"- 어떤 TSR은 단순히 예방적 요구사항(예: 특정 조건에서 기능 제한)일 수 있고, 이 경우 safe state로의 전환 개념이 직접적으로 필요하지 않을 수 있습니다." 너가 말한 이런 경우의 예시를 들어줘

 

예시를 들어 설명하자면, 예방적 요구사항은 “고장이 발생했을 때 안전 상태로 전환한다”는 개념이 아니라, 애초에 위험 상황이 발생하지 않도록 기능을 제한하거나 조건을 설정하는 요구사항을 말합니다. 따라서 이런 경우에는 Safe state 전환이나 FHTI 개념이 직접적으로 필요하지 않습니다.

🔧 예방적 TSR(Technical Safety Requirement) 예시

1. 속도 제한 기반 요구사항
   TSR: "차량 속도가 10km/h 이상일 떄 자동 주차 브레이크 해제 기능은 비활성화 되어야 한다.
   →설명: 여기서는 고장을 감지하고 safe state로 가는 것이 아니라, 위험 상황(주행 중 의도치 않은 EPB 해제)을 애초에 방지하는 예방적 제약입니다.
2. 입력 조건 제한
   TSR: "운전자가 브레이크 페달을 밟지 않으면 변속 레버를 'D'로 전환할 수 없어야 한다."
   →설명: 이는 고장 대응이 아니라, 시스템이 위험한 상태로 들어가지 않도록 조건을 강제하는 예방적 요구사항입니다.
3. 출력 제한
   TSR: "조향 보조 토크는 차량 속도가 120km/h 이상일 때 50% 이하로 제한되어야 한다."
   →설명: 고장 감지 후 safe state로 가는 것이 아니라, 고속 주행 시 과도한 조향 보조로 인한 위험을 예방하는 요구사항입니다.
   
4. 워치독(Watchdog) 활성화
   

• TSR: “MCU는 항상 워치독 타이머를 활성화해야 한다.”
• 설명: 워치독은 시스템이 오작동하기 전에 리셋을 유도하는 예방적 메커니즘으로, 특정 고장에 대한 safe state 전환이라기보다는 사전적 방어입니다.

📌 정리

• Safe state 전환이 필요한 TSR: “센서 고장 시 시스템은 100ms 이내에 토크 출력을 0으로 줄여야 한다.” → 여기서는 FHTI가 반드시 필요.
• 예방적 TSR: “차량 속도가 10km/h 이상이면 EPB 해제 불가.” → 여기서는 FHTI 개념이 직접적으로 필요하지 않음.

즉, TSR이 항상 FHTI를 포함해야 하는 것은 아니고, 고장 감지 후 안전 상태로 전환하는 시나리오가 있는 경우에만 FHTI가 필수적으로 정의됩니다.