[DoIP 마스터 가이드 시즌2 - 4편] 실전 엣지 케이스! "왜 이 상황에서만 통신이 죽을까? (完)

[DoIP 마스터 가이드 시즌2]의 마지막 여정에 오신 것을 환영합니다!
파이썬 파서도 만들고(1편), 패킷도 까보고(2편), UDS 심화 로직까지 뚫어냈다면(3편) 이제 웬만한 진단 통신 구현은 두렵지 않으실 겁니다.

📌 [DoIP 마스터 가이드 시즌 2: 실전 심화편 목차]

[IT/자동차] - [DoIP 마스터 가이드 시즌2 - 1편] 파이썬(Python)으로 직접 짜보는 DoIP 파서와 TCP 프레이밍 구현

[IT/자동차] - [DoIP 마스터 가이드 시즌2 - 2편] Wireshark 실전! 패킷 덤프(PCAP)로 뜯어보는 DoIP 흐름과 디버깅

[IT/자동차] - [DoIP 마스터 가이드 시즌2 - 3편] UDS 딥다이브! 악명 높은 보안 접속(0x27)과 루틴 제어(0x31) 해부

[IT/자동차] - [DoIP 마스터 가이드 시즌2 - 4편] 실전 엣지 케이스! "왜 이 상황에서만 통신이 죽을까? (完)

 

하지만 우리가 현업에서 다루는 차량 네트워크는 교과서처럼 예쁘게만 동작하지 않습니다. 테스트 벤치에서는 기가 막히게 잘 돌던 코드가, 실차에만 연결하면 간헐적으로 뻗어버리거나 알 수 없는 타임아웃을 발생시키며 피를 말리게 하죠.

오늘은 시리즈의 대미를 장식할 '고급 엣지 케이스(Edge Cases) 트러블슈팅'입니다. 진짜 삽질해 본 사람만 아는, 현업 밀착형 노하우 3가지를 대방출합니다.

---

엣지 케이스 1: 펌웨어 전송 중 S3 타임아웃과 P2*의 기묘한 줄다리기

펌웨어(Flash)를 지우는 작업을 지시(0x31 Erase Memory)했습니다. 이 작업은 낸드 플래시 특성상 10초~20초 가까이 걸립니다.
ECU는 테스터에게 안심하라며 7F 31 78 (Response Pending, 기다려!)을 계속 던집니다.

[현상]
테스터는 0x78을 받았으니 얌전히 기다리고 있는데, 한 10초쯤 지났을까? 갑자기 세션이 Default(0x01)로 툭 떨어지며 통신이 완전 초기화되어 버립니다.

[원인 분석: 타이머 간의 충돌]

• P2* Timer: "나(ECU) 작업 중이니까 0x78 보냈지? 테스터 너는 P2* 시간만큼 타임아웃 연장하고 기다려."
• S3 Timer (Session Timer): "테스터야, 5초 동안 너한테서 아무런 요청(Tester Present 등)이 없네? 너 죽은 줄 알고 세션 리셋할게."

즉, ECU 놈팽이가 지 혼자 작업하느라 바쁜 와중에, S3 타이머 로직이 테스터로부터의 입력을 감지하지 못하고 세션을 강제로 닫아버린 겁니다. (ECU 내부 소프트웨어의 고질적인 타이머 동기화 버그이기도 합니다.)

[해결책 (DevBJ's Tip)]
이런 바보 같은 ECU를 달래기 위해, 테스터는 0x78을 기다리는 '대기열(Blocking)'에 빠져 있더라도 백그라운드 스레드에서 무조건 Tester Present(0x3E 80)를 2초 간격으로 계속 때려줘야 합니다. 여기서 80 (Suppress Positive Response)을 꼭 넣어서 응답을 요구하지 않도록 만들어, 기존 P2* 대기 흐름을 방해하지 않고 심박수(S3)만 유지시키는 것이 핵심 비기입니다.

---

엣지 케이스 2: 쏟아지는 응답의 병목 현상 (Functional Routing 큐 오버플로우)

테스터가 네트워크의 전체 ECU 상태를 보기 위해 Functional Address(예: 0xE400)로 0x22 (ReadData) 요청을 날렸습니다.

[현상]
평소에는 응답이 잘 오다가, 네트워크에 ECU가 30개 이상 주렁주렁 매달린 풀옵션 차량에 연결했더니 응답이 중간에 끊기거나 게이트웨이가 DoIP 연결을 리셋해버립니다.

[원인 분석]
차량 내부의 게이트웨이(Gateway)는 30개의 하위 ECU에 UDS 메시지를 브로드캐스트로 뿌립니다. 그리고 30개의 ECU가 0.1초 만에 동시에 응답을 쏟아냅니다.
게이트웨이 내부의 이더넷 전송 큐(Tx Queue) 사이즈가 이 30개의 버스트(Burst) 트래픽을 감당하지 못하고 버퍼 오버플로우(Buffer Overflow)가 난 것입니다. 놀란 게이트웨이는 방어 기제로 TCP 소켓을 닫아버리죠.

[해결책 (DevBJ's Tip)]
이건 테스터 코드의 잘못이라기보다는 게이트웨이 성능 한계에 가깝습니다. 실무에서는 이런 현상을 피하기 위해, 전체 브로드캐스트를 날리기보다는 ECU들을 5~6개 그룹으로 쪼개서 순차적으로 Functional Request를 날리거나, 아예 번거롭더라도 개별 Physical 주소로 Loop를 돌며 쿼리(Query)하는 방식으로 우회하여 게이트웨이의 부담을 줄여야 합니다.

---

엣지 케이스 3: 멀티 테스터(Multi-Tester) 충돌과 SA(Source Address) 훔치기

[현상]
A 엔지니어가 차에 진단기를 꽂고 한참 펌웨어를 올리고 있습니다. 그런데 갑자기 연결이 펑! 하고 끊깁니다. 로그를 보니 DoIP 세션이 강제로 Drop 되었습니다.

[원인 분석]
B 엔지니어가 반대쪽에서 자기 노트북(무선 진단기)을 켜고 DoIP 연결을 시도했습니다. 하필 A와 B의 진단기 소프트웨어에 설정된 테스터 주소(Source Address)가 0x0E80으로 똑같았던 겁니다.
게이트웨이 입장에서는 "어? 0x0E80이 새로 붙네? 예전 연결은 죽었나 보군!" 하고 기존 A 엔지니어의 라우팅 테이블(소켓)을 무자비하게 걷어차 버리고 B의 연결을 받아준 것입니다.

[해결책 (DevBJ's Tip)]
DoIP 소프트웨어를 만들 때는 무조건 SA(Source Address)를 하드코딩하면 안 됩니다.
실행 시점(Runtime)에 설정 파일이나 사용자 입력을 통해 0x0E80 ~ 0x0E8F 대역 중 고유한 값(Randomize 또는 고정 할당)을 사용하도록 설계해야, 공장이나 서비스 센터 환경에서 여러 테스터가 동시에 한 차량에 붙었을 때 발생하는 끔찍한 간섭 현상을 막을 수 있습니다.

---

🚀 대단원을 마치며: 진짜 전문가로 가는 길

여기까지 잘 따라오셨나요? 시즌1의 기초부터 시즌2의 실전 엣지 케이스까지 모두 섭렵하신 여러분은 이제 평범한 진단 통신 개발자를 넘어, 시스템의 근본적인 구조와 한계를 이해하는 '트러블슈팅의 마스터'가 되셨습니다.

통신 이슈는 언제나 막막하고 답답하지만, 패킷 하나하나를 쪼개보고 로그를 분석하다 보면 결국 원인은 '물리적인 한계' 아니면 '논리적인 시퀀스 위반' 둘 중 하나로 귀결됩니다. 그 진리를 찾아가는 과정 자체가 임베디드 및 전장 개발의 진짜 묘미가 아닐까 싶습니다.

그동안 이 길고 깊은 가이드 시리즈를 함께해 주셔서 진심으로 감사합니다.
여러분의 현업 트러블슈팅에 한 줄기 빛이 되길 바라며, DevBJ는 더 재밌고 하드코어한(?) 개발 썰로 다시 돌아오겠습니다.

항상 버그 없는 평온한 칼퇴를 기원합니다! 🚀