시스템 수준에서의 요구사항 작성 예시

명확한 원문 제시 감사합니다. 이 조항(ISO 26262-4, 6.4.1.2)은 기술적 안전 요구사항(TSR)을 어떻게 '구체적이고 실행 가능하게' 작성해야 하는지에 대한 가장 중요한 지침 중 하나입니다.

이를 "상황-행동 규칙" 또는 "If (조건)-Then (행동) 명세서" 로 작성하라는 요구사항이라고 이해하시면 됩니다.

---

핵심 해석: "요구사항은 추상적 목표가 아니라, 구체적인 상황과 반응으로 써라."

1. 문구별 분석

• "기술 안전 요구사항은 안전 요구사항의 달성에 영향을 미치는 시스템의 자극 반응을 규정해야 한다."
  • 의미: TSR은 단순히 "안전해야 한다"는 선언이 아니라, 특정 입력(자극)에 대한 시스템의 출력(반응) 을 정확히 정의해야 합니다.
  • 왜? 이렇게 해야만 검증 팀이 그 요구사항이 충족되었는지 테스트할 수 있습니다. (예: "이런 자극을 주면, 이런 반응이 나오나?")
• "여기에는 각 관련 운용 모드 및 정의된 시스템 상태와 관련된 자극과 고장의 조합이 포함된다."
  • 의미: 시스템은 다양한 모드(예: 주행, 대기, 진단 모드) 와 상태(예: 정상, 부분 고장, 응급 모드) 를 가집니다. 요구사항은 "특정 모드/상태에서, 특정 자극(고장 포함)이 발생했을 때" 어떻게 행동할지를 규정해야 합니다.
  • 왜? 고장은 언제든지 발생할 수 있으며, 시스템은 어떤 상태에 있든 안전해야 합니다. 또한, 같은 고장도 시스템 모드에 따라 다르게 처리될 수 있습니다.

2. 예시(※)를 통한 실무적 이해

보기: 수신된 적응 순항 제어(ACC) 명령 메시지가 오류 검출 코드 점검에 실패하면 제동 시스템 전자제어장치(ECU)는 ACC 제동을 불가능하게 한다.

이 예시를 6.4.1.2의 요구사항 구조에 맞춰 분해하면 다음과 같습니다:

이 조항이 의미하는 실무적 업무 변화

잘못된 요구사항 (6.4.1.2 미충족):

"시스템은 통신 오류로부터 안전해야 한다." (너무 추상적. 어떻게? 언제? 무엇을?)

올바른 요구사항 (6.4.1.2 충족):

TSR-45: ACC 기능이 활성화된 상태(Operational_Mode == ACC_Active)에서, 수신된 ACC_Command_CAN 메시지의 CRC 검사가 실패하면(if (CRC_Check(msg) == FAIL)), 제동 시스템 ECU는 다음 동작을 수행해야 한다:

1. 해당 메시지를 무시한다.
2. 내부 상태를 ACC_Degraded로 전환한다.
3. 운전자에게 ACC 일시 불가 메시지를 표시한다.
4. 안전 목적: 오염된 명령에 의한 위험한 자동 제동을 방지한다.

왜 이렇게 해야 하는가? (핵심 이유 3가지)

1. 검증 가능성 보장: 테스트 엔지니어가 위의 TSR-45를 보면 명확한 테스트 케이스를 만들 수 있습니다.
   • 테스트 절차: ACC를 활성화 → CAN 툴로 CRC가 잘못된 ACC_Command 메시지를 주입 → HMI에 경고가 뜨는지 확인 → 실제 제동이 발생하지 않는지 확인.
2. 구현 오류 방지: 소프트웨어 개발자가 이 요구사항을 받으면, 정확한 if-then-else 코드로 구현할 수 있습니다. 애매모호함이 사라집니다.
3. 안전 사례의 강력한 증거: "우리는 통신 오류에 안전하다"는 주장을 할 때, TSR-45와 같은 구체적인 요구사항과 그에 대한 검증 결과를 증거로 제시할 수 있습니다.

결론

Clause 6.4.1.2는 "좋은 안전 요구사항의 문법"을 가르쳐줍니다.

이 조항은 안전 엔지니어에게 "너가 쓰는 요구사항이 '명령'인가, 아니면 '시나리오'인가?" 라고 묻는 것입니다. 진정한 안전 요구사항은 시스템이 마주할 구체적인 위험 시나리오(자극+고장) 와 그에 대한 필수적인 안전 반응을 기술한 실행 가능한 명령이어야 합니다.

따라서, 모든 TSR은 이 "조건-반응" 패턴을 따라 작성되어야 하며, 이는 시스템이 복잡할수록, ASIL 등급이 높을수록 더 철저히 적용되어야 합니다.