Gateway ECU (Central Gateway)
The gateway ECU connects the vehicle networks and decides which messages cross between them. Why it is the key security boundary and how its diagnostic routing fails.
Updated This page as Markdown
In short
A gateway ECU, often called central gateway, connects the vehicle networks (CAN and CAN FD domains, automotive Ethernet, the OBD connector) and forwards only the messages that are allowed to cross. It is usually also the DoIP entity that receives diagnostic requests over Ethernet and routes them to the ECUs behind it. That makes it the main security boundary of the electrical architecture, and a gateway that routes too much undoes the protection of every ECU behind it.
What is a gateway ECU?
A gateway ECU sits between the networks of the vehicle and forwards messages from one to another according to a routing table. Powertrain CAN, chassis CAN, body CAN, infotainment Ethernet and the OBD connector are separate segments; the gateway decides which CAN IDs, signals or diagnostic requests cross. In zonal architectures the role spreads across zone controllers and a central computer, but the function stays the same.
For diagnostics, the gateway is usually the entry point. A tester on the OBD connector or on Ethernet talks to the gateway, and the gateway routes the UDS request to the target ECU, translating between DoIP and ISO-TP on CAN where needed.
Where is it defined?
The gateway as an ECU is an architecture decision of the vehicle manufacturer, not a standardised device. Its diagnostic role is defined in ISO 13400-2: vehicle identification, routing activation (payload type 0x0005, response 0x0006) and diagnostic messages (payload type 0x8001) over TCP and UDP port 13400, with logical addresses for the tester and each target. ISO 14229-1 defines the UDS requests it forwards, ISO 11898-1 the CAN segments behind it.
What it means in practice
The gateway is where the security architecture is either enforced or quietly bypassed. On the bench the main question is: what can a tester reach, from which interface, in which state? We regularly see DoIP gateways that route diagnostic requests to ECUs that should be blocked from that interface, routing activation that accepts any source address without authentication, and routing rules that ignore whether the vehicle is moving or in a workshop mode.
A gateway also has its own UDS server with sessions, services and SecurityAccess, and its own firmware update path. Because it touches every network, a compromised gateway is the most valuable foothold in the vehicle.
How AutoST tests it
AutoST tests the gateway over DoIP: it performs vehicle discovery over UDP, runs routing activation and then enumerates sessions, services, DIDs and SecurityAccess on the gateway and on every logical address it routes to. That shows directly which ECUs are reachable through the gateway from the test interface. On CAN, the same UDS tests run against the gateway’s own diagnostic address.
Common misunderstandings
A gateway is not a firewall in the IT sense. Its routing tables are written for function, and diagnostic routing is typically opened for production and workshops. Testing only the ECUs and not the routing misses the path an attacker takes.
FAQ
Frequently asked questions
What is the difference between a DoIP edge node and a DoIP gateway?
ISO 13400-2 calls the DoIP entity that terminates the external Ethernet link the edge node. A DoIP gateway is a DoIP entity that forwards diagnostic messages to other ECUs, on Ethernet or on CAN behind it. In most vehicles the central gateway is both.
Does a gateway firewall make the ECUs behind it safe?
It reduces what reaches them from outside, but it is not a replacement for ECU hardening. Anyone on the internal bus bypasses the gateway, and diagnostic routing is often opened wider than the threat analysis assumed.
What should a gateway test cover?
Which logical addresses it routes to from each interface, whether routing activation needs authentication, whether the routing rules depend on the session or vehicle state, and how the gateway behaves under malformed or flooding traffic.
Sources
- ISO 13400-2:2019 Road vehicles, Diagnostic communication over Internet Protocol (DoIP), Part 2: Transport protocol and network layer services
- ISO 14229-1:2020 Road vehicles, Unified diagnostic services (UDS), Part 1: Application layer
- ISO 11898-1:2015 Road vehicles, Controller area network (CAN), Part 1: Data link layer and physical signalling
Related pages
- GlossaryDoIP (Diagnostics over Internet Protocol)DoIP (ISO 13400) carries UDS over Ethernet: vehicle discovery, routing activation and diagnostic messages on port 13400. How it works and where gateways go wrong.
- GlossaryECU (Electronic Control Unit)An ECU is an embedded computer that controls one function of a vehicle. What sits inside, which interfaces it exposes and why every ECU is a security test object.
- GlossaryFunctional vs. Physical AddressingPhysical addressing sends a UDS request to one ECU, functional addressing to all of them. CAN IDs 0x7E0 and 0x7DF, the single-frame rule and the response rules.
- PlatformFollow the ECU onto the network.AutoST tests automotive Ethernet: UDS over IP, DoIP routing activation and vehicle discovery, and SOME/IP service discovery with service and method mapping.
- InsightsDoIP test setup: from Ethernet link to UDS over IPA practical DoIP bench setup: addressing, vehicle discovery, routing activation and running UDS over IP, with the byte-level exchanges you need to get a link up.
