| Standard | Full Name | Function | Automotive Relevance |
|---|---|---|---|
| IEEE 802.1AS-2020 | gPTP (Generalized Precision Time Protocol) | Sub-microsecond clock synchronisation | Foundation for all TSN; required for TAS gate scheduling |
| IEEE 802.1Qbv | Time-Aware Shaper (TAS) | Time-gated queues; deterministic transmission windows | Safety streams: guaranteed worst-case latency (e.g., <100 µs) |
| IEEE 802.1Qav | Credit-Based Shaper (CBS) | Bandwidth reservation for audio/video streams | Camera streaming: bounded bandwidth, no burst overflow |
| IEEE 802.1Qbu | Frame Preemption | Low-latency frames can interrupt large frame transmission | Allows mixing 1500-byte camera frames with 100-byte control frames |
| IEEE 802.1CB | FRER (Frame Replication) | Duplicate streams for zero-loss redundancy | Safety-critical ECUs: two paths, zero recovery time |
| IEEE 802.1Qcc | Stream Reservation Protocol (SRP) | Centralised/distributed stream configuration | AUTOSAR TSN: central CNC configures all bridges |
IEEE 802.1 TSN Standards Family
The Latency Determinism Problem
Without TSN: Port egress queue (FIFO, no priority): [1500-byte OTA frame (12 ms at 1 Mbit)] ← currently transmitting [100-byte brake command (waiting!)] ← blocked until OTA frame finishes! Worst-case delay for brake command = 1500×8 / 100Mbit = 120 µs (at 100M link) With TSN TAS (Time-Aware Shaper): t=0: Gate 7 OPEN; Gate 0-6 CLOSED t=50µs: Brake command (Q7) transmitted immediately t=50µs: Gate 7 CLOSED; Gate 0-6 OPEN t=50µs: OTA frame (Q0) continues transmission Result: Without TSN: brake command delay = 0 to 120 µs (unpredictable) With TSN TAS: brake command delay = 0 to 50 µs (bounded, guaranteed) Formula: worst-case delay = guard_band + gate_duration + propagation_delay Typical: ≤ 100 µs end-to-end for safety streams over 2-hop Ethernet path
Automotive TSN Use Cases
| Use Case | Stream Type | TSN Feature | Latency Budget |
|---|---|---|---|
| Brake-by-wire command | Safety, short, periodic | TAS (guaranteed gate window) | < 10 ms E2E |
| Camera video (1 Gbit/s) | Audio/Video Bridging stream | CBS (bandwidth reservation) | < 2 ms frame latency |
| LiDAR point cloud | High-bandwidth periodic | TAS + Qbu (preemption) | < 5 ms E2E |
| OTA firmware update | Best-effort bulk | No TSN (Q0 best-effort) | Unlimited; doesn't block safety |
| Diagnostic (DoIP) | Background, occasional | CBS class B or best-effort | < 500 ms (not real-time) |
| gPTP sync messages | Control, high-priority | Not shaper-dependent; PCP=7 | < 1 µs offset residual |
Summary
TSN is a suite of standards, not a single protocol. For automotive, the core four are: 802.1AS (gPTP — the time synchronisation foundation), 802.1Qbv (TAS — deterministic scheduling), 802.1Qav (CBS — bandwidth reservation for camera streams), and 802.1CB (FRER — redundancy). They are complementary: gPTP provides the shared clock that TAS gate schedules are based on; TAS handles short safety frames; CBS handles sustained bandwidth streams; FRER handles path failures. A vehicle network typically uses all four simultaneously on the same switches.
🔬 TSN Standards Breakdown — Which Standard Does What
Time-Sensitive Networking (TSN) is not a single standard but a suite of IEEE 802.1 amendments. Each addresses a different aspect of deterministic Ethernet behaviour:
- IEEE 802.1AS (gPTP — Generalized Precision Time Protocol): Provides sub-microsecond time synchronisation across all TSN-capable network nodes. The time master (Grand Master Clock) distributes time; all switches and ECUs synchronise to it. Without 802.1AS, there is no shared time base — 802.1Qbv gates cannot be coordinated.
- IEEE 802.1Qbv (Time-Aware Shaper / TAS): Defines a Gate Control List (GCL) that opens/closes queues for specific time windows within each 1 ms network cycle. Safety-critical traffic (e.g., sensor fusion inputs) is assigned a dedicated time slot. No other traffic can interrupt it — zero jitter for that slot.
- IEEE 802.1Qav (Credit-Based Shaper / CBS): Provides bandwidth reservation for Audio/Video Bridging (AVB) class traffic. Less deterministic than TAS but suitable for multimedia streams (backup camera video) that tolerate bounded latency.
- IEEE 802.1Qci (Per-Stream Filtering and Policing): Protects TSN streams from misbehaving talkers. A misconfigured ECU sending too much traffic in a time slot is silently dropped at the switch port. Critical for preventing one failing ECU from disrupting the entire TSN network.
- IEEE 802.1CB (Frame Replication and Elimination): Sends duplicate copies of a frame on two separate paths (redundant switch fabric) and eliminates duplicates at the receiver. Provides seamless redundancy for ASIL-C+ safety streams without requiring failover protocols.
🏭 TSN in Production Automotive Networks
- Volkswagen Group MEB platform: Uses Automotive Ethernet with TSN (802.1AS + 802.1Qbv) on the backbone domain controller network. Camera sensor data at 100 Mbps and ADAS fusion inputs share the same physical network but are isolated in separate TAS time slots.
- TSN switch configuration: The Gate Control List in each TSN switch must be provisioned by a central network configuration tool (e.g., NXP S32G NETCONF, TTTech TSN Configuration Tool). Misconfigured GCLs are the most common cause of TSN integration failures — a 0.1 ms timing error in GCL offsets can cause all time-critical frames to miss their slots.
- 802.1AS convergence time: On a 10-hop network, 802.1AS synchronisation can take 5–10 seconds after power-on. Safety functions that require TSN must wait for synchronisation to complete before entering active mode. Synchronisation status is exposed via MIB/NETCONF management interface.
⚠️ TSN Integration Pitfalls
- 802.1AS not converged before TSN-dependent applications start: If an application starts sending scheduled traffic before gPTP synchronises, frames are sent at the wrong time relative to the network schedule and are dropped by the switch's policing function. Always check sync status before enabling TSN traffic.
- GCL cycle time mismatch between switches: If switch A has a 1 ms GCL cycle and switch B has a 2 ms GCL cycle on the same network, time slots don't align and scheduled traffic experiences inconsistent latency. All switches in a TSN domain must be configured with the same base cycle time.
- TSN configuration not stored persistently: On ECU reset, some TSN switch chips (e.g., NXP SJA1110) require re-provisioning via NETCONF/SSH. If the provisioing agent fails to start before the safety application, the switch falls back to Best Effort mode — all TSN guarantees are lost until the next reboot/reprovision cycle.
- Line rate saturation exceeding TAS budget: If background traffic (diagnostics, OTA) exceeds its allocated time slot bandwidth, it spills into other slots — violating the isolation guarantees. Implement 802.1Qci stream policing on all TSN switch ingress ports.
📊 Industry Note
TSN configuration complexity is the primary reason automotive TSN projects experience 3–6 month delays. A fully TSN-enabled central computing platform with 30+ ECUs has thousands of GCL entries across 8–12 switches. Automated TSN configuration synthesis tools (from Mentor/Siemens, TTTech, or Symtavision) are now considered essential for projects beyond 5 ECUs.
🧠 Knowledge Check — Click each question to reveal the answer
❓ What is the role of IEEE 802.1AS in a TSN network, and what happens to TAS (802.1Qbv) if 802.1AS fails?
❓ What is the difference between CBS (802.1Qav) and TAS (802.1Qbv) in terms of latency guarantee?
❓ An ADAS camera sends 100 Mbps video over a 1 Gbps TSN link shared with diagnostic traffic. How would you design the TSN configuration to prevent diagnostic traffic from affecting camera latency?