This post was revised after fact-checking it against the real SWS EthSwt (see correction issue #145): a generic AUTOSAR configuration channel over frames with a special EtherType does not exist. What the SWS actually offers under "Switch Management Support" (chapter 7.1.7.3) is something different — this post clearly separates the two.

The still-relevant vendor concept is described further below, but explicitly labeled as not AUTOSAR-standardized.

What AUTOSAR actually offers: port-specific frame handling

Under EthSwtManagementSupportApi, the SWS defines a group of APIs (EthSwt_EthRxProcessFrame, EthSwt_EthTxPrepareFrame, EthSwt_SetMgmtInfo, EthSwt_EthTxProcessFrame, EthSwt_EthTxFinishedIndication) that let EthIf set or read switch-port-specific communication attributes of a frame. The central one is EthSwt_SetMgmtInfo:

Std_ReturnType EthSwt_SetMgmtInfo(
    uint8                       CtrlIdx,
    Eth_BufIdxType              BufIdx,
    const EthSwt_MgmtInfoType*  MgmtInfoPtr   // { SwitchIdx, SwitchPortIdx }
);

Per the SWS, this call extends an Ethernet frame previously prepared with EthSwt_EthTxPrepareFrame with management information, "to achieve transmission only on specific ports" — the use case is therefore targeted transmission over a specific switch port, not transmitting arbitrary configuration commands to the switch itself.

Per the introduction to chapter 7.1.7.3, this functionality is "essential for other BSW modules, in particular EthTSyn" — it provides port-specific information for time-synchronization or path-delay measurement frames (gPTP). More on this in this series' Global Time post.

The vendor concept: in-band management over the host port

Independent of the AUTOSAR abstraction, some switch chip families implement their own mechanism: instead of using SPI or MDIO as a separate bus, configuration commands are sent as regular Ethernet frames carrying a reserved, chip-specific EtherType directly over the switch’s host port.

Host-side frame with a vendor EtherType
──────────────────────────────────────────────────────────────
| Dest MAC | Src MAC | EtherType (vendor-reserved) | Payload: command |
──────────────────────────────────────────────────────────────
Recognized by the switch chip itself and not forwarded/switched like
regular traffic.

Advantages:

  • No additional pins/buses (SPI, MDIO) needed

  • Configuration over the same physical link as the payload traffic

Disadvantages / chicken-and-egg problem:

  • The host port must already be linked before it can configure itself

  • A sensible default state after reset is mandatory, otherwise the switch is completely unreachable after boot

Per common vendor practice, such management frames must not be forwarded over regular switch ports — otherwise any device attached to the vehicle network could reconfigure the switch. Filtering (usually port isolation or VLAN separation for management traffic) is a security prerequisite, not an optional feature.

Interaction with AUTOSAR

Such a vendor-specific mechanism is not a standard EthSwt API — it’s typically implemented as an extension outside the AUTOSAR interface in the chip vendor’s driver, and must be strictly distinguished from EthSwt_SetMgmtInfo (see above).

Real-world example

Switch chip families such as the NXP SJA1105 series offer such a mechanism for initial configuration over the host port, before a full SPI- or ARXML-based configuration is even loaded — relevant e.g. for an initial firmware-update scenario where the switch doesn’t yet have a working VLAN configuration.

Summary

AspectKey takeaway

AUTOSAR standard

EthSwt_SetMgmtInfo & co. serve port-specific frame handling (especially for EthTSyn/gPTP), not switch configuration

Vendor mechanism

Some chips allow configuration via frames with a reserved EtherType over the host port — not AUTOSAR-standardized

Security aspect

Management frames must not be forwarded over regular ports

See also

This series' Global Time post for the correct role of EthSwt_SetMgmtInfo