패턴 B 다. 같은 문장이 SR 에 세 번 나온다.
§6.3.2 특정 센서 오류가 발생하더라도 … 다른 센서 기능을 불필요하게 중단하지 않아야 한다
§6.4.4 Smart Access, Predictive Climate 또는 Ambient Lighting 중 특정 기능에 오류가 발생하더라도 …
§6.6 개별 기능에 오류가 발생하더라도 독립적으로 안전하게 운용 가능한 다른 기능을 …
우연이 아니라 의도적 반복이다. 범위를 넓혀 가며(센서 → 세 기능 → 전 기능) 세 번 선언한다. 자동차 기능안전의 간섭으로부터의 자유(freedom from interference)를 사용자 관점 문장으로 옮긴 것.
흔한 구현을 금지한다
static bool g_system_ok; /* ✗ 하나라도 실패하면 전부 세이프 모드 */
static uint32_t g_error_flags; /* ✗ 종류 구분이 없다 */
습도 센서 하나 고장에 시스템 전체가 죽는다. 오류는 반드시 기능 단위로 격리된 상태 변수여야 한다.
static func_status_t g_func[FUNC_COUNT]; /* ✓ 기능 × 오류종류 2차원 */
이 자료구조 하나가 §6.6 의 세 요구사항(기능별 구분 · 오류 종류 구분 · 격리)을 한꺼번에 만족시킨다.
의존 그래프를 그려야 답할 수 있다
"습도 센서가 죽었다. 초음파 후방 경고는 계속 동작해야 하는가?" — 그렇다. 두 정보는 독립적이다. 다만 §6.4.2 의 자동 공조는 습도에 의존하므로 새 공조 판단은 시작하지 않는다. "오류가 어떤 기능의 입력으로 쓰이는가" 를 알아야 판정할 수 있다.