The EthSwt overview article already covered what an AUTOSAR Ethernet Switch Driver does and when you need one instead of a plain EthTrcv. This tutorial series now goes one level deeper: before the next parts cover API calls, ARXML containers and VLAN configuration, this first part clarifies what the official Specification of Ethernet Switch Driver (Document ID 656, AUTOSAR CP R25-11) actually mandates — state machine, configuration classes, and how the module fits into the stack.

Every claim in this post has been checked against the original SWS text (docs/references/autosar-sws/AUTOSAR_CP_SWS_EthernetSwitchDriver_R25-11.txt in this blog’s source repository).

The SWS EthSwt at a glance

At roughly 330 pages, the SWS EthSwt is noticeably larger than the SWS EthTrcv — not because a switch is inherently more complex, but because it brings additional functional areas a plain transceiver simply doesn’t have: port mirroring, MAC learning, VLANs, Time-Sensitive Networking (TSN), MACsec at the switch level, and interaction with the Firewall module. This series covers the fundamentals in parts 1–4 and dives into the specialized topics afterwards in dedicated posts.

SWS EthSwt (Document ID 656) — chapter overview
──────────────────────────────────────────────────────────────
1  Introduction and functional overview
5  Dependencies to other modules
7  Functional specification          ← basis of this post
   7.1.1  Indexing scheme
   7.1.2  Port Mirroring
   7.1.3  State Handling             ← state machine
   7.1.7  Functional Description     (Learning, VLAN, TSN, MACsec, ...)
8  API specification                 ← Part 2 of this series
10 Configuration specification       ← Part 3 of this series

The module’s state machine

Contrary to what you might expect, the EthSwt state machine isn’t a simple Uninit/Init pair — it has four stages, explicitly distinguishing between "the driver is initialized" and "the ports are initialized":

EthSwt_StateType (SWS_EthSwt_00123)
──────────────────────────────────────────────────────────────
ETHSWT_STATE_UNINIT              0x00   Switch is not yet configured
        │
        │  EthSwt_Init()
        ▼
ETHSWT_STATE_INIT                0x01   Switch driver is initialized
        │
        │  (port initialization completed)
        ▼
ETHSWT_STATE_PORTINIT_COMPLETED  0x02   Port initialization is completed
        │
        │  EthSwt_SetSwitchPortMode(ACTIVE)
        ▼
ETHSWT_STATE_ACTIVE              0x03   Switch is active

The SWS explicitly describes this state as "status supervision used for Development Error Detection" — so its primary purpose is error diagnosis (DET), not application-level flow control. Still, it’s worth checking first when debugging a bring-up issue: if the driver is still stuck in UNINIT, EthSwt_Init most likely hasn’t been called (successfully) yet.

Configuration classes

Like every AUTOSAR BSW module, EthSwt distinguishes between pre-compile, link-time and post-build parameters. For a switch driver this yields a practically useful rule of thumb:

Configuration classTypical for EthSwt

Pre-compile

Basic module capabilities that affect compile-time code generation — e.g. whether EthSwt_GetSwitchRegApi is present at all, number of supported switches

Link-time

Rarely used for EthSwt, usually project-specific library binding

Post-build

The bulk of practical parametrization: port count, VLAN assignment, MAC learning mode, mirroring configuration — values that differ between vehicle variants without requiring the driver to be recompiled

According to the SWS, EthSwt_ConfigType (chapter 8.2.2) is explicitly defined as an "implementation specific structure of the post build configuration" — the actual structure is up to the MCAL vendor, only its post-build nature is normative.

The indexing scheme: SwitchIdx and SwitchPortIdx

A detail that’s more often overlooked than you’d think: EthSwt uses two separate, zero-based indices (chapter 7.1.1):

  • SwitchIdx — identifies which switch is meant, if an ECU has multiple physical switch chips

  • SwitchPortIdx — identifies a port on that switch

Practically every EthSwt API (see Part 2) therefore takes either both indices or at least SwitchIdx. Accidentally passing a SwitchPortIdx that belongs to a different switch under the wrong SwitchIdx won’t produce a compile error — just wrong behavior on the wrong port.

If an ECU integrates multiple switch chips from different vendors, the SWS requires (SWS_EthSwt_00131) that the function names of the respective driver instances differ — e.g. by appending a vendor or type identifier. Two EthSwt_Init functions with the identical symbol name for two different chips are not permitted.

Architecture in the AUTOSAR Ethernet stack

EthSwt sits between EthIf and the EthTrcv instances of the individual switch ports:

EthSwt in the AUTOSAR Ethernet stack

The key difference from a plain EthTrcv setup: EthSwt typically has multiple EthTrcv instances underneath it — one per external port — while the host itself talks to the switch over a single Eth/EthIf path. The switch itself handles forwarding between the external ports without every frame having to pass through the host.

A useful mnemonic: with a plain EthTrcv, the host "sees" every bit that goes over the wire. With a switch behind EthSwt, the host only sees the frames addressed to itself, or the ones it explicitly requests via mirroring or management APIs — the switch makes the forwarding decision autonomously in hardware.

Multi-switch topologies

Cascaded switches are the norm in zonal architectures: a backbone switch in the central gateway, connected via uplink ports to smaller switches in the zonal controllers. The SWS explicitly accounts for this through the port role ETHSWT_UP_LINK_PORT and dedicated mechanisms for clock synchronization between cascaded switches (more on that in issue #142 of this series).

Interaction with EthIf

EthIf abstracts every switch port as its own virtual controller towards the upper layers — to TcpIp/SoAd, a switch port looks exactly like a standalone EthTrcv controller. That’s the key trick that frees the higher communication layers from having to distinguish between "plain transceiver" and "switch port".

Overview of the series

PartTopic

1 (this post)

Fundamentals, SWS & architecture — state machine, configuration classes, indexing scheme, position in the stack

2 — API & initialization sequence

The concrete EthSwt function calls and their order

3 — ARXML configuration

Container structure, mandatory parameters, complete example

4 — VLAN management, mirroring & diagnostics

Runtime VLAN changes, mirroring, MAC learning, MIB counters

Several dedicated posts additionally dive into specialized topics: hardware architecture (including the internal switch fabric and switch stacking), TSN (stream identification, time-aware shaping, frame preemption), MACsec in the switch, firewall interaction, global time support, the ARL table/MAC learning, and diagnostics/register access (SPI/SMI).

Summary

AspectKey takeaway

State machine

Four stages: UNINIT → INIT → PORTINIT_COMPLETED → ACTIVE, primarily intended for Development Error Detection

Configuration classes

Practical parametrization (ports, VLANs, mirroring) runs almost exclusively through post-build configuration

Indexing scheme

Two separate, zero-based indices: SwitchIdx (which switch) and SwitchPortIdx (which port on that switch)

Architecture in the stack

EthSwt sits below EthIf, but typically has multiple EthTrcv instances underneath it — one per external port

Next step

Part 2 shows the concrete API and initialization order of EthSwt

Next in the EthSwt series: EthSwt Part 2 — API & Initialization Sequence