The problem
ADAS sensors produce high-rate streams that share Ethernet links with safety-critical control messages. Standard priority queuing cannot bound latency tightly enough under heavy load, which is why Time-Sensitive Networking (IEEE 802.1 TSN) adds traffic shapers, scheduled gates and frame pre-emption. Choosing and configuring these mechanisms is hard. This project quantifies their benefit and cost for a realistic ADAS topology.
Objectives
- Build a simulation model of an ADAS Ethernet topology with realistic stream definitions.
- Configure strict priority, credit-based shaper, time-aware shaper and frame pre-emption.
- Synthesise gate control schedules for time-triggered control traffic.
- Measure worst-case latency, jitter and loss for every stream class.
- Compare simulation results with analytical worst-case bounds.
What you need
Tools and toolboxes
- OMNeT++ with the INET framework — Simulates Ethernet switches, TSN shapers, gate scheduling and frame pre-emption.
- Python with NumPy, pandas and matplotlib — Generates stream definitions, runs batch simulations and analyses result vectors.
- Python with an SMT or ILP solver (for example Z3 or OR-Tools) — Synthesises gate control lists that meet stream deadlines without conflicts.
- MATLAB — Optionally computes analytical latency bounds and compares them with simulation.
- Wireshark — Inspects exported packet traces from selected simulation runs.
Software
- OMNeT++ and INET
- Python with NumPy, pandas, matplotlib and Z3 or OR-Tools
- MATLAB (optional)
- Wireshark
Extra parts and data
None beyond the software above.
Key concepts
- Credit-based shaper (IEEE 802.1Qav)
- Limits the rate of a traffic class by spending credit while sending and earning it while waiting, which spreads bursts and bounds latency for audio-video style streams.
- Time-aware shaper (IEEE 802.1Qbv)
- Opens and closes per-queue gates according to a repeating schedule, so time-triggered traffic gets exclusive windows on the link.
- Frame pre-emption (IEEE 802.1Qbu and 802.3br)
- An express frame can interrupt a pre-emptable frame mid-transmission; the interrupted frame resumes afterwards, reducing blocking delay.
- Guard band
- A period before a scheduled window in which no new low-priority frame may start, so the window is not delayed by a frame already on the wire.
Step-by-step guide
- 1
Define the topology and streams
Model a front ADAS zone: four cameras, one lidar, five radars, a zonal switch, a backbone link at 1 Gbit/s and a central computer, plus a control path to a brake and steering controller. Define streams with period, frame size, deadline and class: control at 1 ms with tight deadlines, radar object lists, compressed camera video and lidar point clouds as bulk, and best-effort diagnostics. Base rates on documented sensor classes and state assumptions.
Checkpoint: A stream table with period, size, deadline and class for each stream and a topology diagram.
- 2
Build the simulation model
In OMNeT++ with INET, create the network description with TSN-capable switches and end stations, configure link rates and cable delays, and add stream sources matching the table with fixed periods and random phase. Record per-frame end-to-end delay for every stream. Run a sanity check at low load and compare latencies with hand-calculated store-and-forward values. Keep the stream table in one file that both the simulation and the analysis scripts read.
Checkpoint: Low-load simulated latencies match hand calculations within a small margin.
- 3
Run the strict priority baseline
Configure eight priority queues with strict priority, mapping control to the highest. Run at nominal load and at load factors up to 0.95 of the backbone link by scaling camera and lidar rates. Record maximum and 99.9th-percentile latency and jitter for control and radar classes. Repeat each configuration with several random seeds for phase. Fix the simulation time and warm-up period so each run is comparable.
Checkpoint: Baseline latency and jitter curves against load with spread across seeds.
- 4
Add credit-based shaping
Apply credit-based shapers to the camera and lidar classes with idle slopes sized from their reserved bandwidth. Repeat the load sweep. Check whether bursty bulk streams now delay control traffic less, and whether camera latency stays within its own deadline. Tune idle slopes and record the trade-off between bulk latency and control protection. Save the raw result vectors as well as summaries so later analysis can recompute any metric.
Checkpoint: Comparison plots of control and bulk latency with and without credit-based shaping.
- 5
Synthesise a gate schedule
Formulate gate scheduling for the control streams as constraints: each frame must be sent within its window on each link, windows on consecutive links respect propagation and processing delays, and windows for different streams do not overlap. Solve with Z3 or OR-Tools, minimising total reserved time. Export gate control lists to the INET configuration. Record solver time against number of streams.
Checkpoint: A valid gate schedule loaded into the simulation, and a plot of solver time against stream count.
- 6
Evaluate time-aware shaping
Run the load sweep with the time-aware shaper using the synthesised schedule, first with guard bands sized for a maximum-length frame. Measure control latency and jitter, which should become nearly constant, and the bandwidth lost to guard bands and reserved windows. Compare bulk-stream latency with earlier configurations, because reserved windows take capacity from them. Check in the simulation that no scheduled control frame ever waits outside its window.
Checkpoint: Control jitter near zero under all loads, with measured bandwidth overhead of guard bands.
- 7
Add frame pre-emption
Enable frame pre-emption so control frames are express and bulk frames pre-emptable, and shorten guard bands accordingly. Repeat the sweep. Measure the reduction in guard-band overhead and any change in control latency, and record the extra overhead of fragment headers on bulk streams. Test pre-emption without scheduling as a separate configuration to separate the two effects. Report fragment counts per bulk stream to show how often pre-emption actually happens.
Checkpoint: Results tables for pre-emption alone and with time-aware shaping, including overhead figures.
- 8
Compare with analytical bounds
Compute worst-case latency bounds for the strict priority and credit-based cases using a published analysis approach such as network calculus, and the deterministic latency of scheduled streams from the schedule itself. Compare with simulated maxima. Simulated values must not exceed valid bounds; if they do, check model assumptions. Discuss how pessimistic the bounds are. State every assumption of the analysis method, such as arrival curves for each stream class.
Checkpoint: A table of analytical bounds against simulated maxima per class and configuration.
- 9
Robustness study
Test sensitivity of each configuration to clock synchronisation error by adding offset between switch schedules, to a sensor sending a burst above its specification and to a link failure that reroutes traffic. Record which configurations keep control deadlines. Time-aware shaping depends on synchronised clocks through gPTP, so quantify how much error it tolerates. Plot deadline misses against clock offset to find the tolerance limit for each configuration.
Checkpoint: Deadline-miss results for each disturbance and configuration.
- 10
Write the thesis
Present the topology, streams, configurations, schedule synthesis, results, bounds comparison and robustness study. Give design guidance: which mechanism suits which stream class, what configuration effort each requires and what it costs in bandwidth. Release the simulation models, stream definitions and scripts. State the limits: simulation only, idealised switch processing and assumed stream definitions. Include a table that summarises which mechanism suits which stream class and why.
Checkpoint: A thesis draft with released models and a clear design-guidance section.
Testing & validation
- Low-load latencies match hand calculations.
- Latency and jitter against load for each TSN configuration over several seeds.
- Gate schedules validated by simulation with no deadline misses.
- Simulated maxima within analytical bounds.
- Robustness to clock error, bursts and link failure.
Expected results
A simulation study of TSN mechanisms for an ADAS network, with schedule synthesis, measured latency and jitter, comparison with analytical bounds and practical configuration guidance.
Research angle for your PhD
Research questions: what combination of TSN mechanisms gives the best trade-off between control-traffic determinism and bulk sensor throughput in ADAS networks, and how does schedule synthesis scale and tolerate clock error? Metrics: worst-case latency, jitter, deadline misses, bandwidth overhead and solver time. Baselines: strict priority and credit-based shaping. Contribution: a reproducible simulation and synthesis toolchain with robustness analysis, suitable for conference or journal publication in automotive networking.
Take it further
- Add per-stream filtering and policing to contain a faulty sensor.
- Co-optimise gate schedules with the task schedule on the central computer.
- Model redundant paths with frame replication and elimination.
- Validate a subset on real TSN-capable hardware if the lab has it.
Viva and review questions
Why does strict priority not guarantee tight latency?
A high-priority frame can still wait for a lower-priority frame already being transmitted, and many high-priority streams can queue behind each other in bursts.
What does a guard band cost?
Link time before each scheduled window in which nothing new may start, which reduces bandwidth available to other traffic.
How does frame pre-emption help?
It lets an express frame interrupt a bulk frame, so guard bands can shrink to the length of a minimum fragment instead of a full frame.
Why does the time-aware shaper need clock synchronisation?
All switches must open gates at the right moments relative to each other; clock offset shifts windows and can cause frames to miss them.
Learn it at DIYguru
These DIYguru courses and programmes teach what this project needs.