A teardown of a 2021 Audi e-tron 55 quattro

Forty computers.
Five networks.
One car.

Every address, part number and behaviour here was read from a real car through its diagnostic port. This is where each computer sits, what it does, and how a single message crosses the car to reach it.

Scroll to look inside

01 Under the skin

The body is only a shell for the network.

Take the panels away and a second car appears: a harness running along the sills, up the pillars and through the dash, with a computer at every place something has to be sensed or moved. Each box is an ECU, drawn in the colour of the bus it lives on.

02 Detail A · the router

Every message that changes wire passes through one box.

The gateway sits under the dash, left of the console. It has a port on each of the five buses and it is the only module that does. When a message has to go from one bus to another, the gateway stores it, checks it and sends it on. The pulses that stop here are doing exactly that.

It is also the only way in: a tester on the OBD socket can only ever talk to the gateway.

03 The drawing

Explore it yourself.

Drag to turn the car. Press 1 to 8 for set views. Hold Ctrl and scroll to zoom. Tap or click any module on the car, or pick one from the parts list.

04 In motion

Five things the car does, one message at a time.

05 The network

Why five buses, not one.

No single wire can carry a brake command and a radar stream at once. So the car runs a hierarchy: cheap and slow where that is enough, fast and deterministic where lives depend on it. ECUs share no memory; the only way one knows anything about another is a message on a wire.

System schematic

The same network as the drawing, drawn the way an engineer would. CAN and CAN FD are shared, terminated lines; FlexRay and Ethernet are stars that meet inside the gateway; LIN hangs off its master. Hover anything to see what it connects to, or trace a scenario and watch where messages have to stop at the gateway.

Module order along each line is front to rear. Termination points and the star coupler and switch inside the gateway are schematic.

06 The roster

Every module on this car, in one line each.

Item numbers match the numbers on the drawing, counted front to rear. Select a row to see that module on the car. A button then brings you back here.

07 Criticality

The more it can hurt you, the more locks it has.

Reading is open almost everywhere. Writing is gated, and on safety and high-voltage modules it is simply not done. This rule shaped every decision in the project behind this page.

Read vs. write, by group

08 Talking to it

One language, nine verbs, four locks.

Every ECU speaks UDS (ISO 14229): send a service and a parameter, the ECU answers. Some verbs are free. Others sit behind barriers that must be opened in order.

The verbs

The locks, in order

One real exchange

Every message changes wire at the gateway, reading is free, and the cluster refuses a coding write until two other values have been written in the same session.

09 What I found

I wanted the animated taillights. Two writes got me there.

Reading the car was easy. Writing to it took two steps that I could not find written down anywhere. The first was a coding write to the instrument cluster, which only works after two other values are written. The second was a feature licence on the gateway. Both are explained below, with the other things I learned on the way.

What worked

Identifying every module over DoIP by reading F187 and F19E.
Reading fault memories and identification data, with no key.
Writing the coding bits I needed, reading each one back to check it.
The redacted secret from finding 6, which I don't publish. See finding 6.
The animated taillights now run.

What I could not do, or chose not to

Clear faults on seven modules. They refuse the standard clear command (finding 7). This can easily be reversed engineered but it was not a priority.
Write to the brakes, airbag, steering or any high-voltage module. I never tried (Note 1). ... you know why ツ