[DoIP 마스터 가이드 3편] 본격적인 진단 시작! UDS 페이로드와 세션 유지의 비밀 (SA/TA & Tester Present)

tags: DoIP, UDS, Diagnostic Message, Source Address, Target Address, Session Control, Tester Present, DevBJ

안녕하세요, DevBJ입니다! 😎

[👉 1편]에서 뼈대를 잡고, [👉 2편]에서 차량을 찾고 라우팅(Routing Activation) 길까지 시원하게 뚫었습니다. 이제 인프라 공사는 끝났으니, 우리가 그토록 원하던 '진짜 진단 통신(UDS)'을 이 고속도로 위에 올려볼 차례입니다.

과거 CAN 통신 하실 때 썼던 UDS (0x22 ReadDataByIdentifier, 0x10 DiagnosticSessionControl 등) 기억나시죠? DoIP라고 해서 이 UDS 명령어 자체가 바뀌는 건 1도 없습니다. 단지 '전달하는 포장 방식'과 '누가 누구에게 보내는지(주소 체계)'가 명확해졌을 뿐입니다.

📌 [DoIP 마스터 가이드 시리즈 목차]

• ▶ [DoIP 마스터 가이드 1편] 왜 CAN 대신 이더넷일까? (탄생 배경과 패킷 구조, TCP 프레이밍의 함정)
• 👉 [DoIP 마스터 가이드 2편] 차량은 어떻게 찾고, 진단 길은 어떻게 뚫을까? (Vehicle Discovery & Routing Activation)
• 👉 [DoIP 마스터 가이드 3편] 본격적인 진단 시작! UDS 페이로드와 세션 유지의 비밀 (SA/TA & Tester Present)
• 👉 [DoIP 마스터 가이드 4편] 혈압 오르는 NRC 완벽 분석! 실전 트러블슈팅 가이드 (0x13, 0x22, 0x31, 0x78 등)
• 👉 [DoIP 마스터 가이드 5편] 실무 끝판왕! 펌웨어 전송과 다중 ECU 게이트웨이 라우팅 완벽 해부 (完)

 

오늘은 DoIP 통신의 본체인 Diagnostic Message 구조를 해부해 보고, 열심히 뚫어놓은 연결이 툭툭 끊기는 걸 막기 위한 세션 유지(Session Control & Tester Present)의 꿀팁을 전수해 드리겠습니다.

---

1. UDS를 싣고 달리는 트럭: Diagnostic Message

DoIP에서 UDS 메시지를 주고받을 때는 Diagnostic Message라는 Payload Type을 사용합니다.
구조는 정말 심플합니다. 아까 말한 8바이트 헤더 뒤에 딱 3가지만 예쁘게 순서대로 담아주면 됩니다.

[ DoIP Generic Header ]
+------------------------+
| Source Address (SA)    | 2 bytes  (보내는 놈)
+------------------------+
| Target Address (TA)    | 2 bytes  (받는 놈)
+------------------------+
| UDS Payload            | N bytes  (진짜 내용물)
+------------------------+

🎯 SA (Source Address)와 TA (Target Address)가 생명이다!

CAN에서는 메시지 ID(0x7E0, 0x7E8 등)로 너와 나를 식별했다면, DoIP에서는 이 SA와 TA가 그 역할을 완벽히 대체합니다.

• SA (Source Address): 진단기의 주소입니다. [👉 2편]의 Routing Activation 단계에서 "나 이 주소 쓸게!"라고 허락받았던 바로 그 주소를 적어 넣어야 합니다. 다른 걸 쓰면 게이트웨이가 "너 누구야?" 하고 가차 없이 쳐냅니다.
• TA (Target Address): 최종 목적지 ECU의 주소입니다. 현대 자동차 네트워크는 여러 ECU가 게이트웨이 뒤에 주렁주렁 매달린 구조입니다. TA를 정확히 지정해야 게이트웨이가 *"아, 이건 엔진 ECU로 토스! 이건 바디 ECU로 토스!"* 하고 라우팅을 해줍니다.

만약 UDS 요청을 보냈는데 타임아웃이 난다면? UDS 데이터가 틀렸을 확률보다 이 TA(Target Address)를 잘못 적어서 패킷이 허공을 맴돌고 있을 확률이 훨씬 높습니다.

⚠️ 주의 (ISO-TP와 혼동 금지!)
CAN 통신할 때 UDS가 길어지면 First Frame, Consecutive Frame으로 쪼개서(ISO-TP) 보냈던 거 기억하시나요? DoIP에서는 절대 그렇게 쪼개시면 안 됩니다! TCP가 알아서 스트림으로 분할 전송해 주기 때문에, 애플리케이션 단에서는 길이가 10바이트든 10,000바이트든 그냥 통째로 묶어서 하나의 Diagnostic Message로 쏴줘야 합니다.

---

2. 왜 연결됐는데 거절당할까? (Session Control의 이해)

자, 주소(SA/TA)도 잘 맞춰서 UDS 요청(0x22, 0x27 등)을 보냈는데, ECU가 자꾸 에러(NRC 0x22 등)를 뱉거나 튕겨내는 경우가 있습니다. 이때는 통신 문제가 아니라 '진단 세션(Diagnostic Session)'을 의심해 봐야 합니다.

ECU 입장에서는 위험한 기능(펌웨어 플래싱, 데이터 수정, 캘리브레이션 변경 등)을 아무나 막 건드리면 안 되겠죠? 그래서 기본적으로 방어막을 치고 있습니다.

• Default Session (0x01): 평상시 모드. 기본적인 정보 조회만 가능합니다.
• Extended Session (0x03) 등: "나 지금부터 딥하게 건드릴 거야!" 선언. 보안 해제(Security Access)나 복잡한 기능을 쓸 수 있는 모드입니다.

즉, "TCP 연결 ➡️ Routing Activation 성공 = 통신 인프라 열림" 일 뿐, ECU의 기능을 맘껏 쓰려면 UDS의 0x10 서비스를 이용해 진단 세션부터 Extended나 Programming 모드로 올려줘야(전환해 줘야) 합니다. 이걸 빼먹고 무작정 Security Access(0x27)부터 들이밀면 매몰차게 차이는 거죠.

---

3. 심박수를 유지하라: Tester Present (0x3E)

세션을 Extended로 기껏 올려놨는데, 잠시 화장실 다녀온 사이에 ECU가 다시 Default 세션으로 뚝 떨어져서 처음부터 다시 인증해야 하는 짜증 나는 상황... 다들 한 번쯤 겪어보셨죠? 😡

ECU는 테스터로부터 일정 시간(S3 Timeout) 동안 아무런 UDS 요청이 오지 않으면 *"아, 테스터 집에 갔나 보네. 나도 그냥 기본 모드로 돌아갈래."* 하고 세션을 초기화해버립니다.

이걸 막기 위해 주기적으로 "나 안 갔어! 계속 작업 중이야!"라고 ECU의 옆구리를 찔러주는 메시지가 바로 Tester Present (0x3E 00) 입니다.

💡 실무 꿀팁: TCP Keepalive와 UDS 세션은 다르다!

현업에서 진짜 많이 착각하시는 부분입니다.
*"네트워크(TCP) 끊기지 말라고 TCP Keepalive도 켜고 DoIP Alive Check도 날렸는데 왜 UDS 세션이 죽죠?"*

• TCP Keepalive / DoIP Alive Check: "나 네트워크 랜선 안 뽑았어!" (물리/네트워크 계층 유지)
• UDS Tester Present: "나 진단 작업 아직 안 끝났어!" (애플리케이션 계층 유지)

네트워크가 살아있어도 진단 로직(UDS) 단에서 조용하면 ECU는 세션을 닫아버립니다. 펌웨어 다운로드(Flash) 전처리처럼 시간이 오래 걸리는 작업을 할 때는, 백그라운드 스레드에서 주기적으로 (보통 1~2초 간격) Tester Present를 날려주도록 꼭 설계하셔야 합니다.

(단, 진짜 UDS 응답을 기다리고 있는(Response Pending) 와중에 눈치 없이 Tester Present를 같이 막 쏘면 상태 머신이 꼬일 수 있으니 세심한 분리 설계가 필요합니다. 이 부분은 4편에서 자세히 다룰게요!)

---

📝 3편 마무리: 통신은 성공, 그러나 에러와의 전쟁 시작

수고하셨습니다! 이제 DoIP의 핵심인 Diagnostic Message(SA/TA)를 이해하고, 세션을 열어 유지하는 법까지 마스터하셨습니다. 이제 여러분은 차량의 모든 ECU와 대화할 준비를 마쳤습니다.

하지만 기쁨도 잠시... 실전에서는 내가 보낸 예쁜 UDS 메시지에 대해 ECU가 "싫은데? 거절할 건데?" (Negative Response, NRC)라고 대답하는 경우가 수두룩합니다.

다음 4편에서는 실무자들의 혈압을 올리는 주범! 각종 NRC(0x13, 0x14, 0x21, 0x22, 0x31, 0x78 등)의 발생 원인과, 이를 완벽하게 분석하고 타파하는 실전 트러블슈팅 가이드를 준비했습니다.

👉 [다음 글 보기: DoIP 마스터 가이드 4편 - 실전 트러블슈팅! 예외 처리와 NRC 분석]

글이 길지만 그만큼 실무에서 헤맬 시간을 확 줄여드릴 거라 확신합니다! 질문은 언제나 환영입니다. DevBJ였습니다!