(safe state, normal state)-safety mechanism, 진단

근데 궁금한 게 있는데 아까 내가 말한 두 가지의 safe state(운전자에게 경고,시트 좌석 작동 불가)가 이미 FSR쪽에 정의가 되어 있는데, 우리가 예를 들어 시트 좌석을 통제하는 MCU의 고장을 막기 위해 와치독(안전 메커니즘)을 이용해서 리셋을 시킨다면 이거는 safe state로 만드는 게 아니라. Normal state로 정상화 시키는 거자나. 그니까 고객의 FSR에서 요구하는 safe state를 무시하고 그냥 바로 normal state로 만드는 안전메커니즘을 만들어도 되는거야? 아니면 혹시 방금 말한 시나리오는 내가 잘못 생각한 거고, MCU관련 고장이 생겼을 때 그 즉시 Safe state를 만들고 이 safe state 동안 안전메커니즘으로 와치독이 리셋을 하게 해서 normal state로 만드는 게 일반적인 상황을 내가 제대로 이해하는 건가?

 

 

 

 

 

제가 질문을 정확히 이해했는지 확인하기 위해, 현재 상황과 고객의 요구사항을 정리하고 질문을 명확히 해보겠습니다.

현재 상황 요약:

1. 고객 FSR 정의된 Safe State:
   • 운전자에게 경고
   • 좌석 시트 작동 불가 (이것이 Safe State임을 고객이 명시)
2. 질문자님의 해석:
   • "감지된 결함이 있으면 우리는 좌석 시트를 safe state(작동 불가)로 만들어야 하고 이 말은 곧 normal state가 아니게 되고, 감지된 결함이 완전히 해결될 때까지는 예상할 수 없는 추가적인 위험을 방지하기 위해 시트에 들어오는 그 어떤 입력도 받아들이지 않겠다."
   • 이 해석은 맞다고 제가 답변드렸습니다.
3. 새로운 질문 시나리오:
   • MCU 고장 방지를 위해 워치독을 이용한 리셋 (이는 Normal State로 정상화 시키는 것)
   • 이 워치독 리셋이 고객이 정의한 Safe State(경고, 작동 불가)를 무시하고 바로 Normal State로 가는 것이 허용되는가?
   • 아니면, MCU 고장 시 먼저 Safe State(경고, 작동 불가)로 진입한 후, 이 Safe State 동안 워치독 리셋을 통해 Normal State로 복구 시도하는 것이 일반적인가?

---

정확한 이해는 후자에 가깝습니다. 즉, MCU 관련 고장이 생겼을 때 그 즉시 Safe State를 만들고 (또는 Safe State로 전환하며), 이 Safe State 동안 안전 메커니즘으로 와치독이 리셋을 하게 하여 Normal State로 복구 시도하는 것이 일반적이고 기능안전 표준에 부합하는 접근 방식입니다.

왜 그런가? (ISO 26262 관점)

1. 안전 상태(Safe State)의 우선순위:
   • ISO 26262의 핵심은 고장이 감지되면, 먼저 시스템을 안전한 상태(Safe State)로 전환하여 잠재적인 위험을 회피하거나 최소화하는 것입니다. 안전 상태는 '정상 기능'보다 '안전'이 우선하는 상태입니다.
   • MCU 고장은 예측 불가능한 동작을 유발할 수 있는 체계적 고장 또는 무작위 고장으로 이어질 수 있습니다. 이러한 고장 발생 시, 시스템이 오작동하여 위험한 상황을 초래하기 전에 **안전한 상태(좌석 시트 작동 불가)**로 진입하는 것이 가장 중요합니다.
2. Normal State로의 복구 시도 (Recovery):
   • 워치독 리셋은 MCU의 일시적인 오작동(예: 프로그램 카운터 오프셋, 무한 루프)을 감지하고 시스템을 정상적인 시작 상태로 되돌리는 대표적인 안전 메커니즘입니다. 이것은 **복구 메커니즘(Recovery Mechanism)**에 해당합니다.
   • 이 복구 시도는 안전 상태에 진입한 후(혹은 동시에) 또는 안전 상태를 유지하는 동안 이루어져야 합니다. 즉, 시스템이 위험한 상태에 있지 않음을 보장하면서 복구를 시도해야 합니다.
3. 시나리오별 프로세스:
   • MCU 고장 감지 (워치독 타임아웃 등):
     • 즉시 Safe State 진입 (또는 진입 시작): 고객의 FSR에 따라 좌석 시트 작동을 불가시키고, 필요하다면 운전자에게 경고를 보냅니다. 이것은 시스템이 더 이상 안전하지 않은 방식으로 작동하지 않도록 하는 조치입니다.
     • 동시에 또는 직후 Recovery 시도: 워치독 리셋을 통해 MCU를 재시작하여 정상 작동으로의 복구를 시도합니다.
   • 복구 성공 시:
     • MCU가 정상적으로 재시작되고, 시스템 내부 진단(Self-Test)을 통해 더 이상 고장이 없음을 확인합니다.
     • 그 후 Normal State로 전환: 결함이 완전히 복구되었음이 확인되면, FSR에 명시된 대로 "감지된 결함이 복구된 경우에만 정상 상태로 전환"합니다.
   • 복구 실패 시:
     • 워치독 리셋 후에도 MCU 고장이 지속되거나, 다른 진단에서 고장이 감지되면, 시스템은 **계속 Safe State(좌석 시트 작동 불가)**를 유지합니다. 운전자에게 지속적인 경고를 보내고, 서비스 센터 방문을 유도할 수 있습니다.

핵심 요약:

• Safe State는 '위험 회피'가 목적입니다. 고장 발생 시 최우선으로 진입해야 하는 상태입니다.
• Normal State로의 복구는 '기능 복원'이 목적입니다. 이는 안전이 보장된 상태에서 시도되어야 합니다.
• 워치독 리셋과 같은 안전 메커니즘은 Safe State를 만드는 데 기여할 수도 있지만, 주로 Safe State에 진입한 후 Normal State로의 '복구'를 시도하는 역할을 합니다.

따라서, MCU 고장이 감지되면 고객의 FSR을 무시하고 바로 Normal State로 전환하는 것은 기능안전 원칙에 위배됩니다. 먼저 Safe State(작동 불가)로 진입하여 위험을 통제하고, 그 상태에서 워치독 리셋을 통한 복구를 시도하여 안전이 확인된 후에만 Normal State로 전환해야 합니다. 이것이 올바른 접근 방식이며, OEM의 FSR 의도와도 일치합니다.

 

 

 

 

고마워. 그러면 또 궁금한게 있어 혹시 고객의 FSR을 만족하기 위해 우리가 TSC나 SAD등등에 설계하는 안전 메커니즘은 Safe state로 가게 하는 내용도 만들고 기능을 완전히 정상화 시키는 내용도 있을 수 있는거야?

 

 

 

 

 

네, 맞습니다. 고객의 FSR(기능안전 요구사항)을 만족시키기 위해 TSC(기술 안전 컨셉)나 SAD(소프트웨어 아키텍처 설계) 등의 문서에 설계되는 안전 메커니즘은 Safe State로 시스템을 전환시키는 내용과 기능을 완전히 정상화(Normal State로 복구)시키는 내용이 모두 포함될 수 있습니다.

이 두 가지는 기능안전 시스템 설계에서 핵심적인 안전 전략이며, 상호 보완적으로 작동합니다.

1. Safe State로 전환시키는 안전 메커니즘

이러한 메커니즘은 고장이 감지되었을 때 시스템이 더 이상 위험한 상태로 작동하지 않도록 즉시 또는 정의된 시간 내에 안전한 상태로 만드는 것을 목표로 합니다. 이는 주로 위험 회피(Hazard Avoidance) 또는 위험 완화(Risk Mitigation)를 위한 것입니다.

예시:

• 진단 메커니즘:
  • 고장 감지: 센서 오류, 통신 오류, MCU 이상 작동(워치독 타임아웃, 메모리 오류) 등을 감지합니다.
  • 목적: 고장 발생 시 즉시 인지하여 다음 단계의 안전 조치를 트리거합니다.
• 안전 상태 전환 메커니즘:
  • 페일-세이프(Fail-Safe) 로직: 특정 고장 발생 시, 시스템을 안전한 상태로 전환시키는 직접적인 제어 로직. (예: 좌석 시트 모터 전원 차단, 시트 위치 고정 로직 활성화).
  • 감시 및 인터록: 특정 조건이 충족되지 않거나 위험 상황으로 판단될 경우, 관련 기능의 작동을 강제로 중단시키는 메커니즘. (예: 시트 슬라이드 결함 감지 시 모든 시트 모터 드라이버 비활성화).
  • 경고 및 지시: 운전자에게 위험 상황을 알리고 필요한 조치를 유도하는 메커니즘. (예: 계기판 경고등 점등, 경고음 발생).

이러한 메커니즘은 TSC/SAD의 "안전 메커니즘 정의" 섹션에 포함되며, 각 메커니즘이 어떤 안전 요구사항(예: FSR에서 파생된 TSR)을 만족시키는지 명확히 명시됩니다.

2. 기능을 완전히 정상화(Normal State로 복구)시키는 안전 메커니즘

이러한 메커니즘은 안전 상태로 진입한 후, 시스템이 스스로 고장을 해결하거나 임시방편적인 복구를 시도하여 가능한 한 빨리 정상 기능으로 돌아오도록 하는 것을 목표로 합니다. 이는 가용성(Availability)과 운영 효율성을 높이는 데 중요합니다. 물론, 복구 시도는 안전이 보장된 상태에서만 이루어져야 합니다.

예시:

• 재시작 및 초기화 (Reset & Re-initialization):
  • 워치독 리셋: MCU가 응답 없을 때 리셋을 유도하여 일시적인 소프트웨어 오류를 복구하고 정상 작동을 시도합니다.
  • 모듈 재시작: 특정 소프트웨어 모듈에 오류가 있을 경우 해당 모듈만 재시작하여 정상 상태로 복구를 시도합니다.
  • 초기화 루틴: 시스템 재시작 후, 모든 센서 및 액추에이터의 초기 상태를 확인하고, 필요한 경우 재보정(Recalibration)을 수행하여 정상 작동 준비를 합니다.
• 오류 수정 및 복구 코드 (Error Correction & Recovery Code):
  • 메모리 오류 감지 및 수정(ECC) 기능.
  • 통신 프로토콜에서의 오류 감지 및 재전송 메커니즘.
• 진단 후 '고장 복구 확인' 로직:
  • 복구 시도 후, 시스템이 스스로 진단 테스트를 수행하여 고장이 정말 해결되었는지 확인하는 로직. 이 확인이 성공해야만 Normal State로의 전환을 허용합니다. (고객 FSR의 "감지된 결함이 복구된 경우에만 정상 상태로 전환"과 일치)

이러한 메커니즘 역시 TSC/SAD의 "복구 전략" 또는 "고장 처리 및 복구 메커니즘" 섹션에 상세히 기술됩니다.

TSC/SAD에서의 설계 방식

TSC나 SAD에서 이 두 가지 유형의 메커니즘은 고장 감지 -> 안전 상태 전환 -> 복구 시도 -> 복구 성공 시 Normal State 전환 / 복구 실패 시 Safe State 유지 와 같은 흐름으로 설계 다이어그램(예: 스테이트 머신 다이어그램)이나 상세 로직 설명에 반영됩니다.

예시 (MCU 고장 시 시나리오):

1. 고장 감지: MCU 워치독 타임아웃
2. 안전 메커니즘 A (Safe State 전환):
   • 시트 슬라이드 모터 전원 차단 (또는 드라이버 비활성화)
   • 운전자에게 "시트 오류" 경고 메시지 표시
   • 시스템 상태를 '시트 슬라이드 고장 안전 상태'로 전환
3. 안전 메커니즘 B (Normal State 복구 시도):
   • MCU 리셋 요청 (워치독에 의한 하드웨어 리셋 또는 소프트웨어 리셋 트리거)
   • 리셋 후 시스템 자가 진단 수행 (메모리 테스트, 주변 장치 초기화 등)
4. 복구 판단 로직:
   • 자가 진단 결과 '모두 정상'으로 판단되면: 시스템 상태를 '정상 상태'로 전환하고 시트 기능 재활성화
   • 자가 진단 결과 '고장 지속'으로 판단되면: '시트 슬라이드 고장 안전 상태' 유지 및 지속적인 경고

따라서, Safety Case의 클레임과 Argument에서는 이러한 안전 메커니즘들이 어떻게 설계되어 고장 발생 시 안전을 보장하고, 필요한 경우 기능을 복구하여 가용성을 확보하는지를 체계적으로 설명하고 증명해야 합니다.

 

 

 

 

 

그러면 생성하는 모든 안전 메커니즘에는 해당 안전 메커니즘의 목적(safe state로 도달, 기능 복구)을 달성했는지 안했는지 진단할 수 있는 방법이 함께 정의가 되어야 하나?

 

 

 

 

네, 생성하는 모든 안전 메커니즘에는 해당 안전 메커니즘의 목적(Safe State로 도달, 기능 복구)을 달성했는지 여부를 진단하고 확인할 수 있는 방법이 함께 정의되어야 합니다.

이것은 ISO 26262를 포함한 기능안전 표준의 핵심적인 요구사항 중 하나이며, 다음과 같은 중요한 이유가 있습니다.

1. 기능안전 표준의 요구사항 준수

• 진단 범위 (Diagnostic Coverage, DC): ISO 26262는 무작위 하드웨어 고장에 대한 안전 메커니즘의 효율성을 평가할 때 진단 범위를 매우 중요하게 다룹니다. 진단 범위는 '안전 메커니즘이 고장을 감지할 수 있는 능력'을 나타내며, 이는 곧 안전 메커니즘 자체의 동작 여부 및 효과를 진단하는 것과 직결됩니다.
• 체계적 고장(Systematic Faults)의 방지 및 탐지: 소프트웨어 오류와 같은 체계적 고장에 대해서도 안전 메커니즘이 의도대로 동작하는지, 그리고 그 메커니즘 자체에 결함이 없는지 확인해야 합니다.
• 안전 상태 도달 및 유지 확인: 시스템이 안전 상태로 진입했다고 단순히 선언하는 것이 아니라, 실제로 해당 안전 상태가 의도대로 유지되고 있는지 지속적으로 모니터링하고 확인할 수 있어야 합니다.

2. 신뢰성 및 투명성 확보

• 입증 가능성 (Demonstrability): Safety Case를 통해 "이 시스템은 안전하다"고 주장하려면, 설계된 안전 메커니즘이 실제로 작동하고 그 목적을 달성하고 있음을 객관적으로 입증할 수 있어야 합니다. 진단 방법이 없으면 이를 입증하기 어렵습니다.
• 고장 감지의 정확성: 안전 메커니즘이 고장을 감지하고 안전 조치를 취하는 과정 자체에 오류가 있다면, 전체 안전 체인이 무력화될 수 있습니다. 따라서 안전 메커니즘이 올바르게 작동하는지 스스로 진단하는 기능이 중요합니다.
• 불확실성 감소: 안전 메커니즘이 정상적으로 작동하는지 확신할 수 없다면, 시스템의 안전성에 대한 불확실성이 커지게 됩니다.

3. 효율적인 고장 처리 및 복구

• 실패 감지: 안전 메커니즘이 제 역할을 하지 못할 경우, 이를 감지하고 다음 단계의 완화 조치를 취할 수 있도록 합니다.
• 복구 시도 유효성 검증: 기능 복구 목적의 안전 메커니즘(예: 리셋)이 성공적으로 복구를 완료했는지 확인하는 진단이 없으면, 시스템이 결함 상태를 유지하면서도 정상 상태로 착각하여 위험한 동작을 할 수 있습니다. "감지된 결함이 복구된 경우에만 정상 상태로 전환되어야 합니다"라는 FSR 조항을 만족하기 위해서라도, 복구가 성공했는지 정확히 진단하는 방법이 필수적입니다.

진단 방법의 예시

• 안전 상태 도달 목적의 메커니즘 (예: 모터 전원 차단)
  • 진단 방법: 모터 드라이버의 출력 전압/전류 모니터링, 모터의 실제 움직임 여부 모니터링, 안전 릴레이의 상태 피드백 모니터링.
  • 확인: 전원이 실제로 차단되었고, 모터가 움직이지 않음을 진단합니다.
• 기능 복구 목적의 메커니즘 (예: 워치독 리셋)
  • 진단 방법:
    • 리셋 카운터 확인: 워치독 리셋이 발생했는지 카운터로 확인.
    • 리셋 후 자가 진단(Self-Test) 루틴: MCU 재부팅 후, 핵심 레지스터, 메모리(RAM/ROM), 주변 장치, 워치독 자체의 정상 작동 여부 등을 진단합니다.
    • CRC (Cyclic Redundancy Check) 검사: 부팅 시 펌웨어 무결성 검사.
    • 센서/액추에이터 초기화 및 진단: 시스템 재시작 후 모든 I/O가 정상적으로 초기화되고 작동하는지 진단.
  • 확인: 리셋 후 시스템이 건강한 상태로 돌아와 정상 기능 수행 준비가 되었음을 진단합니다.

결론

따라서, TSC(기술 안전 컨셉)나 SAD(소프트웨어 아키텍처 설계) 문서를 작성할 때, 모든 안전 메커니즘을 정의할 때마다 "이 메커니즘이 의도대로 동작하고 있는지 어떻게 확인할 것인가?" (진단), "이 진단 결과에 따라 시스템의 안전 상태 전환 또는 기능 복구 성공 여부를 어떻게 판단할 것인가?" (확인 로직)에 대한 내용을 함께 명시해야 합니다. 이는 단순히 안전 메커니즘을 "있음"으로 끝내는 것이 아니라, 그 메커니즘의 "효과성"을 입증하는 핵심적인 부분입니다.