Zonal architectures with switches increasingly rely on TSN mechanisms (IEEE 802.1Q) to guarantee hard real-time behavior for individual streams. This post covers the two central AUTOSAR building blocks for that: egress scheduling/shaping and frame preemption.

Why scheduling in the switch is needed at all

Multiple streams compete for the same bandwidth on the same egress port. Without prioritization, a best-effort bulk transfer (e.g. a diagnostic data upload) could block a hard real-time deadline of a safety stream (e.g. a brake signal).

Egress queues, transmission selection and port schedulers

Frames are enqueued into egress queues (EthSwtPortQueue) according to their traffic class assignment. Each queue has a mandatory sub-container EthSwtPortEgressQueueTransmissionSelection, which determines via EthSwtPortEgressQueueTransmissionSelectionAlgorithm how frames are selected for transmission from that queue — e.g. Credit Based Shaper (CBS) or Asynchronous Traffic Shaper.

Egress queues

The EthSwtPortEgressScheduler (mandatory sub-container, algorithm via EthSwtPortSchedulerAlgorithm, e.g. strict priority) then decides which of the already pre-selected queues actually gets to transmit.

Per the SWS, multiple port schedulers can be cascaded at one egress port: the output of one egress scheduler feeds into the next port scheduler as its input. This allows multi-stage prioritization strategies (e.g. CBS smoothing per queue group first, then strict priority between groups) instead of a single flat scheduler.

CBS vs. ETS

MechanismBasic idea

Credit Based Shaper (CBS)

The classic AVB/TSN shaper (IEEE 802.1Qav): a queue accumulates "credit" while transmitting and loses credit while waiting — limits transmit bandwidth to a configured value without fully suppressing bursts

Enhanced Transmission Selection (ETS)

Bandwidth shares are jointly assigned to multiple traffic classes (IEEE 802.1Qaz) — useful when several classes should share a guaranteed minimum bandwidth instead of a strict ranking

Frame preemption (IEEE 802.1Q)

Frame preemption is configured per EthSwtPort (EthSwtFramePreemptionEnable) and requires the switch hardware to actually support it — it’s disabled by default, since the SWS assumes switch hardware typically doesn’t support it.

EthSwtFramePreemptionEnable = TRUE  on the port
        │
        ▼
Frames in the EthSwtPortQueues get classified:
  EthSwtTrafficClassToPreemptionStatusAssignment
        ├── ETHSWT_TRAFFIC_CLASS_PREEMPTABLE  → interruptible
        └── ETHSWT_TRAFFIC_CLASS_EXPRESS      → interrupts others

If preemption is active on a port, it applies to both ingress and egress. A frame classified as "express" can then interrupt a "preemptable" frame on the wire (interspersing) — the critical message doesn’t have to wait until the large frame is fully transmitted.

Frame preemption only works link by link: both ends of a connection must support it. The SWS explicitly states that dynamic negotiation of preemption capability between peers via protocols like LLDP is not supported by AUTOSAR — automotive networks are designed statically enough that a system-wide consistent configuration via the system description is sufficient.

Practical example

An uplink port carries both a hard real-time stream (e.g. brake data, classified as "express") and a diagnostic bulk transfer (classified as "preemptable"). With frame preemption enabled, the brake-data frame can interrupt the ongoing diagnostic frame transfer instead of waiting for it to complete entirely — critical for meeting a hard latency deadline.

Summary

AspectKey takeaway

Egress scheduling

Queue-based, with cascadable port schedulers (strict priority, ETS)

Shapers

CBS for AVB-style bandwidth limiting, ETS for shared bandwidth across multiple classes

Frame preemption

Configurable per port, traffic classes marked as preemptable/express

Key limitation

Only works link by link; no dynamic LLDP negotiation in AUTOSAR — fully static configuration