[DoIP 마스터 가이드 2편] 차량은 어떻게 찾고, 진단 길은 어떻게 뚫을까? (Vehicle Discovery & Routing Activation)

안녕하세요, DevBJ입니다! 😎

[👉 지난 1편]에서는 우리가 왜 CAN 대신 이더넷과 DoIP를 쓰게 되었는지, 그리고 개발자들 뒤통수를 치는 TCP 프레이밍(Framing)의 비밀에 대해 알아봤죠. 뼈대를 단단하게 잡았으니 이제 진짜 실전으로 들어갈 차례입니다.

랜선(이더넷 케이블)을 차에 꽂았다고 해서 마법처럼 통신이 되는 게 아닙니다. CAN 통신 시절에는 그냥 버스(Bus)에 메시지를 틱 던지면 끝이었지만, IP 기반인 DoIP 환경에서는 내 타겟이 누군지(어떤 IP를 쓰는지) 직접 찾아야 하고, 진단을 해도 되는지 허락(길 뚫기)도 받아야 합니다.

📌 [DoIP 마스터 가이드 시리즈 목차]

• ▶ [DoIP 마스터 가이드 1편] 왜 CAN 대신 이더넷일까? (탄생 배경과 패킷 구조, TCP 프레이밍의 함정)
• 👉 [DoIP 마스터 가이드 2편] 차량은 어떻게 찾고, 진단 길은 어떻게 뚫을까? (Vehicle Discovery & Routing Activation)
• 👉 [DoIP 마스터 가이드 3편] 본격적인 진단 시작! UDS 페이로드와 세션 유지의 비밀 (SA/TA & Tester Present)
• 👉 [DoIP 마스터 가이드 4편] 혈압 오르는 NRC 완벽 분석! 실전 트러블슈팅 가이드 (0x13, 0x22, 0x31, 0x78 등)
• 👉 [DoIP 마스터 가이드 5편] 실무 끝판왕! 펌웨어 전송과 다중 ECU 게이트웨이 라우팅 완벽 해부 (完)

 

오늘은 진단 통신의 멱살을 잡고 하드캐리하기 위한 필수 관문, 'Vehicle Discovery'와 'Routing Activation'을 친근하게 털어보겠습니다.

---

1. 너 내 동료가 돼라! 차량 찾기 (Vehicle Discovery)

테스터(진단기)를 네트워크에 연결했을 때 가장 먼저 맞닥뜨리는 문제입니다. *"도대체 이 수많은 장비 중에 내 타겟 차량(혹은 ECU)은 IP가 뭐지?"*

여기서 등장하는 게 바로 Vehicle Identification (차량 식별) 단계입니다. 쉽게 말해 네트워크상에 대고 동네방네 소리를 치는 겁니다.

테스터 (UDP Broadcast): *"야! 여기 DoIP 지원하는 애들 다 손들어봐! 너네 IP랑 정보 좀 줘!"*

그러면 살아있는 차량(DoIP Entity)들이 대답합니다.

차량 1: *"나 여기 있어! 내 차대번호(VIN)는 이거고, 내 논리 주소(Logical Address)는 이거야!"*

구조는 엄청 직관적이죠? 하지만 이 UDP 기반 브로드캐스트 구간에서 생각보다 많은 분들이 멘붕을 겪습니다.

🚨 실무 삽질 포인트 1: 왜 차가 검색이 안 되죠? (Discovery 실패)

• 부팅 타이밍 문제: 테스터를 켜자마자 바로 Broadcast를 쐈는데 아무 응답이 없는 경우가 많습니다. 왜냐고요? 이더넷 PHY는 켜졌어도, 게이트웨이 내부 라우팅 테이블이나 DoIP 서비스가 아직 부팅 중(초기화 중)일 수 있거든요. 무조건 한 번 쏘고 포기하지 말고, Retry(재시도) 로직을 꼭 넣어두세요.
• 다중 네트워크 인터페이스 (Wi-Fi 켜짐 등): 테스트 PC에 유선 랜카드, Wi-Fi, VPN, Docker 가상 랜카드 등이 짬뽕되어 있으면, UDP Broadcast가 엉뚱한 허공(예: 사내 Wi-Fi 망)으로 날아가는 경우가 허다합니다. 코드 짜실 때 socket.bind()로 이더넷 어댑터를 정확히 콕 집어 명시해 주셔야 합니다.

---

2. IP 찾았다고 끝? No! 'Entity Status'부터 묻자

자, 어찌어찌 IP를 찾아서 TCP 소켓 연결(Connect)까지 맺었다고 칩시다.
여기서 성격 급한 분들은 바로 UDS 진단 메시지(0x22, 0x10 등)부터 마구 때려 붓습니다. 그리고는 *"어? 왜 응답이 없지? 타임아웃 나네?"* 하면서 패킷을 들여다보기 시작하죠.

잠깐! 패킷을 까보기 전에 이 질문부터 던져야 합니다.
"얘가 지금 진단을 받아줄 상태(전원/모드)이긴 한가?"

차량의 게이트웨이는 살아있지만, 정작 통신하려는 하위 ECU는 딥슬립(Deep Sleep) 상태이거나 특정 전원 모드(IGN ON)가 아니면 진단 메시지를 씹어버립니다.

이럴 때 유용하게 쓰는 게 바로 Entity Status / Power Mode 확인 요청입니다. 본격적인 진단(Routing Activation)을 날리기 전에, *"너 지금 상태 괜찮아? 진단받을 준비됐어?"* 라고 짧게 핑을 날려보는 거죠. 여기서 상태가 Ready로 확인된 다음에 진행하면 헛고생(불필요한 타임아웃 대기)을 확 줄일 수 있습니다.

---

3. 통신소, 길 터주세요! (Routing Activation)

차량도 찾았고 상태도 괜찮다면, 이제 DoIP 통신의 꽃이자 가장 중요한 관문인 Routing Activation(라우팅 활성화)을 거쳐야 합니다.

간단히 말해 "나(테스터)라는 녀석이 이 차량 네트워크 내부에 UDS 메시지를 쏠 테니, 길(경로)을 열어주고 내 정보를 등록해 줘!"라고 허락을 받는 과정입니다. 이 인증을 통과하지 못하면, 아무리 예쁜 UDS 메시지를 보내도 게이트웨이가 얄짤없이 컷(Drop) 해버립니다.

📝 Routing Activation은 어떻게 진행되나요?

1. 테스터 ➡️ 차량: Routing Activation Request를 쏩니다. 이때 가장 중요한 건 내 주소(Source Address)와 어떤 방식으로 붙을 건지(Activation Type)를 알려주는 겁니다.
2. 차량 ➡️ 테스터: Routing Activation Response를 돌려줍니다. 여기서 떨어지는 Response Code (응답 코드) 하나에 성공과 실패의 모든 원인이 담겨 있습니다.

🚨 실무 삽질 포인트 2: Routing Activation이 자꾸 실패해요!

가장 흔하게 겪는 실패 패턴들입니다.

• Source Address(SA) 충돌: 테스터 A와 테스터 B가 똑같은 소스 주소(예: 0x0E80)를 달고 동시에 붙으려고 하면 차량은 경로를 꼬아버리거나 한쪽을 거절합니다. 테스터마다 고유한 SA를 부여해야 합니다. (이 SA 꼬임 현상은 [👉 4편] 트러블슈팅에서 더 딥하게 다뤄볼게요!)
• Activation Type 오류: 제조사(OEM) 문서 제대로 안 읽고 디폴트 값 아무거나 찔러 넣으면 거절당합니다. OEM마다 요구하는 타입이 다를 수 있습니다.
• 라우팅은 성공했는데 UDS가 응답이 없어요!
  이게 진짜 환장하는 케이스인데요. Routing Activation 성공 응답을 받았다고 해서 모든 ECU에 접근 가능하다는 뜻은 아닙니다. 길은 뚫렸는데, 정작 내가 UDS를 쏘려는 목적지 ECU(Target Address)가 꺼져있거나, 잘못된 주소로 쏘고 있을 확률이 99%입니다. 이때는 DoIP를 의심하지 말고 UDS 레벨(SA/TA 주소 매핑)로 시선을 내려야 합니다.

---

📝 2편 마무리: 드디어 본게임 시작!

수고하셨습니다! Vehicle Discovery로 타겟을 찾고, TCP 연결 후 Routing Activation으로 든든한 진단 고속도로까지 뚫어냈습니다. 여기까지 오셨으면 DoIP 통신의 까다로운 인프라 설정은 다 끝난 셈입니다.

길이 뻥 뚫렸으니 이제 뭘 해야 할까요? 맞습니다. 진짜 목적이었던 UDS 진단 메시지(Diagnostic Message)를 쌩쌩 달려보내야죠!

다음 시간에는 이 뚫린 길 위에 UDS 메시지를 어떻게 태워 보내는지, 그리고 테스터가 연결을 잃지 않기 위해 계속 심장 박동(Tester Present)을 뛰게 하는 세션 제어의 비밀에 대해 파헤쳐 보겠습니다.

👉 [다음 글 보기: DoIP 마스터 가이드 3편 - 진단 통신과 UDS 제어 완벽 가이드]

궁금한 점이나 현재 트러블슈팅 중인 현상이 있다면 댓글로 남겨주세요. 다음 포스팅에서 뵙겠습니다. DevBJ였습니다!