DoIP Gateway 구조를 이해해야 ECU가 보인다

처음 DoIP를 접하면 보통 이렇게 생각합니다.

Tester <-> ECU

하지만 실제 차량에서는 구조가 더 복잡합니다.

대부분은 이런 형태에 가깝습니다.

Tester <-> DoIP Gateway <-> Multiple ECUs

즉, 테스터가 직접 ECU와 붙는 게 아니라,
중간 Gateway를 통해 routing 되는 경우가 많습니다.

이 구조를 이해하지 못하면:

• logical address 혼란
• routing activation 오해
• 응답 ECU 착각
• timeout 분석 실패

같은 문제가 반복됩니다.

시리즈 목차

• DoIP Alive Check, 연결은 살아 있는데 왜 끊겼을까
• DoIP Negative Acknowledge, UDS 에러랑은 다르다
• DoIP Firmware Download에서 갑자기 문제가 터지는 이유
• DoIP Gateway 구조를 이해해야 ECU가 보인다

Gateway는 사실 라우터에 가깝다

이름 때문에 헷갈리는데,
DoIP Gateway는 단순 relay보다 router에 가깝습니다.

예를 들면:

Tester
  |
Ethernet
  |
DoIP Gateway
  ├── CAN ECU #1
  ├── CAN ECU #2
  ├── LIN ECU
  └── Ethernet ECU

Gateway는 내부적으로:

• logical address 확인
• target ECU 결정
• 내부 bus forwarding
• 응답 reverse routing

을 처리합니다.

즉, 진짜 진단 대상 ECU와 TCP 연결 endpoint가 다를 수 있습니다.

그래서 TCP endpoint만 보면 안 된다

이 부분이 꽤 중요합니다.

예를 들어:

TCP Connected IP = 192.168.0.10

이라고 해서 ECU가 직접 그 IP를 가진 건 아닙니다.

실제로는:

192.168.0.10 = Gateway
0x1201        = Actual ECU

일 수 있습니다.

즉:

• IP는 gateway
• logical address는 target ECU

입니다.

패킷 흐름은 이렇게 간다

예를 들어 ECU Reset 요청:

Tester
  |
  | Diagnostic Message
  | TA = 0x1201
  v
Gateway
  |
  | Internal Routing
  v
Target ECU

응답은 반대로 올라옵니다.

Target ECU
  |
  v
Gateway
  |
  | Diagnostic Response
  | SA = 0x1201
  v
Tester

여기서 중요한 건:

logical address 기반 routing

입니다.

Routing Activation도 Gateway 기준이다

이 부분도 자주 헷갈립니다.

Routing Activation 성공은:

Tester <-> Gateway

세션이 열린 겁니다.

즉:

RA success != 모든 ECU 접근 가능

입니다.

실제로는 gateway 정책에 따라:

• 특정 ECU만 허용
• 특정 diagnostic session 제한
• concurrent access 제한

같은 조건이 붙을 수 있습니다.

현장에서 자주 보는 오해

1) ECU 응답이 없다고 ECU 문제로 판단

실제로는 gateway routing 문제일 수도 있습니다.

예시:

wrong target address

그러면 gateway 내부에서 drop될 수 있습니다.

Tester 입장에서는 그냥 timeout처럼 보입니다.

2) ECU source address를 안 봄

응답 payload만 보는 경우가 많습니다.

하지만 gateway 환경에서는:

SA = 실제 응답 ECU

입니다.

즉:

RX payload 정상
BUT
unexpected source address

상황도 충분히 가능합니다.

특히 multi-ECU 환경에서는 source address 로그가 중요합니다.

3) Gateway overload 상황

Firmware flashing 중 자주 나옵니다.

예를 들어:

multiple tester
+ large transfer
+ internal CAN forwarding

상황이면 gateway queue가 밀릴 수 있습니다.

이 경우:

• response delay 증가
• timeout 증가
• retransmission 증가

로 이어집니다.

내부 bus 속도 차이도 영향이 있다

이더넷은 빠릅니다.

하지만 내부 ECU 연결은:

• CAN
• CAN FD
• LIN

일 수도 있습니다.

즉:

Ethernet ingress
→ Gateway processing
→ Slow internal bus

구조가 됩니다.

그래서 tester 입장에서는:

왜 Ethernet인데 이렇게 느리지?

상황이 나옵니다.

실제로 병목은 gateway 뒤쪽일 수 있습니다.

로그는 gateway 관점도 보여야 한다

추천 로그 예시:

[doip] rx ta=0x1201
[gateway] route target=CAN1
[gateway] forward success
[gateway] response from=0x1201

최소한:

• ingress
• routing decision
• forwarding result
• response source

정도는 보이는 게 좋습니다.

ECU 하나처럼 구현하면 나중에 힘들다

초기 테스트는 보통 단일 ECU라서 단순합니다.

Tester <-> ECU

하지만 실제 양산 구조는 거의 gateway 기반입니다.

그래서 코드 구조도 처음부터:

transport
→ routing
→ target ECU abstraction

형태로 나누는 게 유지보수에 좋습니다.

Wireshark만으로 부족한 경우

Gateway 내부 routing은 packet capture에 안 보이는 경우가 많습니다.

예를 들어:

Tester packet 정상
Gateway packet 정상

인데 내부 CAN forwarding 실패일 수 있습니다.

그래서 gateway internal log가 중요합니다.

특히:

• route lookup fail
• internal bus timeout
• ECU offline
• queue full

같은 이벤트는 외부 trace만으로 안 보입니다.

오늘 포인트

DoIP 환경에서는 TCP 연결 대상과 실제 ECU가 다를 수 있습니다.

실제로 중요한 건:

• logical address
• gateway routing
• internal forwarding
• response source tracking

입니다.

Gateway 구조를 이해하기 시작하면 DoIP 로그가 훨씬 읽히기 시작합니다.

다음 글에서는 DoIP에서 Vehicle Announcement와 Discovery timing이 실제 네트워크에서 어떻게 움직이는지 이어서 다뤄보겠습니다.

추천 대상

• Gateway 기반 DoIP 구조를 처음 다루는 개발자
• multi-ECU routing 문제를 디버깅 중인 엔지니어
• logical address 개념이 헷갈리는 사람

한 줄 요약

DoIP에서는 TCP 연결 endpoint보다 logical address 기반 gateway routing 구조를 이해하는 게 더 중요하다.

추천 키워드

doip, gateway routing, logical address, automotive ethernet, uds over ip, ecu routing

DevBJ | No Bio, Just Log #오늘을살자