DoIP 개론, CAN 진단 보다가 처음 보면 헷갈리는 포인트 정리

차량 진단 쪽 조금 보다 보면
어느 순간 DoIP라는 단어가 꼭 튀어나오죠.

처음엔 이름부터 좀 딱딱합니다.
뭔가 엄청 어려운 새 프로토콜 같고,
CAN 진단만 익숙하면 “이걸 또 알아야 하나?” 싶은 느낌이 팍팍 옵니다.

저도 처음엔 그냥
“아 이거 Ethernet으로 진단하는 거겠지”
이 정도로만 봤습니다.

근데 정말로 말이야,
조금 뜯어보면 이건 단순히 선만 바뀐 얘기가 아닙니다.
진단 메시지를 IP 네트워크 위에서 다루는 방식 자체가 들어가 있죠.

이번 글은 1편 느낌으로 가볍게 갑니다.
DoIP가 왜 나왔는지,
CAN 기반 진단이랑 뭐가 다른지,
전체 구조를 어떻게 보면 덜 헷갈리는지
이 정도까지만 정리해볼까 합니다.

한 문장부터 가보면, DoIP는 이거다

쉽게 말하면 DoIP는
차량 진단 메시지를 IP 네트워크 위에서 주고받기 위한 방식입니다.

조금 더 실무 느낌으로 말하면,
기존에 CAN 위에서 오가던 진단 메시지를
Ethernet/IP 환경에서도 다룰 수 있게 만든 구조라고 보면 됩니다.

주의할 점은!!!!
DoIP가 진단 내용을 새로 만드는 게 아니라,
진단 메시지를 IP 위로 실어 나르는 방식이라는 겁니다.

이 감각이 먼저 잡혀야 뒤가 덜 꼬입니다.

왜 굳이 DoIP가 필요했을까

이 질문이 제일 중요하죠.

CAN 기반 진단은 지금도 여전히 중요합니다.
그리고 실제로 너무 잘 쓰이고요.

근데 차량이 점점 복잡해지면서
진단 쪽에서도 이런 요구가 커졌습니다.

ECU 수가 많아짐
데이터 양이 많아짐
플래싱 이미지가 커짐
빠른 진단/업데이트 요구가 생김
공장/서비스 환경에서 처리 속도가 중요해짐

특히 소프트웨어 업데이트나 대용량 데이터 처리 쪽은
CAN으로만 밀어붙이면 답답한 구간이 분명히 생깁니다.

한마디로
기존 방식이 틀렸다기보다, 더 큰 대역폭이 필요한 구간이 생긴 것입니다.

DoIP를 그냥 “이더넷 진단”이라고만 보면 좀 아쉽다

이렇게 이해해도 아주 틀린 건 아닙니다.
근데 살짝 부족하죠.

왜냐면 진짜 중요한 건
“Ethernet 쓴다”보다
누구랑 연결할 거냐,
어떻게 진단 세션을 열 거냐,
어떤 메시지를 전달할 거냐
이쪽이기 때문입니다.

CAN 쪽은 버스에 붙는 느낌이 강합니다.
반면 DoIP는 IP 기반이라 이런 생각이 같이 따라옵니다.

상대가 누구냐
어떤 주소를 쓰냐
어떻게 찾냐
연결이 살아 있냐
진단 통신을 어떤 흐름으로 열 거냐

즉 DoIP는
그냥 배선 바뀐 버전이 아니라,
네트워크 개념이 들어간 진단 방식이라고 보는 게 더 맞습니다.

이거 차이 큽니다.

UDS랑 DoIP는 어떤 관계냐

이 부분에서 많이 헷갈리죠.

처음 보면 UDS랑 DoIP가 같은 급의 프로토콜처럼 보입니다.
근데 구조상은 이렇게 보는 게 편합니다.

UDS
  ↓
DoIP
  ↓
TCP/IP
  ↓
Ethernet

즉 실제 진단 서비스 내용은 보통 UDS 쪽에서 다루고,
DoIP는 그걸 IP 기반으로 전달하는 구조에 가깝습니다.

예를 들어 이런 것들은 여전히 진단 서비스 쪽 이야기죠.

Diagnostic Session Control
ECU Reset
Read DTC
Read Data By Identifier

DoIP는 그 메시지가
어떻게 IP 환경에서 이동하느냐를 담당하는 느낌입니다.

그래서 실무에서는
UDS on CAN
UDS on DoIP
이렇게 나눠서 보는 감각이 중요합니다.

CAN 진단이랑 비교하면 뭐가 다르냐

아주 단순하게 보면 이런 느낌입니다.

CAN 기반 진단

버스 중심
익숙함
구조가 비교적 단순하게 느껴짐
속도/대역폭 한계가 보임

DoIP 기반 진단

네트워크 중심
연결 관리 개념이 큼
대용량 처리에 유리
빠른 진단/플래싱 환경에 잘 맞음

즉 CAN은 버스 진단 느낌이고,
DoIP는 네트워크 진단 느낌입니다.

둘 다 진단이긴 한데
머릿속에서 그리는 구조가 꽤 다릅니다.

DoIP에서 자주 보게 되는 흐름은 이 정도다

1편에서는 세부 필드까지 안 가고,
큰 그림만 잡으면 충분합니다.

보통 DoIP 얘기할 때 자주 나오는 흐름은 이 정도죠.

1) Vehicle Identification

진단기가 차량이나 노드를 찾는 단계입니다.

쉽게 말하면
“DoIP 가능한 대상 누구 있냐”
이런 느낌의 식별 흐름입니다.

2) Routing Activation

이건 진단 통신 전에
경로를 열어주는 느낌으로 보면 됩니다.

이름은 좀 거창한데,
진단 트래픽을 흘리기 전에 필요한 절차라고 생각하면 편하죠.

3) Diagnostic Message

이제 실제 진단 메시지가 오가는 구간입니다.

즉 UDS request / response 같은 내용이
DoIP payload 안에 실려서 이동하는 흐름입니다.

4) Alive Check

연결이 살아 있는지 확인하는 흐름입니다.

IP 기반 연결이다 보니
세션이 유지되는지,
상대가 여전히 응답 가능한지 보는 과정이 따라옵니다.

큰 그림을 텍스트로 그리면 이런 느낌이다

RFC 문서처럼 아주 단순하게 그리면 대충 이렇습니다.

[Tester]
   |
   |-- Vehicle Identification
   |
   |-- Routing Activation
   |
   |-- Diagnostic Message (UDS request/response)
   |
   |-- Alive Check
   |
[Vehicle / ECU]

이 그림이 머릿속에 들어오면
DoIP를 처음 볼 때 훨씬 덜 낯섭니다.

처음 볼 때 자주 꼬이는 포인트

제가 처음 볼 때도 좀 헤맸던 부분인데,
초반에 이건 정리하고 가면 좋습니다.

DoIP와 UDS를 같은 층위로 보면 헷갈림
Ethernet 쓴다고 다 DoIP는 아님
CAN 진단 감각 그대로 보면 IP 기반 연결 개념에서 막힘
Routing Activation 흐름을 빼먹으면 전체가 애매함
DoIP는 “진단 내용”보다 “전달 구조”라는 걸 먼저 잡아야 함

며칠 밤을 새웠던 기억까진 아니지만 ^^;;
처음엔 저도 “이더넷으로 UDS 보내는 거네?” 정도로만 봤다가
구조가 생각보다 더 있다는 걸 뒤늦게 정리했습니다.

여기까지 이해하면 1편으로는 충분하다

처음부터 패킷 필드 길이 외우고,
payload type 외우고,
메시지 코드 다 보려고 하면 금방 피곤해집니다.

1편에서는 이 정도만 잡아도 충분합니다.

DoIP는 차량 진단을 IP 기반에서 수행하기 위한 구조다
CAN 진단의 확장/보완 관점으로 보면 이해가 쉽다
UDS와 DoIP는 역할이 다르다
Vehicle Identification, Routing Activation, Diagnostic Message, Alive Check 흐름이 있다

이 정도만 머릿속에 들어오면
다음에 패킷 구조를 봐도 훨씬 잘 들어옵니다.

다음 글에서는 뭘 볼 거냐

다음 글에서는 진짜 프로토콜 구조 쪽으로 가보려 합니다.

예를 들면 이런 것들이죠.

DoIP Generic Header
Protocol Version
Inverse Protocol Version
Payload Type
Payload Length
메시지 타입별 payload 구조

그때는 말로 길게 푸는 것보다
RFC 스타일 텍스트 블럭으로 보는 게 훨씬 낫습니다.

한 줄 요약

DoIP는 차량 진단 메시지를 IP 네트워크에서 식별하고 연결하고 전달하기 위한 구조라고 보면 가장 이해가 잘 된다.