DoIP(ISO 13400) 학습 로드맵: 구조 이해부터 진단 장애 분석까지

차량 진단 프레임워크나 전장 아키텍처를 다루다 보면 어느 순간 DoIP(Diagnostics over Internet Protocol, ISO 13400-2)라는 단어를 반드시 마주하게 된다. 기존 레거시 CAN 진단에 익숙한 상태에서 스펙 문서부터 덜컥 열면 머리가 지끈거린다. 처음엔 나 역시 "그냥 물리 선만 CAN에서 이더넷(Ethernet)으로 바뀐 거겠지"라고 가볍게 생각했다가, 막상 패킷 흐름을 뜯어보면서 생각보다 챙겨야 할 네트워크 상태 머신이 많다는 걸 뒤늦게 깨달았다.

CAN 진단은 버스에 물려서 정해진 CAN ID로 프레임을 던지면 끝이지만, DoIP는 IP 네트워크 기반이다. 즉 "누구에게 보낼 것인가"를 넘어 "대상을 어떻게 탐색(Discovery)하고, TCP 세션을 어떻게 맺고 유지할 것인가"라는 네트워크 엔지니어링의 문법이 들어온다. 여기서는 세부 패킷 바이트를 외우기 전에, CAN 진단에서 넘어올 때 먼저 잡아야 할 큰 그림과 통신 흐름을 정리한다.

💡 바쁜 사람을 위한 핵심 요약
DoIP는 새로운 진단 명령어를 정의하는 프로토콜이 아니다. 기존 진단 메시지인 UDS(ISO 14229)를 TCP/IP 이더넷 환경으로 전달하고 라우팅하는 역할을 한다. CAN 진단에서 CAN-TP(ISO 15765-2)가 맡는 전송 기능과 연결해 보면 큰 틀을 이해하기 쉽다.

---

1. 왜 멀쩡한 CAN 놔두고 DoIP를 쓸까? (대역폭의 한계)

고전적인 CAN(또는 CAN-FD) 기반 진단은 지금도 쓰이고 있고, 단순 센서나 액추에이터 제어기 진단에는 부족함이 없다. 하지만 차량이 SDV(Software Defined Vehicle) 구조로 넘어가고 고성능 제어기(HPC)와 도메인 컨트롤러가 들어가면서 진단 환경의 요구사항도 달라졌다.

가장 체감이 큰 건 플래싱(SW 업데이트) 이미지 용량이다. 이미지가 커질수록 기존 CAN 대역폭으로 전송하는 데 더 많은 시간이 걸린다. 기존 방식이 틀렸다기보다, 대용량 데이터를 빠르게 전송하고 여러 ECU를 진단하려는 요구가 커지면서 차량용 이더넷이 선택지로 들어왔다.

---

2. UDS와 DoIP의 관계: 같은 층위가 아니다

입문할 때 가장 많이 꼬이는 포인트가 "UDS 대신 DoIP를 쓴다"고 오해하는 것이다. 둘은 경쟁 관계가 아니라 위아래로 맞물리는 계층 관계다.

[ Application Layer ]   UDS (ISO 14229)  --> $10 Session, $22 Read Data, $19 DTC 등 "진단 내용"
                              ↓
[ Transport / Network ] DoIP (ISO 13400) --> UDS 데이터를 감싸서 IP 패킷으로 포장 및 라우팅
                              ↓
[ TCP / UDP / IP ]      TCP (진단 데이터 전송) / UDP (차량 탐색)
                              ↓
[ Physical / DataLink ] Automotive Ethernet

위 구조에서 보듯 실제로 제어기에게 "리셋해라($11)", "고장 코드 읽어와라($19)"라고 명령하는 진단 서비스 알맹이는 여전히 UDS가 담당한다. DoIP는 그 UDS 바이트 배열 앞에 자신만의 헤더(DoIP Header)를 붙여 IP 네트워크 위에서 목적지 게이트웨이까지 안전하게 배달해 주는 택배 상자 역할을 한다.

그래서 실무에서는 물리 계층과 전송 계층에 따라 UDS on CAN과 UDS on DoIP로 구분해서 부른다. CAN 진단에서 긴 데이터를 쪼개고 합치던 전송 계층(CAN-TP)의 자리에 DoIP + TCP/IP가 들어앉았다고 이해하면 머릿속 정리가 한결 수월해진다.

비교 항목	CAN 기반 진단 (UDS on CAN)	DoIP 기반 진단 (UDS on DoIP)
통신 모델	브로드캐스트 버스(Bus) 중심	IP 네트워크 및 1:1 세션(Session) 중심
사전 작업	물리 연결 후 CAN ID로 프레임 전송	IP 할당 → UDP 차량 탐색 → TCP 연결 및 라우팅 활성화
주요 강점	구조가 단순하고 필요한 리소스가 적음	대용량 SW 플래싱과 높은 데이터 처리량에 적합

---

3. DoIP 통신의 4단계 필수 흐름: 만나서 대화하기까지

CAN은 버스에 그냥 메시지를 던지면 되지만, DoIP는 "상대를 찾고 $\rightarrow$ 문을 두드리고 $\rightarrow$ 대화하고 $\rightarrow$ 생존을 확인하는" 4단계 네트워크 절차를 반드시 거친다. 스펙 문서를 읽기 전에 이 네 가지 키워드만 먼저 눈에 익혀두자.

[외부 진단기 (Tester)]                         [차량 게이트웨이 / DoIP 엔티티]
        |                                                    |
        |--- 1. Vehicle Identification (UDP Broadcast) ----->|  "DoIP 되는 차 누구 있나?"
        |<-- Vehicle Announcement / Response (VIN, 논리주소) -|  "나 여기 있고 내 주소는 이거야"
        |                                                    |
        |====== (TCP 소켓 연결 수립 - Port 13400) ===========|
        |                                                    |
        |--- 2. Routing Activation Request (TCP) ----------->|  "진단 경로 좀 열어줘"
        |<-- Routing Activation Response --------------------|  "인증 완료, 이제 UDS 보내도 됨"
        |                                                    |
        |<== 3. Diagnostic Message (UDS Req / Resp, TCP) ===>|  실제 진단 데이터 통신 ($10, $22...)
        |                                                    |
        |<-- 4. Alive Check Request (TCP) -------------------|  "너 아직 연결 살아있냐?"
        |--- Alive Check Response -------------------------->|  "어, 아직 붙어있어"

① Vehicle Identification (차량 식별 단계)

진단기(Tester)를 차에 꽂았을 때 제일 먼저 하는 일은 "통신할 상대의 IP와 논리 주소(Logical Address)가 뭔지" 알아내는 것이다. 아직 상대 IP를 모르기 때문에 진단기는 UDP 브로드캐스트(포트 13400)로 식별 요청을 뿌리고, 차량(DoIP 게이트웨이)은 자신의 차대번호(VIN)와 논리 주소를 담아 응답한다.

② Routing Activation (라우팅 활성화 단계)

상대방 IP를 알았으니 이제 TCP 연결을 맺는다. 하지만 TCP 소켓이 열렸다고 해서 다짜고짜 UDS 데이터를 던질 수 있는 게 아니다. DoIP 게이트웨이에게 "내가 정당한 진단기(Source Address)이니 내부 네트워크로 진단 트래픽이 흐르도록 길을 열어달라"고 요청하는 Routing Activation 절차를 통과해야 비로소 진단 세션이 성립한다. CAN만 하던 사람들이 처음 패킷 캡처를 볼 때 가장 많이 놓치는 구간이다.

③ Diagnostic Message (실제 진단 메시지 교환)

라우팅까지 열렸다면 이제 익숙한 UDS의 시간이다. 진단기가 Diagnostic Message 타입의 DoIP 패킷 안에 [출발지 주소 + 목적지 제어기 주소 + UDS 데이터]를 담아서 보내면, 차량 게이트웨이가 이를 받아 해당 제어기(또는 하위 CAN 버스)로 토스하고 응답을 돌려준다.

④ Alive Check (연결 생존 확인)

TCP 연결 기반이다 보니 진단기가 중간에 그냥 뽑혔는지, 아니면 잠시 대기 중인지 차량 입장에서 확인해야 소켓 리소스를 관리할 수 있다. 일정 시간 통신이 없거나 새로운 연결 요청이 들어오면 차량 쪽에서 먼저 "아직 살아있나?"라고 Alive Check를 찔러보고, 응답이 없으면 세션을 정리한다.

---

DoIP 학습 로드맵

현재 글에서 큰 흐름을 잡은 뒤, 아래 순서로 읽으면 프로토콜 구조에서 실제 진단과 장애 분석까지 이어서 익힐 수 있다. 각 글은 별도의 질문에 답하며, 이 목록이 학습 순서를 안내한다.

1. 프로토콜과 메시지 구조

• DoIP 헤더 필드와 프로토콜 구조
• TCP stream에서 DoIP 메시지를 framing하는 방법
• DoIP 메시지는 ISO-TP처럼 자르지 않는다
• DoIP Diagnostic Message에 UDS가 실리는 방식

2. 차량 탐색과 진단 경로 연결

• Vehicle Identification의 역할
• Vehicle Discovery가 실패하는 원인
• DoIP Gateway와 ECU 라우팅
• Routing Activation 절차
• Routing Activation 이후 첫 UDS 요청이 실패하는 경우
• Entity Status와 Power Mode로 차량 상태 확인
• Source Address 충돌로 응답이 꼬이는 경우

3. 진단 요청과 응답 해석

• Diagnostic ACK/NACK와 UDS 응답 구분
• DoIP Negative Acknowledge와 UDS 오류 구분
• UDS Negative Response와 NRC 읽기
• Functional Address 진단과 여러 ECU 응답
• UDS Session Control 기초

4. 세션 유지와 보안 접근

• Tester Present의 역할
• Response Pending 중 Tester Present 처리
• Response Pending과 timeout 처리
• Alive Check, TCP Keepalive, Tester Present 구분
• UDS Security Access 개요
• Security Access 이후 NRC 0x24가 발생하는 경우
• ECU Reset 뒤 DoIP 재연결

5. NRC별 문제 분석과 대용량 전송

• NRC 0x13: 메시지 길이 오류
• NRC 0x14: 응답 크기와 ECU 한계
• NRC 0x21: Busy Repeat Request와 재시도
• NRC 0x22: 조건 미충족
• NRC 0x31: 요청 범위와 세션 조건
• NRC 0x35: Invalid Key와 보안 접근 상태
• DoIP Firmware Download에서 발생하는 문제

마무리

DoIP를 이해할 때는 UDS 진단 서비스, DoIP 메시지, TCP 연결, UDP 차량 탐색을 서로 다른 역할로 나눠 보는 것이 중요하다. 위 순서대로 각 계층을 익히면 패킷 구조와 ECU 응답, 재연결 및 전송 문제를 구분해 분석할 수 있다.