Dieser Post eröffnet die EthTrcv-Serie und baut auf dem
AUTOSAR Grundlagen-Post auf.
Er richtet sich an Software-Entwickler, die im Steuergeräte-Projekt zum ersten Mal
auf EthTrcv treffen — sei es beim Lesen eines ARXML-Splits, beim Debuggen eines
Link-Problems oder schlicht, weil im nächsten Sprint „Ethernet-Anbindung" auf dem Ticket steht.
Bevor es in den weiteren Teilen um API-Aufrufe, Initialisierungssequenzen und
ARXML-Parameter geht, klärt dieser Post die Grundfrage: Was genau ist ein
Ethernet Transceiver, wo sitzt er im AUTOSAR-Stack, und warum gibt es überhaupt
zwei getrennte Treiber (Eth und EthTrcv) für etwas, das auf den ersten Blick
wie eine einzige Aufgabe aussieht?
Was ist ein Ethernet Transceiver?
Der Begriff „Transceiver" ist ein Kofferwort aus Trans*mitter und Re*ceiver — ein Baustein, der senden und empfangen kann. Im Ethernet-Kontext bezeichnet er konkret den PHY-Chip (Physical Layer Device): den Baustein, der zwischen dem digitalen Ethernet-Controller im Mikrocontroller und dem analogen Signal auf dem Kabel vermittelt.
Im OSI-Referenzmodell deckt der PHY exakt Layer 1 ab:
OSI-Layer Aufgabe AUTOSAR-Modul
─────────────────────────────────────────────────────────────────────
Layer 2 (Data Link) Framing, MAC-Adressierung Eth
Layer 1 (Physical) Bit-Übertragung, Leitungscodierung EthTrcv
Line Coding, Auto-Negotiation
Link-Status, EnergiesparmodiDer PHY-Chip übernimmt dabei mehrere konkrete Aufgaben, die für Software-Entwickler oft unsichtbar bleiben, aber jede Übertragung erst möglich machen:
Leitungscodierung — digitale Bitfolgen in ein physikalisches Signal wandeln (z. B. PAM3 bei 100BASE-T1) und umgekehrt
Auto-Negotiation / Link-Aufbau — mit dem PHY am anderen Ende der Leitung Geschwindigkeit und Duplex-Modus aushandeln (bei automotive PHYs meist per fixer Konfiguration statt klassischer Auto-Negotiation)
Link-Status-Überwachung — erkennen, ob überhaupt eine funktionierende Verbindung besteht, und diesen Zustand über MDIO auslesbar machen
Energieverwaltung — Sleep-Modi, WakeUp-Erkennung, Standby — essenziell im Fahrzeug, wo das Steuergerät die meiste Zeit im Ruhezustand verbringt
Signalaufbereitung — Entzerrung, Rauschunterdrückung, Echo-Cancellation bei bidirektionalen Single-Pair-Leitungen
Ein PHY-Chip ist reine Hardware — ein eigenständiger IC oder ein IP-Block, der in
den Mikrocontroller integriert sein kann. |
Wichtig ist die Abgrenzung zum Ethernet-Controller (MAC — Media Access Control), der auf Layer 2 sitzt und Frames zusammensetzt, Adressen prüft und Prüfsummen bildet. Der MAC „spricht" nicht direkt mit dem Kabel — er reicht seine Bits über ein digitales Parallel- oder Seriellinterface (MII, RMII, RGMII, SGMII) an den PHY weiter. Dieses Zusammenspiel ist der Kern der nächsten Abschnitte.
Einordnung im AUTOSAR Layered Architecture Model
AUTOSAR Classic Platform organisiert die Basissoftware in klar getrennten Schichten. Für die Ethernet-Kommunikation sind drei Module relevant, die zusammen den kompletten Layer-1/Layer-2-Zugriff abbilden:
┌─────────────────────────────┐
│ Communication Services │
│ (SoAd, TcpIp, ...) │
└──────────────┬────────────────┘
│
┌──────────────▼────────────────┐
│ EthIf │
│ (Ethernet Interface Modul) │
│ State-Handling, Multiplexing, │
│ einheitliche API nach oben │
└────────┬─────────────┬──────────┘
│ │
┌───────────────▼──┐ ┌────▼────────────────┐
│ Eth │ │ EthTrcv │
│ (Controller Driver) │ │ (Transceiver Driver) │
│ Frame-TX/RX, │ │ PHY-Konfiguration, │
│ Deskriptoren, │ │ Link-Status, │
│ Interrupts │ │ WakeUp, MDIO-Zugriff │
└───────────┬─────────┘ └──────────┬─────────────┘
│ │
┌───────▼────────┐ ┌────────▼────────┐
│ Eth-Controller │ │ PHY-Chip │
│ (im MCU/SoC) │◄─MII/────►│ (externer IC │
│ │ RGMII │ oder IP-Block) │
└──────────────────┘ └───────┬──────────┘
│ MDIO
(Steuerbus zwischen
Eth und EthTrcv,
nicht im Bild —
siehe Hardware-Post)EthIf bildet die vereinheitlichende Schicht darüber: Es kennt sowohl Eth
als auch EthTrcv, bündelt deren Zustände zu einem konsistenten Bild
(„ist der Kanal betriebsbereit?") und stellt den darüberliegenden Modulen
(allen voran TcpIp über SoAd) eine einzige, hardwareunabhängige API bereit.
Ohne EthIf müsste jedes höhere Modul wissen, welcher konkrete Eth- und
EthTrcv-Treiber im Steuergerät verbaut ist — genau das soll die
AUTOSAR-Schichtenarchitektur verhindern.
Eine nützliche Eselsbrücke: |
Abgrenzung: Eth vs. EthTrcv vs. EthIf — wer macht was?
In der Praxis ist die Verwechslung dieser drei Module einer der häufigsten Stolpersteine für Neueinsteiger. Die folgende Tabelle stellt Zuständigkeiten, typische API-Aufrufe und die jeweilige Blickrichtung gegenüber.
| Modul | Zuständigkeit | Typische Aufgaben | Blickrichtung |
|---|---|---|---|
Eth (Ethernet Driver) | Ansteuerung des MAC-Controllers im Mikrocontroller | Frame senden/empfangen, Deskriptor-Ringe verwalten, Interrupts behandeln, Statistikzähler führen | „Nach innen" — auf die MAC-Hardware im SoC |
EthTrcv (Ethernet Transceiver Driver) | Ansteuerung des PHY-Chips über MDIO | PHY initialisieren, Link-Status abfragen, Modus wechseln (Active/Sleep), WakeUp erkennen | „Nach außen" — auf den PHY-Chip und die Leitung |
EthIf (Ethernet Interface) | Vereinheitlichung von Eth und EthTrcv für obere Schichten | Zustände konsolidieren, Controller-Indizes auf Treiber-Instanzen abbilden, TX/RX-API weiterreichen | „Nach oben" — auf TcpIp/SoAd und andere BSW-Module |
PHY-Chip (Hardware, kein AUTOSAR-Modul) | Physikalische Signalumsetzung | Leitungscodierung, Auto-Negotiation, Signalaufbereitung | Reine Hardware — wird von EthTrcv via MDIO angesprochen |
Ein konkretes Beispiel macht den Unterschied greifbar: Wenn ein Steuergerät
aus dem Sleep aufwacht, weil auf der Ethernet-Leitung ein WakeUp-Impuls anliegt,
dann ist es EthTrcv, das diesen Zustand über EthTrcv_CheckWakeup erkennt und
nach oben meldet. Eth hat mit diesem Vorgang nichts zu tun — der MAC-Controller
ist zu diesem Zeitpunkt oft noch gar nicht initialisiert. Umgekehrt: Wenn ein
Frame mit fehlerhafter Prüfsumme verworfen wird, ist das ausschließlich Sache
von Eth — EthTrcv bekommt davon nichts mit, weil es nur bis Layer 1 reicht.
|
Typische PHY-Chips in der Praxis
Automotive-Ethernet-PHYs unterscheiden sich deutlich von Consumer-PHYs (wie sie in Routern oder PCs verbaut werden). Sie müssen den erweiterten Temperaturbereich (typisch −40 °C bis +125 °C bzw. +150 °C je nach Grade), AEC-Q100-Qualifikation und EMV-Anforderungen im Fahrzeug erfüllen — und sie sprechen fast ausschließlich Single-Pair-Standards, weil im Kabelbaum jedes zusätzliche Aderpaar Gewicht und Kosten bedeutet.
100BASE-T1
Der heute verbreitetste Automotive-Ethernet-Standard (ursprünglich unter dem Namen „OABR" bzw. BroadR-Reach von Broadcom entwickelt, seit 2015 als IEEE 802.3bw standardisiert). 100 Mbit/s über ein einziges verdrilltes Aderpaar, bidirektional durch Echo-Cancellation im PHY. Details zur Signalcodierung (PAM3) und zum genauen PCB-seitigen Aufbau behandelt der separate Hardware-Deep-Dive dieser Serie.
Typische Einsatzgebiete: Kamera-Anbindung, Sensoren, einfache Steuergeräte in der Peripherie eines Zonal- oder Domain-Controllers.
1000BASE-T1
Gleiche Grundidee wie 100BASE-T1, aber mit 1 Gbit/s über ein Single-Pair-Kabel (IEEE 802.3bp, standardisiert 2016). Höhere Symbolrate, kürzere maximale Kabellänge, aber ausreichend Bandbreite für Backbone-Verbindungen zwischen Zonal Controllern, Domain Controllern und zentralen Gateways — genau dort, wo in einer zonalen Fahrzeugarchitektur große Datenmengen (Kamera-Rohdaten, Sensor-Fusion, Diagnose-Traffic) gebündelt werden.
Beispiel-Chips
| Hersteller / Chip | Standard | Interface (MAC-seitig) | Bemerkung |
|---|---|---|---|
NXP TJA1100 | 100BASE-T1 | RMII | Weit verbreiteter „Klassiker" in vielen Serienfahrzeugen, einer der ersten in Großserie eingesetzten 100BASE-T1-PHYs |
NXP TJA1101 | 100BASE-T1 | RMII | Nachfolger/Variante des TJA1100 mit erweiterten Diagnosefunktionen |
Marvell 88Q2112 | 1000BASE-T1 | RGMII | Gängiger 1000BASE-T1-PHY für Backbone- und Gateway-Anwendungen |
Broadcom BCM89811 | 1000BASE-T1 | RGMII | Alternative für Gigabit-Anwendungen, teils mit integriertem Switch-Portfolio kombiniert |
Marvell 88Q2110 / 88Q2220 | 100BASE-T1 / Multi-Gig | RMII / RGMII / SGMII | Produktfamilie mit mehreren Geschwindigkeitsstufen, je nach Variante |
Der genaue PHY-Chip ist für den |
Wichtig für die Software-Seite: Der konkrete Chip bestimmt zwar die MDIO-Registerbelegung im Treiber, aber die AUTOSAR-API bleibt über alle Chips hinweg identisch. Das ist der ganze Sinn der Abstraktionsschicht — Teil 2 dieser Serie zeigt genau diese API im Detail.
Überblick über die Serie
Dieser Post legt das Fundament. Die folgenden Teile bauen darauf auf und gehen jeweils in die Tiefe eines Teilaspekts:
| Teil | Thema |
|---|---|
1 (dieser Post) | Grundlagen & Einordnung — was ist ein Transceiver, wo sitzt EthTrcv im Stack, welche PHY-Chips gibt es |
Die konkreten AUTOSAR-Funktionsaufrufe, der Ablauf von | |
Die Konfigurationscontainer im Detail — | |
WakeUp-Erkennung, Zusammenspiel mit |
Wer zusätzlich verstehen möchte, was auf PCB-Ebene passiert — MDIO-Bus, MAC-seitige Interfaces wie RGMII, Steckverbinder, EMV — findet das im separaten EthTrcv Hardware Deep Dive, der die Serie thematisch ergänzt, aber keinen der nummerierten Teile ersetzt.
Zusammenfassung
| Aspekt | Kernaussage |
|---|---|
Ethernet Transceiver | PHY-Chip, deckt OSI Layer 1 ab — Leitungscodierung, Link-Status, Energieverwaltung |
Einordnung im Stack |
|
Eth vs. EthTrcv vs. EthIf | Eth = Frames (Layer 2), EthTrcv = Leitung (Layer 1), EthIf = Vereinheitlichung nach oben |
PHY-Chips in der Praxis | 100BASE-T1 (z. B. NXP TJA1100/TJA1101) für Peripherie, 1000BASE-T1 (z. B. Marvell 88Q2112) für Backbone-Verbindungen |
Nächster Schritt | Teil 2 zeigt die konkrete API und Initialisierungssequenz von |
Weiter in der EthTrcv-Serie: EthTrcv Teil 2 — API & Initialisierungssequenz