00. 시스템 개요 — 5개 제어기가 하나의 차량을 만드는 법

출처: 「통합 차량 관제 시스템 사용자 요구사항 명세서(SR) v1.0」 §1~§5, §7 이 노트는 SR 원문을 인용하고, 그 요구사항이 왜 그렇게 쓰였는지와 구현·검증 시 무엇이 문제가 되는지를 덧붙인다.

---

0. 이 노트 묶음을 읽는 순서

12편은 성격이 셋으로 갈린다. 구현하려고 보는 것이라면 00 → 09 → 10 → 11을 먼저 훑고, 담당 기능 편으로 들어가는 게 빠르다.

01~07은 SR에 있는 것을 풀어 쓴 것이고, 09~11은 SR이 SysRS·설계서로 미뤄 둔 것을 요구사항에서 역산한 초안이다(§9). 그래서 09~11의 내용은 팀 합의 전까지 확정이 아니다.

00편의 §4 공통 패턴 5종을 먼저 읽어 두면 나머지가 훨씬 빨리 읽힌다. 같은 문장 구조가 여섯 기능 도메인에서 반복되기 때문이다.

---

1. 이 시스템은 무엇인가

한 줄로 요약하면 저전압 실내 프로토타입 환경에서 검증하는 분산형 차량 제어 시스템이다. "분산형"이 핵심이다. 기능이 하나의 큰 ECU에 몰려 있지 않고, 5개의 물리적으로 분리된 연산 노드에 흩어져 있으며, 그 사이를 **CAN**과 **Wi-Fi/BLE**가 잇는다.

아키텍처에서 바로 눈에 띄어야 하는 두 가지

(1) Central Controller와 VSS는 같은 칩에 산다.

§7.1 "Central Controller 와 VSS 기능은 하나의 S32K344-WB 보드에서 함께 수행하며 두 기능 사이에 별도 차량 네트워크 통신을 사용하지 않는다."

이건 단순한 원가 절감이 아니라 레이턴시 설계 결정이다. VSS(Vehicle Sound System)가 내야 하는 음향 중 가장 급한 것은 Anti-pinch 비상 경고음이다. 만약 VSS가 별도 노드였다면 "끼임 감지 → CAN 프레임 → VSS 노드 수신 → 디코딩 → 오디오 출력"의 경로를 타야 하고, CAN 버스 부하가 높은 순간에는 아비트레이션 대기까지 얹힌다. 같은 칩에 두면 이 구간이 함수 호출 한 번으로 줄어든다.

대신 대가가 있다. 두 기능이 CPU·메모리·인터럽트 우선순위를 공유하므로, VSS의 오디오 DMA가 Central Controller의 상태 종합 태스크를 굶기지 않도록 하는 책임이 설계자에게 넘어온다. "네트워크가 없다"는 건 "네트워크 지연 문제가 스케줄링 문제로 형태를 바꿔 옮겨왔다"는 뜻이다.

(2) S32K144 세 개는 전부 "실행자"이고, 판단은 위로 모인다.

Sensing Controller는 조도를 측정해서 올려보내지만, "조명을 켤지"는 결정하지 않는다. Function Controller가 Ambient Lighting을 구동하지만, "지금 Warning 표시를 해야 하는지"는 Central이 판단한 결과를 받는다. 이 분리가 §9의 원칙과 맞물린다.

§9 "사용자 관점에서 관찰 가능한 기능과 안전 의도는 SR에서 정의하고, Controller 간 내부 명령 전달, 상태 교환, 세부 중재 및 실행 메커니즘은 SysRS 또는 설계 문서에서 정의한다."

즉 SR은 **"무엇이 보여야 하는가"**만 말하고, **"어느 노드가 어떤 CAN ID로 무엇을 보내는가"**는 의도적으로 비워 둔다. 이 노트에서 "Central이 판단한다"고 쓰는 부분은 그림 1의 블록 다이어그램에서 읽어낸 구조이지, SR 요구사항 문장 자체는 아니다.

---

2. 연결 구조

이 그림에서 읽어야 할 설계 의도

• Vision Module은 Central에 직접 붙지 않는다. Sensing Controller를 거친다(TBD-003에서 UART 또는 SPI로 확정 예정). 카메라 판정 결과도 결국 "센싱 정보"의 한 종류로 취급하겠다는 뜻이고, 그래서 §6.3에서 센서 유효성과 비전 유효성이 같은 절에 묶여 있다.

• ESP32와 Central 사이의 물리 통신은 아직 미정이다(TBD-001: UART/CAN/Wi-Fi 등). 이게 미정인 채로 요구사항을 쓸 수 있는 이유가 §9의 마지막 원칙 — 통신 방식을 SR에 고정하지 않았기 때문이다.

• Function Controller는 Window Motor를 직접 제어하지 않는다.

  §7.2 "Function Controller 는 Door Lock Actuator, 공조 출력 장치 및 Ambient Lighting 을 직접 제어한다. Window Motor 는 Power Window Controller 만 직접 제어한다."

  이건 안전 경계다. Anti-pinch는 끼임을 감지한 그 노드가 즉시 모터를 멈춰야 의미가 있다. 모터 구동 권한을 한 노드로 못 박아 두면 "누가 모터를 움직였는가"가 항상 하나로 정해지고, Anti-pinch 로직이 우회당할 경로가 원천 차단된다.

---

3. 용어 — 코드에서 이름이 될 것들

§5의 용어표를 그대로 옮기되, 각 항목에 왜 별도 용어로 정의했는가를 붙였다. 여기 나온 용어는 그대로 상태 변수·열거형 이름이 되어야 한다 — 문서와 코드가 같은 단어를 쓰지 않으면 요구사항 추적이 끊긴다.

함정 — "오류"라는 단어 하나로 뭉치지 말 것 SR은 센서 오류 / 통신 오류 / 기능 자체 오류 세 가지를 끝까지 구분한다. §6.5.3은 "차량 내 HMI 및 모바일 인터페이스는 센서 오류, 통신 오류 및 기능 자체 오류를 사용자가 구분할 수 있도록 표시해야 한다"고 못 박는다. 구현할 때 error_flag 하나짜리 비트로 만들면 이 요구사항을 절대 만족시킬 수 없다. 최소한 오류 원인 코드를 열거형으로 들고 다녀야 한다.

---

4. 전 기능을 관통하는 5개의 설계 패턴

SR을 여섯 개 기능 도메인으로 나눠 읽으면 같은 문장 구조가 반복된다. 이걸 먼저 잡아두면 나머지 노트가 훨씬 빨리 읽힌다.

패턴 A — "신뢰할 수 없으면 새로 시작하지 않는다"

시스템은 X 정보를 신뢰할 수 없는 경우 해당 정보에 기반한 새로운 자동 기능을 수행하지 않아야 한다.

§6.2.2(윈도우), §6.3.2(센싱), §6.4.1(도어), §6.4.2(공조), §6.4.3(조명)에 전부 등장한다. 핵심 단어는 **"새로운"**이다. 이미 진행 중인 동작을 무조건 끊으라는 말이 아니라, 새 판단을 근거 없이 시작하지 말라는 뜻이다.

실제로 §6.2.2는 이렇게까지 구체적이다.

"시스템은 윈도우 위치 또는 이동 상태를 신뢰할 수 없는 경우, 해당 정보에 의존하는 원터치 동작 및 Window 기반 자동 환기 동작을 시작하지 않아야 한다."

시작하지 않아야 한다이지 즉시 중단해야 한다가 아니다. 반면 Anti-pinch는 §6.2.4에서 "즉시 정지해야 한다"로 쓰여 있다. 이 동사 차이가 곧 안전 등급 차이다.

패턴 B — "기능 하나의 고장이 다른 기능을 죽이지 않는다" (Freedom from Interference)

시스템은 특정 센서 오류가 발생하더라도 독립적으로 안전하게 사용할 수 있는 다른 센서 기능을 불필요하게 중단하지 않아야 한다.   (§6.3.2)
시스템은 Smart Access, Predictive Climate 또는 Ambient Lighting 중 특정 기능에 오류가 발생하더라도
독립적으로 안전하게 수행할 수 있는 다른 기능을 불필요하게 중단하지 않아야 한다.                        (§6.4.4)
시스템은 개별 기능에 오류가 발생하더라도 독립적으로 안전하게 운용 가능한 다른 기능을 불필요하게 중단하지 않아야 한다. (§6.6)

같은 문장이 세 군데에 나온다. 이건 우연이 아니라 의도적 반복이다. 자동차 기능안전에서 말하는 간섭으로부터의 자유(freedom from interference)를 사용자 관점 문장으로 옮긴 것이다.

구현 관점에서 이 요구사항은 "전역 system_ok 플래그를 두고 하나라도 실패하면 전부 세이프 모드"라는 흔한 구현을 금지한다. 오류는 반드시 기능 단위로 격리된 상태 변수여야 한다.

꼬리질문: "습도 센서가 죽었다. 초음파 후방 근접 경고는 계속 동작해야 하는가?" → 그렇다. 두 정보는 독립적이다. 다만 §6.4.2의 자동 공조는 습도 정보에 의존하므로 새 공조 판단을 시작하지 않아야 한다. 즉 "오류가 어떤 기능의 입력으로 쓰이는가"의 의존 그래프를 그려야 답할 수 있다.

패턴 C — "복구는 자동 재개가 아니다"

시스템은 Anti-pinch 보호 동작이 종료된 후 새로운 유효 요청이 확인되기 전까지
일반 닫힘 동작 또는 Window 기반 자동 환기 동작을 자동으로 재개하지 않아야 한다.   (§6.2.4)
시스템은 오류로 중단된 자동 기능을 오류 복구만을 근거로 자동 재개하지 않아야 한다.   (§6.4.4)
시스템은 새로운 Fan 제어 기능으로 전환된 이후 이전 기능의 Fan 출력을 자동으로 재개하지 않아야 한다. (§6.4.2)
시스템은 안전 관련 표시가 종료된 이후 이전에 중단된 일시적 Smart Access 시각 피드백 또는
Goodbye Lighting 을 자동으로 재개하지 않아야 한다.                                (§6.4.3)

네 도메인에서 같은 원칙이 반복된다. 중단된 동작은 되살아나지 않는다. 새 요청이나 새 판단이 있어야만 다시 시작한다.

왜 이렇게 강하게 쓰였나? 자동 재개는 사용자가 예측할 수 없는 시점에 물리 동작을 만들기 때문이다. 손가락이 끼어서 창문이 멈췄는데, 오류가 풀렸다고 다시 닫히기 시작하면 사고다. §6.4.4는 이걸 한 문장 더 보강한다.

"시스템은 통신 오류 복구 시 이전에 수신한 마지막 정상 정보를 근거로 새로운 자동 기능을 수행하지 않아야 한다."

복구 직후의 "마지막으로 알던 값"은 이미 낡았다. 그래서 §6.4.4는 이어서 **"기능 오류가 복구된 경우 최신 입력 정보와 관련 기능 상태를 다시 평가해야 한다"**고 요구한다. 재평가가 먼저, 동작은 그 다음이다.

패턴 D — "표시하지 않아야 한다"가 "표시해야 한다"보다 자주 나온다

시스템은 통신 오류 상태에서 마지막 정상 윈도우 상태를 현재 정상 상태로 표시하지 않아야 한다.   (§6.2.6)
HMI 는 통신 오류 동안 마지막 정상 센서 값을 현재 정상 값으로 표시하지 않아야 한다.            (§6.3.4)
HMI 는 신뢰할 수 없는 상태 정보를 현재 정상 상태로 표시하지 않아야 한다.                     (§6.6)
차량 내 HMI 및 모바일 인터페이스는 특정 기능의 상태 정보를 신뢰할 수 없는 경우
마지막 정상 값을 현재 정상 상태로 표시하지 않아야 한다.                                     (§6.5.3)

**"stale 값을 fresh인 척 보여주지 말라"**가 시스템 전체에서 네 번 반복된다. 이건 UI 코드에서 가장 실수하기 쉬운 지점이다. 마지막 값을 캐시해 두고 화면에 계속 그리는 건 자연스러운 구현이지만, 여기서는 요구사항 위반이다.

§6.5.3은 한 발 더 나간다.

"차량 내 HMI 및 모바일 인터페이스는 차량 상태 정보가 최신이 아닌 경우 해당 정보가 최신 상태가 아님을 사용자에게 표시해야 한다."

즉 값을 지우는 것만으로는 부족하고, "이건 최신이 아니다"라는 것 자체를 보여줘야 한다. 회색 처리, "확인 중", 타임스탬프 표기 같은 UX가 요구사항 레벨에서 강제된 셈이다.

TBD-022가 여기 걸려 있다 — "센싱/Vision 데이터 최대 age", 초기 제안은 "센서 종류별 유효 시간 확정".

패턴 E — "같은 목표의 반복 요청은 반복 구동이 아니다"

시스템은 현재 윈도우 상태와 동일한 목표의 요청이 반복되더라도 의도하지 않은 반복 구동이 발생하지 않도록 해야 한다. (§6.2.1)
시스템은 현재 도어 잠금 상태와 동일한 목표의 요청이 반복되더라도 의도하지 않은 반복 구동이 발생하지 않도록 해야 한다. (§6.4.1)

멱등성(idempotency) 요구사항이다. 이미 잠긴 문에 "잠금" 명령을 열 번 보내도 액추에이터가 열 번 물리적으로 움직이면 안 된다. 잠금 액추에이터는 기계 부품이고 수명이 유한하며, 소음도 발생한다.

구현은 보통 두 층으로 한다.

1. 목표 상태 비교 — 현재 상태 == 요청 목표면 액추에이터 호출을 건너뛴다.
2. 디바운스/쿨다운 — 그래도 상태 판독이 흔들릴 수 있으므로 최소 재구동 간격을 둔다.

단, 1번만으로 끝내면 함정이 있다. 현재 상태를 신뢰할 수 없을 때 비교 자체가 성립하지 않는다. §6.4.1이 그래서 별도로 "도어 상태를 신뢰할 수 없는 경우 해당 상태를 정상 상태로 확정하여 사용하지 않아야 한다"를 갖고 있다.

---

5. 프로토타입이라서 생긴 경계선 — §7 가정사항·제약

이 시스템은 양산차가 아니다. 무엇이 범위 밖인지 정확히 아는 것이 SR을 읽는 절반이다.

함정 — "제외한다"를 "안 해도 된다"로 읽지 말 것 §7.2는 "세부 부품 모델, 센서 구현 방식, 회로 구성, 구동 전압·전류, 핀맵 및 배선과 같은 하드웨어 상세 설계 항목은 SR 에서 고정하지 않고 하드웨어 설계서 또는 조달 문서에서 관리한다"고 한다. SR에서 제외 = 다른 문서에서 관리이지, 하지 않음이 아니다. §9의 마지막 원칙과 같은 이야기다.

---

6. 왜 요구사항이 이렇게 잘게 쪼개져 있는가 — §9

§6 도입부와 §9가 같은 말을 두 번 한다.

§6 "하나의 요구사항에는 하나의 주요 동작 또는 독립적으로 검증 가능한 목적을 작성한다. 서로 다른 기능·조건·결과가 독립적으로 검증 가능한 경우 별도 요구사항으로 분리한다." §9 "하나의 문장에 서로 독립적으로 검증 가능한 둘 이상의 기능, 조건 또는 결과가 포함되는 경우 별도의 요구사항으로 분리한다."

"검증 가능"이 분리 기준이다. 두 개의 결과를 한 문장에 넣으면, 시험에서 하나는 통과하고 하나는 실패했을 때 그 요구사항의 판정이 애매해진다.

예를 들어 이렇게 쓰면 안 된다.

✗ 시스템은 끼임 위험을 감지한 경우 닫힘을 정지하고 열림 방향으로 보호 동작을 수행하며
  사용자에게 알리고 자동 재개하지 않아야 한다.

SR은 이걸 §6.2.4에서 다섯 문장으로 쪼갰다.

✓ 시스템은 윈도우가 닫힘 방향으로 이동하는 동안 끼임 위험을 감지해야 한다.
✓ 시스템은 끼임 위험을 감지한 경우 진행 중인 윈도우 닫힘 동작을 즉시 정지해야 한다.
✓ 시스템은 끼임 위험으로 닫힘 동작을 정지한 경우 정의된 보호 위치까지 열림 방향의 보호 동작을 수행해야 한다.
✓ 시스템은 Anti-pinch 보호 동작이 발생한 경우 해당 발생 상태를 사용자에게 제공해야 한다.
✓ 시스템은 Anti-pinch 보호 동작이 완료된 경우 보호 동작 결과를 사용자에게 제공해야 한다.
✓ 시스템은 Anti-pinch 보호 동작이 종료된 후 새로운 유효 요청이 확인되기 전까지 ... 자동으로 재개하지 않아야 한다.

각각이 별도의 시험 항목이 된다. 감지는 되는데 정지가 늦다와 정지는 하는데 열림 보호를 안 한다는 완전히 다른 결함이고, 분리된 요구사항만이 이 둘을 구분해 낸다.

"해야 한다" 형식과 책임 주체

§9 "요구사항은 책임 주체와 수행 동작이 명확한 '해야 한다' 형식으로 작성한다."

SR 문장의 주어를 보면 세 종류다.

세 번째 형식이 중요하다. **"사용자는 ~할 수 있어야 한다"**는 시스템 동작이 아니라 사용자에게 보장되는 능력을 규정한다. 그래서 §6.5.1은 이렇게 갈라 쓴다.

"차량 내 HMI 및 모바일 인터페이스는 기능 제어 요청을 생성할 수 있으나, 차량 기능의 실제 수행 여부는 해당 기능의 허용 조건 및 안전 정책에 따라 결정되어야 한다."

요청 생성 능력 ≠ 실행 보장이다. 이게 이 시스템 전체 아키텍처의 요약이기도 하다. HMI는 요청을 만들 뿐이고, 판단은 기능이 한다.

---

7. TBD 32건 — 미정을 관리하는 방법

§8의 표에는 TBD가 32건 있다. 번호는 038까지 가지만 023~026, 028, 035, 037이 비어 있다 — 통합·삭제된 항목의 흔적이고, 번호를 재사용하지 않는 게 옳다(과거 회의록·이슈 참조가 깨지므로). "아직 안 정했다"를 문서에 명시적으로 남긴다는 게 핵심이다.

§9 "미확정 통신 방식, 센서 임계값, 법규 적용 범위 및 성능 수치는 TBD 로 관리한다."

TBD의 성격을 분류해 보면 이 프로젝트가 어디쯤 와 있는지 보인다.

TBD 중 서로 얽힌 것들

몇몇 TBD는 참조 절이 명시돼 있다. 이건 "이 값을 정하면 저 요구사항 문장의 의미가 확정된다"는 뜻이다.

TBD-022(데이터 최대 age)가 가장 넓게 퍼져 있다. 이 값 하나가 "신뢰할 수 없음"의 정의를 결정하고, 그게 패턴 A·D 전부의 트리거이기 때문이다. TBD-038이 "TBD-022 데이터 age 와 별개"라고 명시돼 있는 것도 의미가 있다 — "언제 오류로 볼 것인가"와 "언제 복구로 볼 것인가"는 대칭이 아니다. 보통 복구 판정이 더 보수적이다(연속 N회 정상 수신 요구).

---

8. 한 줄 요약

---

설계 판단 체크포인트

구현에 들어가기 전에 팀이 답을 갖고 있어야 하는 것들이다. 답이 안 나오면 그 자리가 곧 설계 문의 또는 TBD 후보다.

1. Central Controller와 VSS를 같은 칩에 둔 것의 단점은? CPU/메모리/인터럽트 공유 → 오디오 DMA와 제어 태스크의 자원 경합. 한 기능의 무한 루프가 다른 기능을 같이 죽인다(freedom from interference가 소프트웨어 레벨에서만 보장됨). 별도 노드였다면 물리적 격리가 공짜로 따라왔을 것.

2. "통신 오류"의 정의가 "수신 실패"가 아니라 "신뢰할 수 없는 상태"인 이유는? 프레임은 정상 수신되지만 값이 오래된 경우(송신 노드가 멈춤, 주기 지연)를 포함하기 위해서다. 그래서 TBD-020(Heartbeat/Timeout)과 TBD-022(최대 age)가 둘 다 필요하다.

3. §6.4.4의 "오류 복구만을 근거로 자동 재개하지 않는다"를 어기면 어떤 사고가 나는가? 통신이 끊겨 자동 공조가 멈췄고, 그 사이 사용자가 창문을 열었다고 하자. 통신 복구 순간 마지막 명령("Fan HIGH")이 되살아나면, 사용자가 만든 새 환경을 무시한 동작이 예고 없이 시작된다. 재평가 후 동작이라는 순서가 이걸 막는다.

4. §6.2.2는 "시작하지 않아야 한다", §6.2.4는 "즉시 정지해야 한다"로 동사가 다르다. 왜? 전자는 정보 부족 상황(위험이 확인된 게 아님)이므로 새 동작 억제로 충분하다. 후자는 위험이 확인된 상황이므로 진행 중인 동작까지 끊어야 한다. 정보 없음 ≠ 위험 있음이 동사 차이로 표현돼 있다.

5. TBD를 문서에 남기지 않고 임의 값으로 채웠다면 무엇이 나빠지는가? 임의 값이 시험 기준이 되어 "통과"로 기록되고, 나중에 실제 값이 정해졌을 때 어떤 요구사항을 재검증해야 하는지 추적할 수 없게 된다. TBD ID가 있으면 §9의 마지막 원칙 — "요구사항 변경 시 관련 기능 요구사항, 기능별 상태, HMI 표시 및 시험 항목의 영향을 함께 검토한다" — 을 실제로 수행할 수 있다.