This post is the companion to the EthTrcv Part 1 — Basics & Classification series: while EthTrcv drives the PHY chip on exactly one port, EthSwt takes care of ECUs with multiple ports and a switch chip sitting between them. General background on AUTOSAR is covered in the AUTOSAR basics post.

If you’ve so far only configured simple ECUs with a single Ethernet connection, you know EthTrcv, EthTrcv_Init, EthTrcvMiiInterface — and that’s it. But as soon as an ECU has to serve multiple Ethernet participants (a zonal gateway, a domain controller with several camera feeds), that model stops being sufficient. That’s where EthSwt comes in.

What Is EthSwt?

EthSwt is the AUTOSAR Basic Software driver for Ethernet switch ICs. It encapsulates the configuration and control of a switch chip that connects multiple physical ports with Layer 2 forwarding between them.

The basic question that decides "do I need EthSwt?" is simple:

SituationDriver

One Ethernet port, one PHY, a point-to-point link

EthTrcv is sufficient

Multiple Ethernet ports that need to forward frames between each other (switching)

EthSwt required, in addition to EthTrcv per port

ECU with VLANs, port mirroring, prioritization across multiple participants

EthSwt mandatory

EthSwt does not replace EthTrcv — it complements it. Each physical port of a switch chip typically still has its own PHY (internal or external), which continues to be configured through EthTrcv. EthSwt sits on top and handles the switch-specific logic: forwarding tables, VLANs, port states.

In practice, EthSwt mainly shows up in two scenarios:

  • Zonal gateway ECUs that aggregate Ethernet traffic from multiple zones and forward it onto the backbone.

  • Domain controllers with multiple cameras or sensors, each connected via its own 100BASE-T1 link, whose frames need to converge on a shared uplink.

Architecture in the AUTOSAR Ethernet Stack

EthSwt sits in the Basic Software between EthIf and the EthTrcv instances of the individual switch ports. The overall layout looks like this:

                     ┌────────────────────────────────────────┐
                     │                  EthIf                 │
                     │  (abstraction: virtual controllers)     │
                     └───────────────┬────────────┬───────────┘
                                      │            │
                         ┌────────────┘            └────────────┐
                         ▼                                      ▼
                 ┌───────────────┐                      ┌───────────────┐
                 │      Eth      │                      │     EthSwt    │
                 │ (controller   │                      │  (switch      │
                 │  driver, MAC) │                      │   driver)     │
                 └───────┬───────┘                      └───┬───┬───┬───┘
                         │                                  │   │   │
                         ▼                                  ▼   ▼   ▼
                    ┌─────────┐                        ┌─────┐┌─────┐┌─────┐
                    │ EthTrcv │                        │EthTrcv││EthTrcv││EthTrcv│
                    │ (1 port)│                        │Port 1 ││Port 2 ││Port 3 │
                    └────┬────┘                        └───┬───┘└───┬───┘└───┬───┘
                         ▼                                 ▼        ▼        ▼
                       PHY                                PHY      PHY      PHY
                         │                                 │        │        │
                       Cable                             Cable    Cable    Cable

Key points in this picture:

  • Eth is the classic controller driver for the SoC’s MAC connection (e.g. the SoC’s internal uplink port to the switch chip, often via RGMII or SGMII).

  • EthSwt manages the switch chip as a whole: register configuration over SPI/I2C or MDIO, forwarding rules, VLAN tables, port states.

  • Each physical port of the switch chip still has its own EthTrcv, because at the line level a PHY (often integrated into the switch IC) is still what generates the signal on the cable — see the EthTrcv Hardware Deep Dive for details.

  • EthIf additionally abstracts switch ports as their own virtual controllers, so upper software layers (socket adaptor, TCP/IP stack, DoIP) don’t need to know whether a frame travels over a physical MAC controller or a switch port.

A common misconception: EthSwt does not "talk" directly to EthIf users such as DoIP or the TCP/IP stack. Those always communicate through EthIf — EthSwt is a pure configuration and management layer for the switch chip itself.

EthSwt API — the Core Functions

Compared to EthTrcv, the EthSwt API is much more management-heavy: less "send this frame," more "configure this port this way." Three functions form the core.

EthSwt_Init

void EthSwt_Init(
    const EthSwt_ConfigType* CfgPtr
);

Initializes the switch driver from the generated configuration structure. This typically involves:

  • setting up the communication interface to the switch chip (SPI, I2C, or an MDIO-based register interface, depending on the chip),

  • setting the initial port states (e.g. all ports starting out DISABLED or BLOCKING until the upper layers activate them),

  • loading the initial VLAN configuration, forwarding database, and, where applicable, QoS prioritization.

Like many AUTOSAR init functions, EthSwt_Init returns void — errors are reported through the Diagnostic Event Manager (DEM) or the Development Error Tracer (DET), not via a return value.

EthSwt_GetPortMacAddr

Std_ReturnType EthSwt_GetPortMacAddr(
    uint8    SwitchIdx,
    uint8    SwitchPortIdx,
    uint8*   MacAddrPtr
);

Reads the MAC address of a given switch port. This is needed because some switch chips assign a dedicated MAC address per port (e.g. to answer ARP/NDP requests on virtual controllers), while others use a shared base MAC address with a per-port offset.

SwitchIdx addresses the switch chip (for ECUs with multiple switch ICs), SwitchPortIdx the physical port within that chip. The return value is Std_ReturnType — E_OK on success, E_NOT_OK if the port is invalid or the MAC address cannot (yet) be read.

EthSwt_SetPortMode

Std_ReturnType EthSwt_SetPortMode(
    uint8              SwitchIdx,
    uint8              SwitchPortIdx,
    Eth_ModeType       PortMode
);

Sets a port’s operating mode — typically ETH_MODE_DOWN or ETH_MODE_ACTIVE. This allows ports to be selectively disabled, for example to save power when a connected participant isn’t needed, or to isolate a port for security reasons.

EthSwt_SetPortMode controls the logical operating mode of the port within the switch (forwarding active/inactive). The physical link state — whether a cable is even connected and a PHY link has been established — remains the job of the associated EthTrcv_SetTransceiverMode and is queried via EthTrcv_GetLinkState. The two levels need to be considered independently.

Switch Management Concepts in AUTOSAR

Beyond the three API functions, the AUTOSAR EthSwt standard defines a number of management concepts that are driven through ARXML configuration.

Port Configuration

Each switch port is described in ARXML as an EthSwtPortConfig (or an equivalent container, depending on the AUTOSAR release), including:

  • port role: uplink port (toward the SoC) vs. downlink port (toward end devices/sensors),

  • default VLAN membership,

  • prioritization mapping (IEEE 802.1p → switch-internal queues),

  • allowed link speeds (autonegotiation limits).

Forwarding

The switch chip internally maintains a forwarding database (FDB) that maps MAC addresses to ports. AUTOSAR EthSwt allows static FDB entries to be preconfigured via ARXML — for example for safety-relevant communication paths that should not depend on the switch’s dynamic learning behavior.

Dynamic learning:  switch observes the source MAC of incoming frames
                    → automatically enters (MAC, port) into the FDB
                    → timeout removes unused entries (aging)

Static entries:    preconfigured in ARXML
                    → never age out
                    → typical for safety-critical ECU-to-ECU paths

Mirroring

For diagnostics and development, most automotive-grade switch chips support port mirroring: all traffic on one or more source ports is additionally copied to a destination port (mirror port), where an analysis tool (e.g. a Wireshark-capable logging machine) is connected.

In production ECUs, mirroring is usually disabled by default and only enabled via a diagnostic command (UDS Routine Control) or a special debug variant of the ARXML configuration — permanently active mirroring costs bandwidth on the mirror port and is undesirable in field operation.

VLAN Configuration

VLANs (IEEE 802.1Q) are the core mechanism by which a single physical switch represents multiple logically separate networks — for example to keep safety-critical ADAS traffic separate from infotainment traffic even though both run over the same switch chip.

Tagged vs. Untagged Ports

Untagged port (access port):
   Incoming frame without a VLAN tag
   → switch internally assigns it the port VLAN ID (PVID)
   → tag is stripped again on egress (transparent to the end device)

Tagged port (trunk port):
   Incoming frame already carries an 802.1Q tag (VLAN ID in the header)
   → switch forwards based on this VLAN ID
   → tag is preserved on egress
   → typical between two switches or toward the zonal-gateway uplink

An 802.1Q tag adds 4 extra bytes to the Ethernet header:

 Dest MAC | Src MAC | 802.1Q tag (4 bytes) | EtherType | Payload
                       ├─ TPID  (0x8100)
                       ├─ PCP   (3 bits, priority, 802.1p)
                       ├─ DEI   (1 bit)
                       └─ VID   (12 bits, VLAN ID, 1–4094)

VLAN Configuration in ARXML

A simplified, illustrative example of what a VLAN configuration can look like in ARXML (structure loosely modeled on the real EthSwt configuration containers, details vary by vendor):

<ETHERNET-SWITCH-VLAN>
  <SHORT-NAME>VLAN_ADAS</SHORT-NAME>
  <VLAN-IDENTIFIER>100</VLAN-IDENTIFIER>
  <ETHERNET-SWITCH-PORT-VLAN-MEMBERSHIPS>
    <ETHERNET-SWITCH-PORT-VLAN-MEMBERSHIP>
      <ETHERNET-SWITCH-PORT-REF DEST="ETHERNET-SWITCH-PORT">
        /EthSwt/SwitchAsr/Port_Camera_Front
      </ETHERNET-SWITCH-PORT-REF>
      <TAGGING-MODE>UNTAGGED</TAGGING-MODE>
    </ETHERNET-SWITCH-PORT-VLAN-MEMBERSHIP>
    <ETHERNET-SWITCH-PORT-VLAN-MEMBERSHIP>
      <ETHERNET-SWITCH-PORT-REF DEST="ETHERNET-SWITCH-PORT">
        /EthSwt/SwitchAsr/Port_Uplink_Gateway
      </ETHERNET-SWITCH-PORT-REF>
      <TAGGING-MODE>TAGGED</TAGGING-MODE>
    </ETHERNET-SWITCH-PORT-VLAN-MEMBERSHIP>
  </ETHERNET-SWITCH-PORT-VLAN-MEMBERSHIPS>
</ETHERNET-SWITCH-VLAN>

In this example, port Port_Camera_Front belongs to VLAN 100 untagged (the camera itself has no notion of VLANs), while the uplink port to the zonal gateway is tagged — that’s where multiple VLANs run bundled over a single physical link.

ParameterMeaningTypical value

VLAN-IDENTIFIER

Unique VLAN ID within the switch

1–4094 (0 and 4095 reserved)

TAGGING-MODE

Whether the port sees the VLAN tagged or untagged

TAGGED / UNTAGGED

PVID (port VLAN ID)

Default VLAN for untagged incoming frames

Usually identical to the VLAN ID of the primary access VLAN

A port mistakenly configured as TAGGED instead of UNTAGGED lets tagged frames reach an end device that doesn’t expect 802.1Q tags. Many simple sensor/actuator ECUs silently drop such frames — a classic "communication doesn’t work, but no error code" bug.

Interaction with EthIf

For upper software layers, switch ports should look as much as possible like ordinary Ethernet controllers. AUTOSAR achieves this by having EthIf map each relevant switch port to its own virtual controller (EthIfCtrlIdx).

Physical view:                        Logical view (EthIf):

  Switch chip                           EthIf controller 0  → switch port 1
    ├── Port 1 (front camera)           EthIf controller 1  → switch port 2
    ├── Port 2 (rear camera)            EthIf controller 2  → switch port 3
    ├── Port 3 (radar)                  EthIf controller 3  → Eth (SoC uplink)
    └── Port 4 (uplink to SoC)

A socket adaptor or TCP/IP stack instance that wants to receive camera data from port 1 simply configures EthIfCtrlIdx = 0 — whether a "real" MAC controller or a switch port routed through EthSwt sits behind it is invisible to that layer.

This abstraction is a central design advantage of AUTOSAR: an application software module that communicates over a socket doesn’t need to know whether it runs on an ECU with a plain EthTrcv or on a complex zonal gateway with a multi-stage switch. Porting between hardware variants stays a pure configuration change in EthIf/EthSwt.

Spanning Tree & Port States

Once multiple switches in a vehicle network form redundant paths (e.g. ring topologies in zonal architectures meant to keep working even after a cable break), the risk of broadcast loops appears. The standard remedy from the IT world is the Spanning Tree Protocol (STP, IEEE 802.1D) and its faster successors RSTP (802.1w) and MSTP (802.1s).

In automotive ECUs, STP/RSTP is rarely operated fully dynamically — the network topology is usually known and hard-wired at development time. Still, AUTOSAR EthSwt defines the port states that STP implementations (or statically preconfigured equivalents) move through:

DISABLED    → port physically/logically shut down, no traffic
BLOCKING    → port receives STP BPDUs but does not forward payload data
              (prevents loops while the topology is being negotiated)
LISTENING   → transitional state, port starts actively participating in STP
LEARNING    → port learns MAC addresses (FDB build-up), still not forwarding
FORWARDING  → normal operation: port forwards payload data in both directions

With classic STP, the transition from BLOCKING through LISTENING/LEARNING to FORWARDING takes several seconds (forward delay). For automotive use cases that require network availability within milliseconds of power-on, that is often unacceptable. Many automotive switch chips therefore rely on RSTP with rapid transition mechanisms, or forgo dynamic STP entirely in favor of statically configured, loop-free topologies.

Most switch topologies deployed in vehicles are therefore deliberately built loop-free as a tree or star — STP then serves more as a safeguard against misconfiguration or workshop cabling mistakes rather than as an actively used redundancy mechanism during normal operation.

Typical Switch Chips in Practice

A brief, by no means exhaustive overview of automotive-grade switch ICs that show up in AUTOSAR projects with EthSwt integration:

ChipVendorKey facts

SJA1110

NXP

Automotive Ethernet switch with integrated 100BASE-T1/1000BASE-T1 PHYs, TSN support (IEEE 802.1Qbv time-aware shaper), commonly used in zonal gateways

88Q5050

Marvell

Gigabit automotive switch, multiple 1000BASE-T1 ports, SGMII uplink, used in domain/zonal controllers with high camera/LiDAR throughput

RTL9068

Realtek

Automotive switch family focused on cost-efficient multi-port solutions for smaller zonal ECUs

Many of these chips already bring the PHYs for 100BASE-T1/1000BASE-T1 integrated on-die — from an AUTOSAR perspective, that changes nothing about the need to still configure an EthTrcv instance per port. The PHY is merely physically inside the same package as the switch; architecturally the separation between EthSwt (switch logic) and EthTrcv (PHY per port) remains.

The connection to the microcontroller for these chips is usually SPI (for register configuration) combined with SGMII or RGMII (for the data uplink) — MDIO is sometimes used additionally for per-port PHY configuration, even when the switch chip itself is controlled over SPI.

Diagnostics and Monitoring

Switch chips collect extensive per-port statistics — CRC errors, collisions (relevant mainly for legacy half-duplex, rarely relevant in modern automotive networks), dropped frames, broadcast/multicast counters. AUTOSAR feeds this data into diagnostics through two established channels.

DEM — Fault Memory Entries

If an error counter (e.g. the CRC error rate on a port) exceeds a configured threshold, EthSwt reports this as a diagnostic event to the DEM. Typical events include "port link lost" or "excessive frame errors," which then end up in the fault memory via the regular DTC (Diagnostic Trouble Code) mechanism and can be read out via UDS.

DCM — Reading Switch Statistics

Switch-specific data sets — current port states, FDB utilization, or accumulated error counters — can be read out via UDS services, typically Read Data By Identifier (service 0x22). These data sets are mapped to vendor-specific Data Identifiers (DIDs) in the DCM/DEM configuration layer.

Workshop tester
   → UDS ReadDataByIdentifier (DID = switch port statistics)
   → Dcm forwards the request to the EthSwt diagnostic callback
   → EthSwt reads registers from the switch chip (SPI/I2C)
   → statistics are returned as the UDS response

When troubleshooting in the field, port statistics are often more informative than a single DTC: a continuously rising CRC error rate on exactly one port usually points to a PCB or cable problem at that specific connection, whereas a DTC only signals "something with Ethernet."

Summary

TopicKey takeaway

EthSwt vs. EthTrcv

EthSwt manages the switch chip as a whole; EthTrcv stays responsible for the PHY on each port

Architecture

EthIf abstracts switch ports as virtual controllers — upper layers see no difference

API

EthSwt_Init, EthSwt_GetPortMacAddr, EthSwt_SetPortMode form the core

VLANs

802.1Q tagging separates logical networks on one physical switch; tagged/untagged port configuration is error-prone

Spanning tree

Automotive networks are usually statically configured loop-free rather than run dynamically — STP as a safeguard, not an active mechanism

Switch chips

NXP SJA1110, Marvell 88Q5050, and similar chips integrate PHYs but don’t change the EthSwt/EthTrcv separation

Diagnostics

Port statistics via DEM/DCM are often more informative than a single DTC

More on the AUTOSAR Ethernet stack: EthTrcv series