Skip to content
Go DevBJ
Go back

DoIP에서 응답이 이상할 때, Negative Response부터 봐야 한다

Edit page

DoIP 디버깅하다 보면 이런 순간이 온다.

근데 결과가 실패다.

이럴 때 대부분은
UDS Negative Response를 보고 있는 상황이다.

처음에는 “통신은 되는데 왜 실패하지?” 싶다.
근데 사실 이건 오히려 좋은 상황이다.
적어도 ECU까지는 정상적으로 도달했다는 뜻이니까.

오늘은 짧게,
Negative Response를 어떻게 봐야 하는지 감 잡아보자.

Negative Response 한 줄 정리

Negative Response는
ECU가 요청은 받았지만, 현재 처리할 수 없거나 거절한다는 응답이다.

즉:

이 차이를 먼저 구분해야 한다.

구조는 생각보다 단순하다

UDS Negative Response는 기본적으로 이런 형태다.

7F [Request SID] [NRC]

예를 들면:

7F 22 31

이걸 해석하면:

이렇게 된다.

여기서 중요한 건 NRC다

실무에서는 거의 이것만 본다.

이 값이 실패 이유다.

와 이거, 여기부터 진짜 디버깅 느낌 난다.

자주 보는 NRC 몇 개만 보자

오늘은 많이 보는 것만 가볍게 보자.

0x11 — Service Not Supported

7F 22 11

서비스 자체를 지원 안 한다는 뜻이다.

보통 이런 경우다.

0x13 — Incorrect Message Length

이건 요청 길이가 이상하다는 뜻이다.

진짜 자주 나온다.

예:

이럴 때는 요청 데이터 길이부터 다시 본다.

0x22 — Conditions Not Correct

이건 ECU 상태 문제다.

예를 들면:

즉:

“명령은 이해했는데 지금은 안 된다”

이 느낌이다.

0x31 — Request Out Of Range

이것도 많이 본다.

보통:

이 경우는 대상 데이터 정의를 다시 봐야 한다.

0x78 — Response Pending

이건 실패가 아니다.

중요하다.

ECU가:

“처리 중이니까 잠깐 기다려라”

이 뜻이다.

근데 이거 모르고 timeout 처리해버리면
멀쩡한 ECU를 실패 처리하게 된다.

DoIP 문제인지 UDS 문제인지 구분하는 법

이건 진짜 중요하다.

DoIP 문제

UDS 문제

즉, Negative Response가 왔다는 건
오히려 DoIP는 정상인 경우가 많다.

이 경계를 빨리 구분해야 한다.

실무에서는 이렇게 본다

개인적으로는 거의 이 순서다.

1. 응답 자체가 왔나
2. Positive / Negative 구분
3. NRC 확인
4. 현재 세션 상태 확인
5. 요청 포맷 다시 확인

이렇게 보면 생각보다 금방 좁혀진다.

괜히 패킷 전체를 다 의심하면
시간만 오래 걸린다.

패킷 느낌으로 보면 이렇다

예를 들어:

Tester → ECU
22 F1 90

VIN 요청이다.

근데 ECU 응답이:

7F 22 31

이면:

이렇게 해석하는 거다.

다음 단계에서는 timeout도 봐야 한다

Negative Response까지 보면 이제 흐름이 꽤 잡힌다.

다음 글에서는 이런 걸 보면 좋다.

여기부터는 진짜 진단 툴 구현 느낌이 강해진다.

추천 대상

한 줄 요약

Negative Response는 ECU가 요청을 이해했지만 현재 처리할 수 없다는 의미이며, 대부분 UDS 레벨 문제를 분석해야 하는 상황이다.

추천 키워드

UDS Negative Response, NRC, DoIP debug, Automotive Ethernet, UDS over IP


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


Edit page
Share this post on:

Previous Post
DoIP timeout 처리, Response Pending 제대로 이해해야 덜 헤맨다
Next Post
DoIP Diagnostic Message, UDS가 실제로 어떻게 실리는지 보자