Why Every EV ECU Now Needs DoIP Testing - and How to Start Without Hardware

If you are working on an ECU for an electric vehicle, an ADAS domain controller, or a central compute platform, there is a good chance your diagnostic transport is no longer CAN. It is Ethernet. And that means your test suite needs DoIP.

This shift is not gradual - it is happening on every new platform. If your CAN-based diagnostic test suite does not include DoIP, it is incomplete.

Why EV Platforms Moved to Ethernet

Three things drove the transition from CAN to Ethernet as the diagnostic backbone:

Bandwidth. A modern ADAS domain controller may receive camera streams, radar point clouds, and HD map data simultaneously. CAN's 1 Mbit/s maximum bandwidth is physically inadequate. Ethernet at 100 Mbit/s or 1 Gbit/s handles the data rate. Diagnostic communication shares this network.

ECU consolidation. Zonal architectures replace 20–30 small domain ECUs with 3–5 powerful domain controllers. Each domain controller manages dozens of sub-ECUs internally. The diagnostic interface connects to the domain controller, which then routes diagnostic messages to the sub-ECU over the internal vehicle network. This routing requires a network-layer diagnostic protocol - which is exactly what DoIP provides.

Software update volume. An EV software update can be 5–10 GB across the entire vehicle. Delivering this over CAN (8 bytes per frame, 500 kbit/s) would take hours. Over Ethernet at 100 Mbit/s, the same update takes minutes. OTA infrastructure demands Ethernet. Diagnostic infrastructure follows.

What DoIP Replaces and What It Keeps

DoIP (ISO 13400) replaces DoCAN (ISO 15765-2) as the transport layer. Everything above the transport layer stays identical: UDS (ISO 14229) service IDs, PDU format, positive and negative response codes - all unchanged. Your 0x22 ReadDataByIdentifier request looks exactly the same over DoIP as it does over CAN. The difference is the network underneath it.

This means your existing UDS test cases are portable. The service logic - session management, DID read/write, security access, fault memory, flash programming - is the same. You add the DoIP transport configuration and change the agent. Your test design investment is preserved.

The Three DoIP Test Scenarios Every EV ECU Team Needs

1. Vehicle Announcement Validation

When the ECU powers up, its DoIP gateway must broadcast a Vehicle Announcement UDP packet containing the VIN, EID, and GID within a specified time window (typically 500ms). This is the entry point for any DoIP session. If the announcement does not arrive, no diagnostic tool can connect. Test this explicitly on every firmware build - it catches gateway initialisation regressions that would otherwise only appear in the vehicle integration lab.

2. Multi-ECU Logical Address Routing

A domain controller manages multiple sub-ECUs, each with a distinct logical address (defined in the vehicle communication matrix). DoIP routes diagnostic messages to the correct ECU based on this address. Test every logical address: send a diagnostic request, verify it reaches the correct ECU and not a neighbour, and verify that an invalid logical address returns the correct DoIP NACK (code 0x00, incorrect logical address).

This is the test most teams skip because it requires knowing the logical address map - which sits in the DoIP entity configuration file (ECU-Extract). Get that file from your ECU supplier. It is the key to mapping your test suite to the real vehicle architecture.

3. UDS Flash Programming Over DoIP

EV ECU software updates are large (50–200 MB for a domain controller) and delivered over Ethernet. The flash programming sequence - 0x10 Programming Session, 0x27 Security Access, 0x31 Flash Erase, 0x34–0x37 Transfer sequence, 0x37 Transfer Exit - is identical to CAN-based flashing, but the payload size per transfer block is dramatically larger (up to 4096 bytes vs 4095 bytes over CAN, limited by the DoIP MaxDataLength negotiation). Test the full cycle. Test it against all supported firmware variants. Automate it in your pipeline so every firmware build is also a flash test.

The Practical Advantage: No Hardware Required

The reason to start DoIP testing today - rather than waiting until your DoIP-capable ECU hardware arrives - is that the DoIP Client Agent runs entirely over your PC's built-in Ethernet port. Connect an Ethernet cable from your laptop to the ECU's Ethernet port. No USB adapter. No PXI module. No specialised interface card.

If you do not have the ECU hardware yet, the DoIP Server Agent simulates a DoIP gateway - responding to vehicle announcements, routing activation requests, and diagnostic messages - so you can develop and validate your test suite against a controlled virtual endpoint before the real hardware exists.

The Validation Engineering Mistake to Avoid

The mistake is treating DoIP as a future concern - something to address when the new ECU platform arrives. By then, your CI/CD pipeline is built, your test suite is established, and adding DoIP feels like a retrofit. The right time to add DoIP test coverage is when you add any other diagnostic test coverage: now, as a standard part of the test suite, not as a special project for the next platform.

The ECU platforms being designed today will ship in 2–4 years. The validation teams designing test suites for those platforms are doing it now. If DoIP is not in your test suite today, it will be a gap in your evidence package tomorrow.