Automotive Ethernet Basics: VLANs, Timing and Bandwidth for ADAS Data

The problem

Cameras and lidars produce far more data than CAN or CAN FD can carry, so vehicles use 100BASE-T1 and 1000BASE-T1 Ethernet with VLANs and priorities. Engineers must budget bandwidth and latency before choosing a topology. This project teaches the method: calculate a budget, build a test network in software, load it with realistic streams and measure whether the priorities protect control traffic.

Objectives

• Estimate data rates for camera, radar and control streams in an ADAS system.
• Configure VLANs and priority tagging on Linux virtual interfaces.
• Generate realistic traffic streams and measure throughput, latency and jitter.
• Use traffic control queuing disciplines to protect high-priority traffic.
• Compare measured results with the calculated budget.

What you need

Key concepts

100BASE-T1 and 1000BASE-T1

Automotive Ethernet physical layers that run full-duplex over a single twisted pair at 100 Mbit/s and 1 Gbit/s, saving weight and cost compared with standard four-pair Ethernet.

VLAN and PCP

An IEEE 802.1Q tag adds a VLAN ID to separate traffic domains and a 3-bit Priority Code Point that switches use to pick a queue.

Jitter

Variation in latency between successive frames of a periodic stream. Control loops tolerate a fixed delay better than an unpredictable one.

Head-of-line blocking

A small urgent frame waits behind a large frame already being sent. At 100 Mbit/s a full-size frame takes about 120 microseconds to transmit.

Step-by-step guide

1. 1

   Define streams and calculate the budget

   List the streams for a simple front ADAS zone: one compressed front camera at a stated bit rate, one radar object list at 20 Hz, a vehicle-control message at 100 Hz and background diagnostics. For each, calculate payload rate, frame overhead including Ethernet, VLAN tag, IP and UDP headers, and total link utilisation on 100 Mbit/s. State latency targets, for example 1 ms for control and 30 ms for camera frames.

   Checkpoint: A budget table with per-stream rates, overheads, total utilisation and latency targets.

2. 2

   Build the test network

   Using Linux network namespaces, create a sender namespace per domain and a receiver namespace connected through a Linux bridge. Limit the egress link to 100 Mbit/s with a tc token bucket filter so it behaves like a 100BASE-T1 link. Document every command in a setup script so the network can be rebuilt exactly. Verify the rate limit by running iperf3 and checking the achieved throughput.

   Checkpoint: A setup script and an iperf3 result showing throughput capped near 100 Mbit/s.

3. 3

   Configure VLANs and priorities

   Create 802.1Q VLAN sub-interfaces for a camera VLAN, a control VLAN and a diagnostics VLAN, and map socket priority to PCP with the egress-qos-map option. Capture in Wireshark and confirm that each stream carries the expected VLAN ID and PCP value. Explain why VLANs separate domains for both security and traffic management. Keep a table that maps each stream to its VLAN, PCP value and queue for use in later steps.

   Checkpoint: Wireshark shows the three VLAN IDs with the configured PCP values on the right streams.

4. 4

   Generate the streams

   Write a Python generator for the control stream that sends small UDP frames every 10 ms with a sequence number and a send timestamp, using a monotonic clock. Generate the radar list similarly at 20 Hz with a few hundred bytes per frame. Use iperf3 UDP at the calculated camera bit rate with large datagrams to stand in for camera traffic. Run diagnostics as bursty TCP transfers.

   Checkpoint: All four streams run together and appear at the receiver with expected rates.

5. 5

   Measure with a single queue

   With a default first-in, first-out queue, run all streams and log control-frame latency and jitter from receiver timestamps. Then increase the camera stream until total offered load exceeds 90 and then 100 per cent of the link, and observe what happens to control latency and loss. This baseline shows why priority queuing is needed. Check sender and receiver timestamps use the same host clock so latency values are meaningful.

   Checkpoint: Plots of control latency and loss against total load with a single FIFO queue.

6. 6

   Add priority queuing

   Replace the root queue with a tc priority or multiqueue priority discipline mapping PCP to separate bands, so control traffic is always served first. Repeat the load sweep. Then try a shaper on the camera class to cap its rate. Compare control latency, jitter and loss with the FIFO case at every load level. Run each load level for at least a few minutes so rare long delays have a chance to appear.

   Checkpoint: Control latency stays within target at high load with priority queuing, shown side by side with FIFO.

7. 7

   Study head-of-line blocking

   With priority queuing in place, vary camera datagram size from 200 bytes to the maximum and measure the worst-case control latency. Compare with the calculated transmission time of one maximum-size frame at 100 Mbit/s. This shows that strict priority cannot pre-empt a frame already on the wire, which motivates frame pre-emption and time-aware shaping in Time-Sensitive Networking. Keep all other settings fixed between runs so that only the queuing discipline changes.

   Checkpoint: A plot of worst-case control latency against camera frame size compared with the theoretical value.

8. 8

   Compare with the budget

   Put measured throughput, latency and jitter next to the calculated budget for every stream. Explain differences: software timing noise on a general-purpose Linux host, queueing in the bridge and timestamp resolution. Repeat the key runs three times to show spread. Recalculate what changes on a 1000BASE-T1 link and whether the camera stream would then fit with margin. Plot the theoretical maximum-frame transmission time as a reference line on the same chart.

   Checkpoint: A table of budget versus measured values with the spread from repeated runs.

9. 9

   Report

   Write up the stream definitions, budget method, network setup scripts, VLAN and queuing configuration, measurements and comparison. Explain the limitation clearly: this is a software emulation, not a real automotive PHY or switch, so absolute timing is indicative. Summarise the practical rules learned, such as separating domains with VLANs, giving control traffic high priority and keeping link utilisation below a safe level.

   Checkpoint: A report with scripts, captures, plots and a set of justified design rules.

Testing & validation

• VLAN IDs and PCP values confirmed in Wireshark for each stream.
• Throughput cap verified with iperf3.
• Control latency, jitter and loss against load for FIFO and priority queuing.
• Worst-case control latency against frame size compared with theory.

Expected results

An emulated automotive Ethernet zone with VLANs and priority queuing, a calculated bandwidth budget, and measurements showing how priorities protect control traffic and where head-of-line blocking remains.

Take it further

• Emulate a time-aware shaper with the Linux taprio queuing discipline.
• Add a second switch hop and measure accumulated latency.
• Repeat key tests on a pair of real 100BASE-T1 media converters if available in the lab.
• Replace iperf3 camera traffic with replayed recorded video packets.

Viva and review questions

Learn it at DIYguru

These DIYguru courses and programmes teach what this project needs.