Tag: Routing Activation

DoIP에서 Routing Activation까지는 정상처럼 보였는데 몇 분 또는 몇십 분 유휴 후 첫 UDS 요청만 timeout처럼 사라지면, ECU보다 먼저 이미 끊긴 TCP socket을 앱이 계속 살아 있다고 믿는 상태를 확인해야 한다. keepalive, Alive Check, 재연결 조건을 분리해 두는 편이 안전하다.

• DoIP
• UDS
• TCP Socket
• Routing Activation
• +2

DoIP에서 Routing Activation까지는 되는 것 같은데 UDS 응답이 가끔 다른 요청에 붙거나 timeout처럼 사라져 보이면, ECU보다 먼저 Source Address를 누가 같이 쓰고 있는지 확인해야 한다. 같은 SA를 공유하면 응답 매칭과 세션 문맥이 쉽게 꼬인다.

• DoIP
• UDS
• Source Address
• Routing Activation
• +2

DoIP에서 UDS 요청이 길어질 때 CAN의 ISO-TP처럼 프레임을 쪼개어 처리하려 들면 길이 계산, 재전송, 응답 매칭이 쉽게 꼬인다. DoIP는 TCP stream 위에서 Generic Header의 payload length로 메시지 경계를 잡고, UDS 한 요청을 Diagnostic Message 단위로 다루는 편이 안전하다.

• DoIP
• UDS
• ISO-TP
• Diagnostic Message
• +2

DoIP에서 UDS ECU Reset 이후 연결이 살아 있는 것처럼 보이는데 다음 진단이 실패하면, ECU 애플리케이션보다 먼저 소켓 종료, Routing Activation 재수행, Tester Present 재개 순서를 확인해야 한다. reset 전후를 같은 세션으로 취급하면 ACK는 보이는데 실제 UDS가 안 붙는 식으로 쉽게 꼬인다.

• DoIP
• UDS
• ECU Reset
• Routing Activation
• +2

DoIP에서 Routing Activation까지는 성공했는데 첫 UDS 요청만 간헐적으로 실패하면, ECU 로직보다 먼저 SA/TA와 재연결 이후 상태를 의심해야 한다. ACK/NACK, 무응답, 다른 ECU로 간 것처럼 보이는 증상을 같은 그림으로 정리한다.

• DoIP
• UDS
• Routing Activation
• Source Address
• +2

TCP는 붙고 Vehicle Identification도 되는데 Routing Activation/UDS가 안 될 때가 있다. 이때 패킷 필드를 무작정 붙잡기 전에, DoIP의 Entity Status/Power Mode 같은 상태성 정보를 써서 '지금 진단 가능한 상태인지'를 먼저 확인하는 디버깅 흐름을 정리한다.

• DoIP
• Entity Status
• Power Mode
• Vehicle Identification
• +2

DoIP는 TCP라서 붙기만 하면 끝인 줄 아는데, 실무에서는 가만히 두면 어느 순간 세션이 끊기는 경우가 많다. Alive Check, TCP Keepalive, UDS Tester Present는 목적이 다르다. 끊김을 줄이려면 이 셋을 분리해서 설계해야 한다.

• DoIP
• Alive Check
• TCP Keepalive
• Routing Activation
• +2

DoIP에서 TCP 연결 이후 Routing Activation이 왜 필요하고, 여기서 진단 요청이 막히는 이유가 무엇인지 정리합니다.

• DoIP
• Routing Activation
• UDS
• Automotive
• +3