지난 수년간 Ethernet은 진단, 더 구체적으로 말하자면 ECU의 플래싱을 위해 사용되어 왔습니다. 생산 및 수리 시 플래싱 사이클을 현저하게 감소시킬 수 있기 때문에 자동차 제조 및 공급업체에 이러한 응용 분야는 이미 충분히 매력적입니다.
이제 언제든지 Diagnostics over IP(DoIP)를 사용할 수 있고, 이는 ISO 13400에 기술되어 있습니다. IP 패킷 전송을 지원하는 한 어떠한 물리 계층을 사용할 것인지는 상관없습니다. 예를 들어, Ethernet 이외에, 물리매체로써 WLAN 및 UMTS를 사용하는 경우 역시 DoIP를 사용할 수 있습니다.
여기에서 중요한 점은 DoIP가 ISO 13400에 따른 진단 프로토콜을 대표하는 것이 아니라 확장된 전송 프로토콜을 대표한다는 점입니다. 이는 진단 패킷의 전송은 DoIP에 의해 정의되지만 포함된 진단 서비스는 계속해서 KWP2000 및 UDS와 같은 진단 프로토콜에 의해 명시되고 기술된다는 사실을 의미합니다.
DoIP를 위한 요구 사항은 UDP 및 TCP의 지원입니다. UDP는 상태 및 환경설정 정보의 전송에 사용됩니다. 다른 한편으로 TCP 연결은 고정된 통신 채널을 통해 실제 진단 패킷의 전송을 가능하게 만들어 줍니다. 이는 데이터 전송에 대한 높은 신뢰성을 보장하고 큰 데이터 패킷을 자동으로 분할할 수 있게 해줍니다. TCP와 UDP는 진단 테스터뿐 아니라 DoIP 진단이 가능한 각 ECU(DoIP 노드) 및 진단 게이트웨이(DoIP 게이트웨이 또는 DoIP 엣지 노드)에 구현되어야 합니다.
전통적인 버스 시스템을 사용한 진단에서와 마찬가지로 진단 테스터는 진단 요청의 전송이 가능합니다. 테스터는 수리 공장에서 볼 수 있는 외부 장비나 차량 내 온보드 테스터의 형태로 존재할 수 있습니다. 수신용 ECU는 순차적으로 진단 요청을 처리하고 관련 진단 작업에 대한 응답을 테스터로 회신합니다. 그러나, 이를 위해서는 DoIP는 물론 하위 계층 또한 진단하고자 하는 ECU에 구현되어 있어야 합니다.
각 ECU에 대해 이를 개별적으로 구현하는 대신 DoIP에서는 진단 게이트웨이를 사용할 수 있습니다. 즉, 이론적으로 전통적인 버스 시스템이나 네트워크를 통해 연결된 차량의 모든 ECU에 대해 사용이 가능합니다. 게이트웨이는 중개자 역할을 맡게 됩니다. 테스터의 요청은 내부 네트워크로 전달되고 진단하고자 하는 ECU가 이를 수신하여 처리하게 됩니다. 요청된 ECU로부터 응답이 발생하는 즉시 게이트웨이는 이를 테스터로 다시 라우팅하게 됩니다
진단 요청 및 응답을 전달하기 위해 진단 게이트웨이는 항상 다음과 같은 두 가지 정보를 요청합니다. 먼저, 차량 내에서 진단하게 될 ECU를 식별할 수 있는 논리적인 주소가 필요합니다. 둘째로 게이트웨이는 각각의 버스 시스템이나 네트워크에서 어떤 메시지를 사용하여 진단 요청을 전송하거나 진단 응답을 수신할 것인지 알아야 합니다. 게이트웨이를 통해 ECU에 액세스하기 위해서는 이 두 가지 정보가 모두 필요합니다.
진단 중, 진단 게이트웨이는 먼저 테스터로부터 요청을 수신합니다. 이러한 요청에는 원하는 진단 서비스와 진단하게 될 ECU의 논리적인 주소가 있는 진단 패킷이 포함됩니다. 그 후 게이트웨이는 진단 패킷을 제거한 후 활성화된 버스 시스템이나 네트워크로 전송할 수 있는 메시지로 패킹합니다. 예를 들어, CAN을 사용하여 ECU의 주소를 할당하는 경우, 게이트웨이는 관련 식별자(예: 0x600)와 함께 메시지를 버스로 전송합니다. 그 후 ECU로부터의 응답을 기다립니다. 관련 시스템 또는 네트워크로부터 응답을 수신하는 즉시(예: 0x700 식별자가 있는 CAN) 게이트웨이는 진단 서비스에 대한 응답을 테스터로 회신합니다. 이를 위해, ECU의 논리적인 주소를 추가하여, 테스터가 해당 ECU만을 위한 유일한 응답을 할당할 수 있게 합니다. 이로써, 테스터는 다수의 ECU에 대해 순서대로 응답을 대기하지 않으면서도 다른 버스 시스템 및 네트워크로 요청을 전송할 수 있습니다.