12. 시스템 요구사항(SysRS) 초안 — 누가 무엇을 책임지는가

⚠️ SR에 없는 문서다. §9가 "Controller 간 내부 명령 전달, 상태 교환, 세부 중재 및 실행 메커니즘은 SysRS 또는 설계 문서에서 정의한다"고 미뤄 둔 자리를 채우는 초안이다. 11편의 V모델에서 왼팔의 두 번째 층이고, 지금까지 통째로 비어 있던 곳이다. 팀 합의 전까지 확정이 아니다.

1. SysRS는 SR과 무엇이 다른가

SR은 **"시스템은 ~해야 한다"**라고만 쓴다. 어느 노드가 하는지는 의도적으로 안 정한다.

SR     "시스템은 끼임 위험을 감지한 경우 진행 중인 윈도우 닫힘 동작을 즉시 정지해야 한다"
         ↓  누가?  무엇을 근거로?  결과를 누구에게 알리나?
SysRS  "Power Window Controller는 닫힘 구동 중 1 ms 주기로 모터 전류와 회전 속도를
        평가하여 끼임 위험을 판정하고, 판정 시 통신을 거치지 않고 로컬에서 모터를
        정지시켜야 한다. 판정 결과는 Central Controller에 이벤트로 통지해야 한다."

세 가지가 추가된다.

추가되는 것	예
책임 노드	Power Window Controller가 한다
판정 근거와 주기	전류·속도를 1 ms 주기로
노드 간 교환	결과를 Central에 이벤트로 통지

왜 이 층이 필요한가

SR만 있으면 두 사람이 같은 요구사항을 읽고 다른 시스템을 만든다.

§6.4.3의 표시 우선순위를 예로 들면 — SR은 "Emergency를 Fault보다 우선해야 한다"고만 한다. 그럼 그 우선순위 선택을 Function Controller가 하나, Central Controller가 하나? 둘 다 요구사항을 만족시키는데 시스템 구조가 완전히 달라진다.

이 선택을 적어 두는 문서가 SysRS다.

2. SR 요구사항 → 노드 할당

이 표가 이 문서의 핵심이다. SR의 각 절이 어느 노드의 책임이 되는지를 못 박는다.

SR 절	판단	실행	입력 제공	표시
§6.1 VSS 오디오	Central	Central (오디오 경로)	Power Window·Sensing·Function	ESP32 (오류만)
§6.2 파워윈도우	Power Window(안전) / Central(중재)	Power Window	ESP32·Central·Function	ESP32
§6.3.1~2 센싱	Sensing(유효성) / Central(환경 판단)	—	Sensing 센서	ESP32
§6.3.3 초음파 근접	Sensing	—	Sensing 센서	ESP32·Central(VSS)
§6.3.5 엔진룸 CV	Vision	—	Vision 카메라	ESP32·Central(VSS)
§6.4.1 Smart Access	Central	Function	ESP32 (BLE 인증·근접)	ESP32·Function(조명)
§6.4.2 Predictive Climate	Function	Function / Power Window(환기)	Sensing·Vision	ESP32
§6.4.3 Ambient Lighting	Function	Function	Central(안전 상태)·Sensing(조도)	ESP32 (오류만)
§6.5 HMI·모바일	ESP32	ESP32	Central (종합 상태)	ESP32
§6.6 기능별 상태	각 노드 + Central(집계)	—	전 노드	ESP32

이 표에서 결정된 것 셋

① 판단이 항상 Central에 있지 않다.

00편에서 "판단은 Central로 모인다"고 했는데, 정확히는 기능이 한 노드 안에서 닫히면 그 노드가 판단한다.

Fan 소유권 중재      Function 안에서 닫힌다   → Function이 판단
Ambient 표시 우선순위 Function 안에서 닫힌다   → Function이 판단
Smart Access 허용    ESP32(인증)·Function(액추에이터)·Central(도어 상태)에 걸친다
                                              → Central이 판단

판단 위치의 기준: 그 판단에 필요한 입력이 한 노드 안에 다 있는가.

② Anti-pinch만 판단·실행이 같은 노드에서 통신 없이 닫힌다.

§6.2.5가 요구하는 것이라 다른 선택지가 없다. 이건 아키텍처 제약 요구사항이다.

③ ESP32는 표시와 인증만 한다. 판단을 하지 않는다.

§6.5.1의 "요청 생성 능력 ≠ 실행 보장"이 노드 할당으로 표현된 것이다.

3. 노드별 시스템 요구사항

3-1. Power Window Controller (S32K144)

SYS-PW-01  닫힘 구동 중 모터 전류와 회전 속도를 주기적으로 평가하여
           끼임 위험을 판정해야 한다.                          (§6.2.4-1)
SYS-PW-02  끼임 판정 시 통신 수신 여부와 무관하게 로컬에서 모터
           구동을 정지시켜야 한다.                     (§6.2.4-2, §6.2.5-1)
SYS-PW-03  정지 후 정의된 보호 위치까지 열림 방향으로 구동해야 한다. (§6.2.4-3)
SYS-PW-04  보호 동작 발생·완료를 Central Controller에 이벤트로
           통지해야 한다.                              (§6.2.4-4,5)
SYS-PW-05  보호 래치를 유지하고, 새로운 유효 요청의 상승 엣지가
           확인될 때까지 닫힘 구동을 시작하지 않아야 한다.       (§6.2.4-6)
SYS-PW-06  윈도우 위치와 그 신뢰 상태를 관리하고 Central에
           주기적으로 통지해야 한다.                          (§6.2.6-2)
SYS-PW-07  Anti-pinch 판정 기능의 가용 여부를 Central에 통지해야 한다. (§6.2.2-4)
SYS-PW-08  전용 윈도우 스위치 입력을 통신과 무관하게 처리해야 한다.  (§6.2.5-2)
SYS-PW-09  수신한 제어 요청의 출처를 구분하고, 정의된 우선순위에
           따라 처리해야 한다.                              (§6.2.1-5~8)
SYS-PW-10  요청 처리 결과(수락·진행·완료·거부·중단)와 거부 사유를
           Central에 통지해야 한다.                    (§6.2.2-6, §6.2.6-4)

SYS-PW-07이 SR에 없던 것이다. §6.2.2는 "Anti-pinch를 사용할 수 없는 경우 닫힘을 시작하지 않아야 한다"고만 하는데, 그 가용성을 Central과 HMI가 미리 알아야 버튼을 비활성화해 보여줄 수 있다. 요구사항을 노드에 할당하다 보면 이런 신호가 드러난다.

3-2. Sensing Controller (S32K144)

SYS-SN-01  조도·실내 온도·실내 습도·후방 거리를 정의된 주기로
           측정해야 한다.                                    (§6.3.1)
SYS-SN-02  각 센싱 값에 대해 범위·신선도·복구 이력 세 기준으로
           유효 상태를 판정해야 한다.                          (§6.3.4)
SYS-SN-03  센싱 값과 그 유효 상태를 항상 함께 통지해야 한다.       (§6.5.3-3)
SYS-SN-04  후방 거리로부터 근접 위험 상태와 근접 위험 단계를
           산출해야 한다.                                    (§6.3.3)
SYS-SN-05  근접 거리 원값과 근접 위험 단계를 모두 통지해야 한다.    (§6.3.3-3,4)
SYS-SN-06  Vision Module의 판정 결과를 수신하여 차량 네트워크로
           중계해야 한다.                                    (§4.1)
SYS-SN-07  Vision 링크의 통신 상태를 감시하고 결과의 유효 상태에
           반영해야 한다.                                    (§6.3.4-4)
SYS-SN-08  특정 센서의 오류가 다른 센서의 측정·통지를 중단시키지
           않아야 한다.                                      (§6.3.2-3)

SYS-SN-05가 설계 결정이다. 03편에서 본 대로 원값(VSS의 연속 경고음 간격)과 단계(HMI 바 표시)의 소비처가 다르므로 둘 다 올린다. 단계만 올리면 Central이 VSS 2단계 매핑을 독자적으로 못 한다.

3-3. Function Controller (S32K144)

SYS-FN-01  Central이 허용한 도어 제어 명령만 액추에이터에 반영해야 한다. (§6.4.1)
SYS-FN-02  도어 잠금 상태와 물리적 개폐 상태를 독립적으로 관리하고,
           비정상 조합을 별도 상태로 통지해야 한다.              (§6.4.1-3)
SYS-FN-03  도어 제어 후 실제 목표 상태 도달을 확인한 뒤에만
           정상 완료로 통지해야 한다.                          (§6.4.1-6)
SYS-FN-04  액추에이터 구동 시간이 정의된 상한을 초과하면 소프트웨어
           상태와 무관하게 구동을 차단해야 한다.                 (§6.4.1-6)
SYS-FN-05  Fan 을 사용하는 기능 중 하나만이 임의 시점에 Fan 을
           소유하도록 관리해야 한다.                           (§6.4.2-4)
SYS-FN-06  Fan 소유권 전환 시 이전 기능의 출력 상태를 보존하지
           않아야 한다.                                      (§6.4.2-4)
SYS-FN-07  요구 Fan 출력과 실측 Fan 상태를 대조하고, 정의된 허용
           시간을 넘는 불일치를 오류로 통지해야 한다.            (§6.4.2-7)
SYS-FN-08  Window 기반 자동 환기 시 Power Window에 요청만 하고,
           요청 거부 결과를 자동 환기의 완료 판정에 반영해야 한다. (§6.4.2-5)
SYS-FN-09  Ambient Lighting 표시 요구를 수집하여 정의된 우선순위에
           따라 매 판정 주기마다 최우선 항목을 새로 선택해야 한다. (§6.4.3-5)
SYS-FN-10  선점되어 중단된 일시적 표시의 상태를 보존하지 않아야 한다. (§6.4.3-5)
SYS-FN-11  안전 관련 표시의 밝기가 사용자 설정 및 자동 조절 경로를
           거치지 않도록 해야 한다.                            (§6.4.3-6)

SYS-FN-06과 SYS-FN-10이 같은 요구를 두 기능에 각각 적용한 것이다. "상태를 보존하지 않는다"를 요구사항으로 쓰면, 구현에서 저장 변수를 만드는 순간 위반이 눈에 띈다. 자동 재개 금지를 구조로 강제하는 방식이다.

3-4. Central Controller + VSS (S32K344-WB)

SYS-CE-01  전 노드의 기능별 상태와 오류를 수집하여 종합 상태를
           유지해야 한다.                                    (§6.6)
SYS-CE-02  수집한 상태에 대해 송신 노드별 통신 유효성을 판정하고,
           유효하지 않은 상태를 정상으로 취급하지 않아야 한다.    (§6.5.3-3)
SYS-CE-03  차량 전원 상태(OFF/ACC/ON/START)를 관리하고 전 노드에
           통지해야 한다.                                    (§5, TBD-027)
SYS-CE-04  실내 고온·탑승자 유무·도어 잠금·차량 사용 종료를 조합하여
           잔류 탑승자 위험 상태를 판정해야 한다.               (§6.3.2)
SYS-CE-05  Digital Key 인증 결과와 근접 상태를 수신하여 자동 도어
           제어의 허용 여부를 판정해야 한다.                    (§6.4.1-1)
SYS-CE-06  음향 요구를 정의된 우선순위로 중재하고, 상위 음향 발생 시
           진행 중인 하위 음향을 중단해야 한다.                 (§6.1.2)
SYS-CE-07  동일 등급 피드백 음향이 중첩되지 않도록 최소 간격을
           보장해야 한다.                                    (§6.1.2-5)
SYS-CE-08  안전 관련 음향의 출력 음량이 사용자 설정 및 야간 감쇄에
           의해 식별 불가 수준으로 낮아지지 않도록 해야 한다.     (§6.1.3)
SYS-CE-09  VSS 입력 정보 불신과 VSS 자체 오류를 구분하여 처리해야
           한다 — 전자는 음향으로, 후자는 HMI로 통지한다.        (§6.1.4)
SYS-CE-10  오류 복구 시 마지막 수신 값이 아니라 최신 입력으로 관련
           기능 상태를 재평가해야 한다.                        (§6.4.4)

SYS-CE-09가 §6.1.4의 두 오류를 노드 동작으로 옮긴 것이다. 소리를 낼 수 있으면 소리로, 낼 수 없으면 화면으로 — 알림 채널 이중화가 요구사항이 된다.

3-5. Vision Module (Raspberry Pi 3 B)

SYS-VI-01  실내 카메라 영상으로 탑승자 존재 여부와 인원 수를
           판정해야 한다.                                    (§6.3.1)
SYS-VI-02  엔진룸 카메라 영상으로 대상 동물 진입 여부를 정의된
           트리거 또는 주기에 따라 판정해야 한다.               (§6.3.5-2)
SYS-VI-03  프레임 품질을 평가하고, 인식 기준을 만족하지 못하는
           프레임의 결과를 유효로 통지하지 않아야 한다.          (§6.3.4-5)
SYS-VI-04  판정 결과와 함께 품질 미달 사유를 구분 가능한 코드로
           통지해야 한다.                                    (§6.5.3-4)
SYS-VI-05  카메라 원본 영상을 판정 목적 범위를 벗어나 외부로
           전송하거나 상시 저장하지 않아야 한다.                (§6.3.4)
SYS-VI-06  엔진룸 판정의 지연·실패가 실내 탑승자 인식의 주기와
           정확도에 영향을 주지 않아야 한다.                    (§6.3.4-8)

SYS-VI-06이 구조를 강제한다. 두 추론을 같은 실행 흐름에 두면 이 요구사항을 만족시킬 수 없다. 별도 프로세스·스레드가 필수가 된다.

SYS-VI-04도 SR에서 역산된 것이다. §6.5.3이 오류 종류 구분을 요구하는데, 비전 결과에 valid 비트만 있으면 렌즈 오염과 야간 저조도를 구분할 수 없다.

3-6. HMI / Digital Key (ESP32)

SYS-HM-01  BLE Digital Key 의 인증을 수행하고 결과를 Central에
           통지해야 한다.                                    (§6.4.1-1)
SYS-HM-02  수신 신호 세기를 필터링·히스테리시스·유지 시간을 적용하여
           접근·근접·이탈 상태로 판정해야 한다.                 (TBD-016)
SYS-HM-03  인증 및 차량별 권한 확인이 완료된 사용자에게만 원격
           제어 요청 생성을 허용해야 한다.                     (§6.5.2-1)
SYS-HM-04  제어 요청을 생성만 하고, 실행 여부를 자체 판단하지
           않아야 한다.                                      (§6.5.1-4)
SYS-HM-05  요청 상태와 차량 상태를 분리하여 표시해야 한다.
           요청 전송을 차량 상태 변경으로 표시하지 않아야 한다.   (§6.5.1-2)
SYS-HM-06  통신 종료 시 미완료 요청을 자동으로 재전송하지 않아야
           하며, 결과 확인 불가 상태로 표시해야 한다.           (§6.5.2-3)
SYS-HM-07  수신 상태의 나이를 평가하여, 최신이 아닌 정보를 최신으로
           표시하지 않아야 한다.                              (§6.5.3-2,3)
SYS-HM-08  센서 오류·통신 오류·기능 자체 오류를 구분하여 표시해야
           한다.                                            (§6.5.3-4)
SYS-HM-09  사용자가 확인하지 않은 중요 경고를 보존하고 조회 가능하게
           해야 한다.                                        (§6.5.4-5)

SYS-HM-05가 "낙관적 UI 금지"를 요구사항 문장으로 만든 것이다. SR에는 이 표현이 없지만, §6.5.1의 "실제 수행 여부는 기능이 결정한다"를 HMI 구현으로 옮기면 이 문장이 나온다.

4. 노드 간 교환 요구사항

바이트 배치는 네트워크 인터페이스 명세서(10편이 초안)의 몫이고, 여기서는 무엇을 언제 주고받아야 하는가만 정한다.

SYS-IF-01  모든 상태 신호는 값과 유효 상태를 함께 전달해야 한다.
SYS-IF-02  모든 노드는 생존을 알리는 신호를 정의된 주기로 송신해야 한다.
SYS-IF-03  수신 노드는 송신 노드의 생존, 신호의 나이, 송신 태스크의
           동작 여부를 각각 판정할 수 있어야 한다.
SYS-IF-04  제어 명령은 중복·역순·손상·지연된 프레임에 의해 실행되지
           않아야 한다.                                      (§6.2.5-4)
SYS-IF-05  안전 관련 이벤트는 주기 전송을 기다리지 않고 발생 즉시
           송신해야 하며, 버스 경합에서 우선해야 한다.          (§6.1.2-1)
SYS-IF-06  상태 신호는 변화 시점과 정의된 주기 양쪽에서 송신해야 한다.
SYS-IF-07  설정 값은 변경 시점과 저빈도 주기 양쪽에서 송신해야 한다.

SYS-IF-03이 세 층 감시를 요구사항으로 만든 것이다. 생존(heartbeat)·나이(max age)·태스크 동작(alive counter) 중 하나만 있으면 잡지 못하는 고장이 있다.

SYS-IF-05가 CAN ID 배정을 제약한다. §6.1.2의 "안티핀치를 최우선으로"를 만족시키려면 소프트웨어 우선순위만으로 부족하고, 버스 아비트레이션에서도 이겨야 한다.

5. SR이 말하지 않은 중재 규칙

SR은 "우선하여 처리해야 한다"까지만 말한다. 동시에 발생했을 때 실제로 무슨 일이 일어나는가는 SysRS가 정해야 한다.

5-1. 윈도우 요청 중재

SYS-AR-01  더 높은 우선순위의 유효 요청이 도착하면 진행 중인 하위
           요청을 중단하고, 중단 결과를 통지해야 한다.
SYS-AR-02  중단된 하위 요청은 대기열에 보존하지 않아야 한다.
SYS-AR-03  동일 출처의 반복 요청은 목표 상태가 현재 상태와 같으면
           액추에이터 구동으로 이어지지 않아야 한다.

SYS-AR-02가 필요한 이유 — SR의 자동 재개 금지는 Anti-pinch와 Fan·조명에만 명시돼 있고 윈도우 요청 중재에는 없다. 그런데 원격 요청이 스위치 조작에 밀렸다가 나중에 되살아나면 사용자가 예측할 수 없는 동작이 된다. 같은 원칙을 여기까지 확장하는 것이 정합적이다.

5-2. 음향 중재

SYS-AR-04  선점된 음향은 재생 대기열에 보존하지 않아야 한다.
SYS-AR-05  안티핀치 위험 중 감쇄된 일반 음향은 위험 해제 후 음량만
           복구하고, 중단된 음향을 재생하지 않아야 한다.

SYS-AR-05가 08편 §5에서 지적한 SR 모호성을 해소하는 안이다. §6.1.2는 "즉시 중단"이라 하고 §6.1.3은 "이전에 재생 중이던 일반 음향을 Fade-in 복구"라 하는데, 두 문장이 다른 상태 모델을 전제한다. 감쇄 상태로 살려 두고 음량만 복구하는 쪽으로 통일하면 둘이 모순되지 않는다.

이건 SysRS가 임의로 정할 게 아니라 SR 작성자에게 확인해야 하는 항목이다. 여기서는 잠정안으로 적어 둔다.

5-3. Ambient 표시 중재

SYS-AR-06  표시 항목의 수명을 시간 기반과 상태 기반으로 구분하여
           관리해야 한다.
SYS-AR-07  선점된 일시적 표시의 잔여 시간은 선점 중에도 소진되며,
           선점 해제 시 재개하지 않아야 한다.

SYS-AR-07이 06편에서 SR이 답하지 않은 부분이다. 어차피 재개하지 않으므로 수명이 흐르든 멈추든 결과는 같지만, 구현이 달라지므로 명시해야 한다.

6. SysRS에서 닫히는 TBD

11편에서 "TBD 32건 중 상당수가 사실 SysRS에서 결정될 항목"이라고 했는데, 구체적으로 이렇다.

TBD	SysRS에서 결정	비고
TBD-001	노드 간 물리 통신 방식	하드웨어 제약(TBD-002)과 함께
TBD-002	CAN 파라미터·메시지 정책	부하 계산이 근거
TBD-003	Vision 링크 방식	이벤트 방향성이 근거
TBD-020	생존 신호 주기·타임아웃	SYS-IF-02,03
TBD-021	상태 재전송 정책	SYS-IF-06
TBD-022	신호별 최대 나이	TBD-020·021 확정 후
TBD-027	차량 전원 상태 생성 주체	SYS-CE-03에서 Central로 잠정
TBD-034	동물 진입의 표시 등급	정책 결정 — SysRS가 아니라 회의

나머지는 벤치 시험(하드웨어 설계서)이나 정책 회의의 몫이다. SysRS가 모든 TBD를 닫지는 않는다.

7. 한 줄 요약

항목	한 줄
SysRS가 하는 일	SR의 "시스템은"에 책임 노드·판정 근거·노드 간 교환을 붙인다
노드 할당 원칙	판단에 필요한 입력이 한 노드에 다 있으면 그 노드가 판단한다
예외	Anti-pinch만 판단·실행이 통신 없이 로컬에서 닫힌다
역산으로 드러난 것	Anti-pinch 가용성 통지, 비전 품질 사유 코드, 낙관적 UI 금지
노드 간 요구	값+유효성 동반, 생존·나이·태스크 3층 감시, 안전 이벤트 즉시 송신
SR이 안 정한 중재	선점된 요청·음향·표시를 보존하지 않는다로 통일
남는 것	정책 TBD 4건은 SysRS로 못 닫는다. 회의가 필요하다

설계 판단 체크포인트

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

Ambient 표시 우선순위 선택을 Function이 하는 것이 맞는가? 이 문서는 Function에 뒀다(SYS-FN-09). 근거는 "표시 요구 수집과 조명 출력이 한 노드에 있다"는 것인데, Warning/Fault/Emergency 판정은 Central이 한다. 즉 등급 판정은 Central, 표시 선택은 Function으로 갈린다. Central이 이미 등급을 매겨 보내는데 우선순위 선택까지 Central이 하는 게 단순할 수도 있다.
근접 위험 단계 산출을 Sensing에 두는 것이 "판단은 Central" 원칙과 충돌하지 않나? 충돌한다. 다만 거리→단계 변환은 센서 특성에 밀착한 계산이고 §6.3.3이 센싱 절에 두었다. 원값도 함께 올리는 것을 전제로 Sensing에 배치했다(SYS-SN-05). 원값을 안 올리면 이 배치는 성립하지 않는다.
Fan 소유권 중재가 Function 안에서 닫히는가? 자동 공조와 공기 순환은 Function 안이지만, Pre-conditioning의 시작 판단은 예상 탑승 시점에 의존한다. 그 학습 데이터를 어느 노드가 갖는가에 따라 달라진다 — Central이면 Fan 소유권도 Central로 올라가야 할 수 있다.
SYS-AR-05(음향 복구를 음량 복구로 한정)를 SysRS가 정해도 되는가? 안 된다. SR의 두 문장이 모순되는 것이라 작성자 확인이 필요하다. SysRS가 임의로 해석하면 나중에 SR이 다른 의미였을 때 전면 재작업이 된다. 이 문서에는 잠정안으로만 적었다.
SYS-PW-07(Anti-pinch 가용성 통지)처럼 SR에 없는 요구사항을 SysRS가 추가해도 되는가? 추가 자체는 정상이다 — SysRS의 역할이 SR을 구현 가능한 형태로 분해하는 것이다. 다만 "이건 SR에서 온 것이 아니라 분해 과정에서 도출된 것"임을 표시해야, 나중에 SR이 바뀔 때 이 요구사항이 여전히 필요한지 판단할 수 있다.
요구사항 ID를 SysRS에는 붙였는데 SR에는 없다. 추적이 되는가? 반쪽만 된다. SYS-PW-02 ← §6.2.4-2, §6.2.5-1 처럼 절-순번으로 거슬러 올라가는데, SR 문장 순서가 바뀌면 이 참조가 깨진다. SR 개정 시 이 매핑을 함께 갱신하는 절차가 필요하고, 그게 §9의 변경 영향 분석에 포함되어야 한다.