DoIP는 붙었는데 진단이 안 된다: Entity Status/Power Mode로 상태부터 확인하기

DoIP 붙일 때 이런 케이스가 생각보다 많다.

• Vehicle Identification은 된다
• TCP 연결도 된다
• 그런데 Routing Activation이 안 되거나, UDS가 묵묵부답이다

이때 보통 처음 반응은 이거다.

“Routing Activation 패킷이 틀렸나?”

물론 그럴 수도 있다.

그런데 실무에서는 패킷이 맞아도 안 되는 케이스가 있다.
원인이 프로토콜 필드가 아니라, 상대가 진단 가능한 상태가 아니어서인 경우다.

그래서 나는 이런 순서로 본다.

패킷부터 뜯기 전에
상대 상태부터 확인

DoIP 학습 로드맵

차량 탐색과 진단 경로 연결을 순서대로 보려면 DoIP 학습 로드맵을 확인하세요.

왜 “상태 확인”이 필요한가

DoIP에서 “TCP 연결 성공”은 이걸 의미한다.

네트워크 레벨로는 붙었다

하지만 이게 곧바로 이걸 의미하진 않는다.

진단을 받아줄 준비가 됐다

예를 들어 이런 상황이 있다.

• Gateway는 올라왔는데, 일부 ECU는 아직 부팅 중이다
• ECU는 살아있는데, 특정 전원/통신 모드에서만 진단을 허용한다
• “진단 채널”은 열리지만, 특정 서비스는 조용히 무시한다

이런 상태에서 Routing Activation/UDS만 계속 때리면 로그는 보통 이렇게 된다.

RA timeout
UDS timeout
RA retry...

그리고 디버깅은 “필드/파서”로만 쏠린다.

Entity Status / Power Mode를 실무적으로 쓰는 방식

표준을 완벽히 외우지 않아도 된다.
핵심은 이 두 질문이다.

• “내가 지금 붙은 대상이 살아있냐”
• “지금 진단을 받을 모드냐”

이걸 짧은 요청/응답으로 먼저 확인하는 게 목적이다.

그래서 내 state machine은 보통 이렇게 구성한다.

1) Vehicle Identification (선택)
2) TCP connect
3) (옵션) Entity Status / Power Mode
4) Routing Activation
5) UDS

여기서 3번을 넣으면 얻는 게 많다.

• “상대가 아예 응답 가능한 상태인지” 빠르게 거를 수 있음
• “내 요청이 틀린 문제”와 “상대 준비 상태 문제”를 분리 가능

이런 증상이면 상태 확인을 먼저 넣자

1) 부팅 직후만 간헐적으로 실패한다

전형적인 패턴이다.

• ECU 재부팅 직후에는 Routing Activation 실패
• 몇 초~수십 초 지나면 갑자기 잘 됨

이 경우는 필드가 틀린 게 아니라,
상대가 아직 준비가 안 된 상태일 가능성이 크다.

booting → (대기) → ready → routing activation

상태 확인을 넣으면 “기다려야 하는 상황”을 재시도 로그로 덮지 않게 된다.

2) 특정 전원/상태에서만 실패한다

이것도 종종 나온다.

• 동일한 툴인데 어떤 차량에서는 되고, 어떤 차량에서는 안 됨
• 동일한 ECU인데 전원 조건에 따라 안 됨

이때는 “Routing Activation 패킷이 잘못됐다”만으로는 끝까지 못 잡는다.
상대가 특정 모드에서만 진단을 열어주는 설계인 경우가 있다.

3) TCP는 붙는데 UDS가 0개다

캡처를 보면:

• TCP handshake 정상
• DoIP 메시지는 오간다
• 그런데 UDS 응답은 한 번도 안 온다

이런 경우 “내 UDS가 틀렸다”보다,
그 전에 진단이 가능한 상태가 아닌지를 먼저 확인해보는 게 빠르다.

디버깅 체크리스트 (현장용)

상태 확인을 넣기로 했으면,
아래 순서로 보면 실수할 확률이 줄어든다.

1. Vehicle Identification 응답이 항상 오는지(네트워크/브로드캐스트/필터)
2. TCP 연결이 항상 되는지(포트/방화벽/세션 한도)
3. Entity Status / Power Mode 응답이 오는지(상대 준비 상태)
4. Routing Activation 응답이 오는지(승인 단계)
5. UDS 요청이 ECU까지 들어가는지(진단 로직)

여기서 포인트는 이거다.

3번이 안 되면
4~5번은 의미가 없다

구현 팁: 상태 확인은 “로그 분리”가 반이다

상태 확인 메시지를 넣으면,
로그가 섞이기 시작한다.

그래서 나는 최소한 이 정도로 prefix를 나눈다.

[doip][discover] vehicle identification ...
[doip][status] entity status / power mode ...
[doip][ra] routing activation ...
[uds] request/response ...

이렇게만 나눠도 “어디에서 막혔는지”가 빨라진다.

결론: 상태를 보면, 패킷을 덜 뜯는다

Routing Activation/UDS가 안 된다고 해서,
항상 패킷이 틀린 건 아니다.

DoIP는 “네트워크 + 상태 + 승인 단계”가 다 얽혀 있다.
그래서 상태 확인을 한 번 끼워 넣으면,
원인이 프로토콜인지/상대 준비 상태인지 분리가 빨라진다.

다음 글에서는 Routing Activation이 성공했는데도 특정 ECU만 응답이 이상하게 오는 케이스(게이트웨이 라우팅/응답 출처 추적)를 이어서 다뤄보겠습니다.

추천 대상

• DoIP 연결은 되는데 Routing Activation이 들쑥날쑥한 사람
• 부팅 직후 간헐 실패를 retry로만 때우고 있는 사람
• 테스트 자동화에서 “대상 준비 상태”를 조건으로 넣고 싶은 사람

한 줄 요약

DoIP에서 진단이 안 될 때는 패킷부터 뜯기 전에, Entity Status/Power Mode 같은 상태성 정보로 “지금 진단 가능한 상태인지”부터 확인하는 게 빠르다.

추천 키워드

DoIP, entity status, power mode, vehicle identification, routing activation, gateway

---