Automotive Ethernet and TSN · Bhargava Mandapati

Everything in this module rests on the network. Services, data brokers and central compute all assume that moving data around the vehicle is fast and predictable — which, on , it is not.

What CAN could and could not do#

CAN has been the vehicle backbone since the 1980s, and it earned that position. It is extremely robust, cheap, needs only two wires, and degrades gracefully.

Its limits, though, are structural:

	CAN	What a modern vehicle needs
Speed	Up to 1 Mbit/s	Camera and sensor data: hundreds of Mbit/s
Payload	8 bytes per frame	Structured messages, sometimes kilobytes
Topology	Shared bus, everyone hears everything	Switched, point-to-point
Addressing	None — messages are numbered, not addressed	Named endpoints
Growth	Adding traffic loads the whole bus	Capacity that scales

Why ordinary Ethernet was not enough#

Office Ethernet is fast, cheap and universal. Two things made it unusable in a vehicle without modification.

Cabling. Standard Ethernet uses four twisted pairs and bulky connectors. Automotive Ethernet (100BASE-T1, 1000BASE-T1) runs over a single twisted pair with automotive connectors, tolerating vehicle temperature ranges and electromagnetic conditions.

Timing. This is the important one.

What TSN adds#

— Time-Sensitive Networking — is a set of IEEE standards that add guarantees to Ethernet. The pieces that matter in a vehicle:

Time synchronisation. Every device shares a common clock, accurate to microseconds. Everything else depends on this.

Scheduled traffic. The network runs on a repeating schedule with reserved slots. A control message has a slot; nothing else may transmit during it.

Frame preemption. A large, low-priority frame already in transmission can be interrupted so an urgent frame goes first, then resumed.

Stream reservation. A talker declares its bandwidth and latency needs up front; the network either guarantees them or refuses the stream.

What this means in practice#

The network is designed, not grown. Schedules and reservations are computed offline from a description of all traffic. Adding a stream is a configuration change, not something that happens spontaneously.

CAN does not disappear. Automotive Ethernet is the backbone; CAN remains at the edges, connecting simple sensors and actuators where its cost and robustness still win. A gateway translates between them, and that gateway is significant, ongoing work on every real programme.

The realistic topology

   sensors/actuators ──CAN/LIN──> zone controller
                                        │
                                   Automotive
                                    Ethernet
                                    (+ TSN)
                                        │
                                 central compute

Diagnostics change. Debugging shifts from a CAN analyser to Ethernet packet capture. Familiar tools work, with automotive-specific dissectors.

Looking at the wire

# CAN, at the edges
candump can0
 
# Ethernet backbone
tcpdump -i eth0 -w capture.pcap
# then analyse SOME/IP and DDS traffic in Wireshark

What to check on a programme#

Is TSN actually enabled, or is it Ethernet without timing guarantees? This is a real distinction and the answer is sometimes "not yet".
Who owns the network schedule, and what does adding a stream cost?
Where is the CAN boundary, and who owns the gateway?
Is there reserved headroom for streams added later in the programme?

Next#

The protocol that carries services over this network.