Dieser Post ist Teil der EthTrcv-Serie und baut auf dem vorherigen Post zu MACsec auf. Er richtet sich an alle, die ein bestehendes Steuergerät oder ein neues Projekt von klassischem 100BASE-TX-Ethernet auf automotive 100BASE-T1 migrieren — und die genau wissen wollen, was sich dabei auf Hardware-, Treiber- und Konfigurationsebene ändert.

Die kurze Antwort: mehr, als der ähnliche Name vermuten lässt. 100BASE-TX und 100BASE-T1 teilen sich die Bitrate und den Namen "100BASE", aber auf der Leitung, im PHY und in der ARXML-Konfiguration sind es zwei grundverschiedene Welten. Wer eine TX-Konfiguration nimmt und nur den PHY-Treiber austauscht, wird spätestens beim ersten Link-Up-Versuch im Fahrzeugaufbau überrascht.

Warum 100BASE-T1?

Bevor es an die Technik geht, lohnt sich die Frage nach dem "Warum". 100BASE-TX funktioniert im Fahrzeug schließlich auch — zumindest im Labor und auf dem Prüfstand.

Gewicht und Bauraum: 100BASE-TX benötigt zwei verdrillte Aderpaare (TX und RX getrennt), 100BASE-T1 kommt mit einem einzigen Aderpaar aus. Bei einem modernen Fahrzeug mit dutzenden Ethernet-Verbindungen zwischen Zonal Controllern, Kameras und Domain Controllern summiert sich das zu mehreren Kilogramm Kabelbaum-Gewicht — und Kabelbaum ist nach der Batterie oft die schwerste Einzelkomponente im Fahrzeug.

Kosten: Weniger Adern bedeuten weniger Kupfer, dünnere Kabelbäume, kleinere Steckverbinder und weniger Crimp-Kontakte in der Fertigung. Bei Stückzahlen im sechsstelligen Bereich pro Baureihe ist das ein messbarer Kostenfaktor — nicht nur Materialkosten, sondern auch Montagezeit am Band.

Kabelbaum-Vereinfachung: Ein Single-Pair-Kabel lässt sich einfacher routen, biegen und in bestehende Kabelbaum-Bündel integrieren als ein Vierdraht-Kabel mit RJ45-artigem Steckverbinder. Das reduziert nicht nur Gewicht, sondern auch die Komplexität der Kabelbaum-Topologie und die Anzahl möglicher Fehlerquellen bei der Montage.

EMV-Verhalten im Fahrzeug: 100BASE-T1 ist von Grund auf für den automotive EMV-Kontext entwickelt worden — ungeschirmte Twisted-Pair-Kabel (UTP), die neben Zündanlagen, Elektromotoren und DC/DC-Wandlern bestehen müssen. 100BASE-TX-Komponenten sind für Büroumgebungen ausgelegt und erfüllen automotive EMV-Anforderungen oft nur mit zusätzlichem Schirmungsaufwand.

100BASE-T1 wurde 2015 als IEEE 802.3bw standardisiert — mit dem expliziten Ziel, ein automotive-taugliches 100-Mbit/s-Interface über ein einziges ungeschirmtes Aderpaar bereitzustellen. Es ist kein Zufall, dass die Automobilindustrie an der Standardisierung maßgeblich beteiligt war.

Technische Unterschiede

Der Name "100BASE" suggeriert Verwandtschaft, aber auf physikalischer Ebene haben TX und T1 wenig gemeinsam.

Leitungscodierung: MLT-3 vs. PAM3

100BASE-TX verwendet MLT-3 (Multi-Level Transmit-3) auf zwei getrennten Adernpaaren — eines pro Richtung. Da Senden und Empfangen physikalisch getrennt sind, braucht der PHY keine Echo-Cancellation.

100BASE-T1 verwendet PAM3 (Pulse Amplitude Modulation, 3 Pegel) auf einem einzigen Adernpaar, bidirektional. Sende- und Empfangssignal überlagern sich auf derselben Leitung — der PHY muss sein eigenes Sendesignal per adaptivem Filter herausrechnen, um das Empfangssignal zu isolieren.

100BASE-TX (MLT-3, unidirektional pro Paar):

  TX-Paar:  Sender ──[TX+/TX-]──► Empfänger      (nur eine Richtung)
  RX-Paar:  Empfänger ◄──[RX+/RX-]── Sender       (nur eine Richtung)

  Kein Echo-Cancellation nötig, da Senden/Empfangen getrennt sind.


100BASE-T1 (PAM3, bidirektional auf einem Paar):

  Paar:     Knoten A ◄──[T1+/T1-]──► Knoten B     (beide Richtungen gleichzeitig)

  Echo-Cancellation zwingend erforderlich —
  jeder Teilnehmer muss sein eigenes Sendesignal
  vom Summensignal auf der Leitung subtrahieren.

Das hat direkte Konsequenzen für den PHY-Chip: ein 100BASE-T1-PHY ist intern deutlich komplexer als ein 100BASE-TX-PHY, weil er einen adaptiven Echo-Canceller, einen Near-End-Crosstalk-Filter und ein Trellis-codiertes PAM3-Encoding realisieren muss, wo TX mit einfachem 4B5B-Encoding und MLT-3 auskommt.

Keine Auto-Negotiation

100BASE-TX kennt Auto-Negotiation nach IEEE 802.3 Clause 28 — zwei verbundene Ports handeln automatisch Geschwindigkeit und Duplex-Modus aus, indem sie Fast-Link-Pulse-Bursts austauschen.

100BASE-T1 hat keine Auto-Negotiation im klassischen Sinn. Es gibt nur eine Geschwindigkeit (100 Mbit/s) und nur Vollduplex — insofern wäre Auto-Negotiation auch wenig sinnvoll. Was es stattdessen zwingend braucht, ist eine statische Master/Slave-Rollenzuweisung, die vor Inbetriebnahme feststehen muss.

Ohne Auto-Negotiation gibt es auch keinen automatischen Fallback, wenn zwei Ports falsch konfiguriert sind. Zwei 100BASE-T1-PHYs, die beide als Master konfiguriert sind, bauen schlicht keinen Link auf — und das Fehlerbild sieht auf den ersten Blick aus wie ein Kabel- oder Steckerproblem.

Master/Slave zwingend

Da es keine Auto-Negotiation gibt, muss bei jeder 100BASE-T1-Verbindung exakt eine Seite als Master (gibt den Takt vor) und die andere als Slave (synchronisiert sich auf den Master-Takt) konfiguriert sein. Diese Rolle wird bei der Systemauslegung festgelegt und im ARXML hinterlegt — sie ändert sich zur Laufzeit nicht automatisch.

Details zur Konfiguration, den relevanten ARXML-Parametern und typischen Topologie-Entscheidungen (z. B. Gateway immer Master, Endpunkte immer Slave) behandelt der dedizierte Master/Slave-Post in dieser Serie ausführlich.

Kein Power over Ethernet (klassisch)

100BASE-TX kennt PoE (Power over Ethernet, IEEE 802.3af/at) für Büroanwendungen wie IP-Telefone oder Access Points. 100BASE-T1 kennt kein PoE in diesem Sinne — stattdessen gibt es PoDL (Power over Data Line, IEEE 802.3bu), ein separates, automotive-spezifisches Konzept mit eigenen Spannungsklassen. In den meisten Fahrzeug-Topologien wird PoDL bislang aber kaum genutzt, da Steuergeräte ohnehin über die KL30/KL15-Bordnetzversorgung mit Energie versorgt werden.

Vergleichstabelle

Merkmal100BASE-TX100BASE-T1

Adernpaare

2 (TX + RX getrennt)

1 (bidirektional)

Leitungscodierung

MLT-3 (3 Pegel, unidirektional pro Paar)

PAM3 (3 Pegel, bidirektional, Trellis-codiert)

Symbolrate

125 MBaud

66,67 MBaud

Auto-Negotiation

Ja (IEEE 802.3 Clause 28)

Nein

Master/Slave

Nicht relevant

Zwingend, statisch konfiguriert

Echo-Cancellation

Nicht nötig

Zwingend erforderlich

Steckverbinder

RJ45-artig, 8P8C

HSD, MATEnet, H-MTD (automotive)

Kabellänge

bis 100 m (Cat5e)

bis 15 m Standard, bis 40 m reduziert

Power-Konzept

PoE (802.3af/at), Büroumfeld

PoDL (802.3bu), selten genutzt im Fahrzeug

EMV-Auslegung

Büroumgebung

Automotive-EMV (Zündanlage, DC/DC-Wandler)

Clause (MDIO)

Meist Clause 22

Häufig Clause 45 (insbesondere bei Diagnose-Features)

Was sich im AUTOSAR-Stack ändert

Aus Sicht der Anwendungssoftware sieht das Ethernet erst mal gleich aus — Frames, IP-Pakete, SOME/IP-Services. Aber unterhalb von EthIf ändert sich einiges.

Neuer EthTrcv-Treiber

Der offensichtlichste Punkt: 100BASE-T1 wird von einem anderen PHY-Chip realisiert als 100BASE-TX, und jeder PHY-Chip braucht seinen eigenen EthTrcv-Treiber (BSW-Modul, MCAL-nah, vom Halbleiterhersteller oder Tier-1 geliefert).

100BASE-TX-Setup:
  EthIf → EthTrcv_TX_Driver → PHY-Chip (z. B. Broadcom BCM5241, Microchip LAN8710)

100BASE-T1-Setup:
  EthIf → EthTrcv_T1_Driver → PHY-Chip (z. B. Marvell 88Q2110, TJA1101, DP83TC811)

Die EthTrcv-API selbst (EthTrcv_Init, EthTrcv_GetLinkState, EthTrcv_SetTransceiverMode, …​) bleibt nach oben stabil — das ist der ganze Sinn der AUTOSAR-Schichtenarchitektur. Aber die Treiberimplementierung darunter ist komplett neu: andere Register-Maps, andere Init-Sequenzen, andere Timing-Anforderungen beim Power-Up.

Der neue Treiber ist in der Regel kein Software-Update eines bestehenden Moduls, sondern eine komplette Neu-Integration. Das bedeutet: neue MCAL-Qualifikation, neue Treiber-Tests, neue Lieferantenbeziehung, wenn der bisherige PHY-Lieferant kein 100BASE-T1-Portfolio hat.

Master/Slave-Konfiguration

Wie oben beschrieben, ersetzt die statische Master/Slave-Zuweisung die Auto-Negotiation. Im AUTOSAR-Stack äußert sich das durch einen neuen ARXML-Parameter (herstellerspezifisch meist unter EthTrcvConfigSet oder als Vendor-Specific-Parameter modelliert), der bei 100BASE-TX schlicht nicht existierte, weil er nicht gebraucht wurde.

Die vollständige Behandlung dieses Themas — inklusive typischer Topologie-Muster und Fehlerbilder bei Fehlkonfiguration — findet sich im Master/Slave-Post dieser Serie. An dieser Stelle nur so viel: Master/Slave ist keine Software-Konvention, sondern eine physikalische Notwendigkeit für die Taktsynchronisation des PAM3-Signals — und ein reiner ARXML-Parameter, der nicht zur realen Verkabelung passt, führt zu einem Link, der nie hochkommt.

WakeUp-Mechanismus unterscheidet sich

Bei 100BASE-TX-PHYs ist Energy-Detect ein verbreiteter WakeUp-Mechanismus: der PHY erkennt allein durch das Vorhandensein von Signalenergie auf der Leitung, dass ein Link-Partner aktiv ist, und kann daraus ein WakeUp-Ereignis ableiten.

100BASE-T1-PHYs nutzen stattdessen überwiegend einen dedizierten WakeUp-Puls — ein definiertes Signalmuster (in der Praxis oft an die IEEE-802.3bp/bw-WakeUp-Spezifikation angelehnt oder herstellerspezifisch), das ein sendender Knoten aktiv erzeugt, um einen schlafenden Knoten aufzuwecken. Energy-Detect allein reicht bei 100BASE-T1 nicht zuverlässig, weil auf der Leitung durch Rauschen und Reflexionen leichter Fehlinterpretationen entstehen können als bei einem klar definierten Pulsmuster.

100BASE-TX — Energy-Detect (vereinfacht):
  Leitung inaktiv → Signalenergie erscheint → PHY interpretiert als WakeUp-Kandidat
  → EthTrcv_CheckWakeup meldet Ereignis

100BASE-T1 — WakeUp-Puls (vereinfacht):
  Leitung inaktiv → sendender Knoten erzeugt definierten WakeUp-Puls
  → empfangender PHY erkennt Pulsmuster (nicht nur "Energie da")
  → EthTrcv_CheckWakeup meldet Ereignis

Das ist für den AUTOSAR-Software-Entwickler keine rein akademische Unterscheidung: die ARXML-Parameter zur WakeUp-Konfiguration (z. B. Aktivierung, Debounce-Zeiten, Polarität) unterscheiden sich zwischen den Treibern, und wer die TX-Konfiguration unverändert übernimmt, konfiguriert häufig einen WakeUp-Mechanismus, den der neue PHY gar nicht anbietet.

Ein besonders tückischer Fehler: die Konfiguration kompiliert, das System läuft im Labor mit Dauerstrom einwandfrei — und erst im Feldtest, wenn das Steuergerät regulär in den Sleep geht, zeigt sich, dass WakeUp-over-Ethernet nicht funktioniert. Dieser Pfad wird im Dauerbetrieb am Prüfstand oft gar nicht durchlaufen.

ARXML-Konfiguration: andere Parameter, andere Vendor Extensions

Über die bereits genannten Punkte hinaus unterscheidet sich die ARXML-Konfiguration in mehreren Details:

  • Interface-Typ (MII/RMII/RGMII): 100BASE-T1-PHYs werden häufiger über RGMII statt über MII/RMII angebunden, insbesondere in Kombination mit 1000BASE-T1-fähigen Chips, die im 100-Mbit/s-Modus betrieben werden. Welche dieser Varianten zum Einsatz kommt, ist implizit über die konkrete Hardware- und Treiberanbindung festgelegt und nicht als eigenes ARXML-Enum wählbar.

  • PHY-Testmodi (EthTrcv_SetPhyTestMode): 100BASE-T1-PHYs bringen herstellerspezifische Testmodi (z. B. für die IEEE-802.3bw-konforme Sendeleistungsmessung) mit, die über EthTrcv_PhyTestModeType bzw. Vendor-Specific-ARXML-Parameter modelliert werden und bei TX-PHYs anders oder gar nicht existieren.

  • Clause-45-Register-Maps: Viele 100BASE-T1-PHYs (insbesondere mit Diagnosefunktionen wie Kabellängenmessung oder Link-Qualitäts-Monitoring) nutzen MDIO Clause 45 statt Clause 22 — das betrifft nicht nur den Treiber, sondern auch, wie der MAC-Treiber MDIO-Zugriffe absetzt.

  • Vendor Extensions: Jeder PHY-Hersteller bringt eigene ARXML-Vendor- Extension-Pakete für Register-Level-Konfiguration (z. B. Filter- Einstellungen für Echo-Cancellation, EMV-Tuning-Register). Diese Pakete sind PHY-spezifisch und nicht zwischen TX- und T1-Chips übertragbar, selbst wenn beide vom gleichen Hersteller stammen.

Es lohnt sich, frühzeitig ein ARXML-Diff zwischen der bestehenden TX-Konfiguration und einer Referenzkonfiguration des neuen T1-PHY- Herstellers zu erstellen — nicht um Werte zu übernehmen, sondern um systematisch zu sehen, welche Parameter überhaupt neu hinzukommen. Das verhindert, dass Parameter "vergessen" statt bewusst weggelassen werden.

Was gleich bleibt

Nach so vielen Unterschieden lohnt sich der Blick auf das, was die Migration handhabbar macht: Die AUTOSAR-Schichtenarchitektur tut genau das, wofür sie gedacht ist.

Anwendung / SOME-IP / DoIP / ...
        │
        ▼
     Socket Adaptor / TCP-IP-Stack        ── unverändert
        │
        ▼
       EthIf                              ── unverändert
        │
        ▼
  Eth-Controller-Driver (MAC)             ── unverändert*
        │
        ▼
      EthTrcv                             ── NEU (anderer PHY-Treiber)
        │
        ▼
      PHY-Chip                            ── NEU (anderer Chip)
        │
        ▼
      Kabel / MDI                         ── NEU (Single-Pair statt Dual-Pair)

  • Der Eth-Controller-Driver (MAC-Treiber im SoC) bleibt in aller Regel unverändert, solange das MAC-seitige Interface (z. B. RGMII) gleich bleibt. Ändert sich dabei auch das Interface (etwa von RMII auf RGMII, weil der neue PHY das verlangt), ist auch hier eine Anpassung nötig — das ist aber ein Nebeneffekt der PHY-Wahl, kein grundsätzliches Merkmal der T1-Migration.

Konkret bleiben unverändert:

  • EthIf — die Abstraktionsschicht über mehreren EthTrcv/Eth-Instanzen kennt die Details der Leitungscodierung nicht und muss nicht angepasst werden.

  • TCP/IP-Stack — IP-Adressierung, ARP, TCP/UDP-Verhalten sind auf Layer 3/4 komplett unabhängig vom physikalischen Layer 1.

  • SOME/IP, DoIP, DDS und andere Kommunikationsdienste — sehen nur Sockets, keine PHY-Details.

  • Diagnose-Stack (Dcm, Dem) — solange DoIP über die gleiche logische Adressierung läuft, ist die physikalische Anbindung transparent.

  • EcuM/BswM-Zustandsautomaten — die grundsätzliche Logik für Sleep/Wakeup-Handling bleibt gleich, auch wenn die konkreten WakeUp-Bedingungen sich ändern (siehe oben).

Das ist die eigentlich gute Nachricht dieser Migration: sie ist ein Austausch auf Layer 1/2, kein Redesign der gesamten Kommunikationsarchitektur.

Typische Migrationsfehler

Aus wiederkehrenden Projekterfahrungen — die folgenden Fehler tauchen in nahezu jeder TX-zu-T1-Migration in irgendeiner Form auf.

Master/Slave-Konflikt

Der klassiker: beide Seiten einer Verbindung sind als Master (oder beide als Slave) konfiguriert. Da 100BASE-T1 keine Auto-Negotiation kennt, gibt es keinen automatischen Fallback — der Link kommt einfach nicht hoch.

Das Fehlerbild ist auf den ersten Blick nicht von einem defekten Kabel oder einem falsch bestückten Steckverbinder zu unterscheiden. Wer bei "Link kommt nicht hoch" reflexartig zum Kabeltester greift, statt zuerst die Master/Slave-Konfiguration beider Seiten zu prüfen, verliert wertvolle Debugging-Zeit.

Häufige Ursache: bei komplexen Topologien mit mehreren Steuergeräten wird die Master/Slave-Zuweisung in einer Tabelle gepflegt, die nicht konsistent mit dem tatsächlichen ARXML jedes einzelnen Steuergeräts abgeglichen wird. Ein Steuergerät wird ausgetauscht oder neu programmiert — und bekommt versehentlich die falsche Rolle.

Falsche Impedanzanpassung

100BASE-T1 verlangt eine Leitungsimpedanz von 100 Ω (±15 %) und ein sorgfältiges Differential-Pair-Matching auf dem PCB. Wird beim Hardware-Redesign (neues PCB-Layout für den neuen PHY) die Impedanzanpassung nicht neu berechnet — etwa weil Layout-Regeln vom TX-Design unreflektiert übernommen werden — entstehen Reflexionen auf der Leitung.

Symptome sind selten ein kompletter Link-Ausfall, sondern:

  • Sporadische CRC-Fehler bei bestimmten Kabellängen oder -biegungen

  • Reduzierte maximale Kabellänge gegenüber der Spezifikation

  • Link-Instabilität bei Vibration oder Temperaturwechsel im Fahrzeug

Diese Fehlerklasse ist besonders unangenehm, weil sie in der funktionalen Prüfung am Labortisch (kurzes Kabel, stabile Temperatur) oft unentdeckt bleibt und erst im Fahrzeug-Dauertest oder im Feld auffällt.

WakeUp nicht konfiguriert

Wie im Abschnitt zum WakeUp-Mechanismus beschrieben: wird die TX-Konfiguration unverändert übernommen, bleibt der WakeUp-Mechanismus entweder deaktiviert oder auf einen Modus eingestellt, den der neue PHY nicht unterstützt. Das System funktioniert im Dauerbetrieb einwandfrei — der Fehler zeigt sich erst, wenn das Steuergerät den regulären Sleep/WakeUp-Zyklus durchläuft.

Weitere häufige Stolperfallen

FehlerAuswirkung

MDIO Clause falsch angenommen

Register-Zugriffe schlagen fehl oder liefern falsche Werte, EthTrcv_Init erkennt den PHY nicht

Alter Steckverbinder-Footprint übernommen

Mechanische Inkompatibilität, im schlimmsten Fall unbemerkte falsche Kontaktierung

Kabellänge nicht neu bewertet

100BASE-T1-Spezifikation (15 m Standard) ist restriktiver als viele TX-Installationen

EMV-Filter (CMF) vom TX-Design übernommen

Falsch dimensionierter Common-Mode-Filter für die neue PHY-Charakteristik

Diagnose-Timing nicht angepasst

Link-Erkennungszeiten unterscheiden sich zwischen TX und T1, DoIP-Timeouts ggf. zu knapp

Testempfehlungen

Vor dem ersten Aufbau im realen Fahrzeug sollten folgende Punkte verifiziert sein — idealerweise in dieser Reihenfolge, vom Labor zum Fahrzeug.

Auf dem Labortisch

  • Link-Up-Test mit kurzem Referenzkabel: Master/Slave-Rollen gegeneinander prüfen — funktioniert der Link mit der geplanten Konfiguration, und bricht er kontrolliert ab (nicht "irgendwie halb"), wenn beide Seiten die gleiche Rolle bekommen?

  • Register-Dump nach Init: Über MDIO alle relevanten PHY-Register auslesen und mit dem erwarteten Zustand aus dem Datenblatt vergleichen. Ein PHY, der falsch initialisiert wurde, meldet oft trotzdem "Link Up", verhält sich aber unter Last fehlerhaft.

  • Kabellängen-Grenztest: Mit dem längsten spezifizierten Kabel (15 m Standard, ggf. 40 m im reduzierten Modus) den Link-Aufbau und die Bitfehlerrate prüfen — nicht nur mit dem bequemen 1-m-Laborkabel.

Signalqualität

  • Augendiagramm-Messung (Eye Diagram): Zeigt, ob das PAM3-Signal sauber zwischen den drei Pegeln unterscheidbar ist. Ein "geschlossenes" Auge deutet auf Impedanzprobleme, schlechtes Cable-Matching oder einen fehlerhaften Echo-Canceller hin.

  • Return-Loss-Messung: Prüft die Impedanzanpassung über den relevanten Frequenzbereich. Abweichungen von der 100-Ω-Spezifikation zeigen sich hier, bevor sie im Feld als sporadische Fehler auftauchen.

  • EMV-Vormessung: Eine reduzierte EMV-Messung (Abstrahlung, Störfestigkeit) vor der vollständigen Fahrzeugintegration erkennt grobe Layout-Fehler frühzeitig, bevor teure Prüfstandszeit im akkreditierten EMV-Labor gebucht wird.

WakeUp und Sleep

  • Vollständiger Sleep/WakeUp-Zyklus: Steuergerät regulär in den Sleep schicken lassen (nicht nur Power-Cycle) und über den WakeUp-Puls vom Partner-Steuergerät aufwecken. Dieser Test wird in der Praxis überraschend oft ausgelassen, weil er im Entwicklungsalltag unbequem ist.

  • WakeUp-Timing-Messung: Zeit von WakeUp-Puls bis EthTrcv_CheckWakeup meldet ein Ereignis, und weiter bis der Link tatsächlich steht — gegen die im Lastenheft geforderte Wakeup-Zeit prüfen.

Netzwerk- und Systemebene

  • Volle Topologie-Simulation: Mit allen beteiligten Steuergeräten (nicht nur Punkt-zu-Punkt) die Master/Slave-Matrix gegen die reale Verkabelung verifizieren — idealerweise automatisiert aus der ARXML-Konfiguration abgeleitet, um manuelle Übertragungsfehler auszuschließen.

  • Dauertest unter Vibration/Temperatur: Da Signalqualitätsprobleme bei 100BASE-T1 oft erst unter mechanischer Belastung sichtbar werden, ist ein Dauertest im klimatisierten Vibrationsprüfstand vor dem ersten Fahrzeugaufbau sinnvoll.

Wenn möglich: den ersten Fahrzeugaufbau nicht mit Serien-Kabelbaum, sondern mit einem instrumentierten Testkabelbaum durchführen, der Zugriff auf die Differenzsignale für ein Oszilloskop erlaubt. Die Fehlersuche im fertig verbauten Fahrzeug ist ungleich aufwändiger.

Checkliste — Migration von TX zu T1

Eine praktische Checkliste für den Umstieg, gegliedert nach Projektphase.

Planung

  • PHY-Auswahl getroffen und Clause-22/45-Unterstützung geprüft

  • Master/Slave-Rollen für alle Verbindungen in der Topologie festgelegt

  • Steckverbinder-Standard festgelegt (HSD, MATEnet, H-MTD) und mit Kabelbaum-Lieferant abgestimmt

  • Maximale Kabellängen je Segment gegen 100BASE-T1-Spezifikation geprüft (15 m Standard)

  • WakeUp-Konzept für den neuen PHY definiert (WakeUp-Puls statt Energy-Detect)

Hardware

  • PCB-Layout für 100 Ω Differential-Pair-Matching neu berechnet (nicht vom TX-Design übernommen)

  • Common-Mode-Filter für die neue PHY-Charakteristik dimensioniert

  • Power-Sequencing gemäß neuem PHY-Datenblatt umgesetzt

  • ESD-Schutzbeschaltung am neuen Steckverbinder geprüft

Software / AUTOSAR-Stack

  • Neuer EthTrcv-Treiber integriert und gegen Referenz-PHY-Datenblatt qualifiziert

  • ARXML-Diff zwischen alter TX- und neuer T1-Konfiguration erstellt und jeder neue Parameter bewusst gesetzt (nicht auf Default belassen)

  • Master/Slave-Parameter je Instanz gesetzt und gegen reale Verkabelung verifiziert

  • WakeUp-Parameter (Aktivierung, Debounce, Polarität) für neuen Mechanismus konfiguriert

  • MDIO-Zugriffsschicht auf korrekte Clause (22 vs. 45) geprüft

  • Vendor-Extension-Pakete des neuen PHY-Herstellers eingebunden

Test

  • Link-Up-Test mit kurzem und mit maximal langem Kabel durchgeführt

  • Augendiagramm- und Return-Loss-Messung durchgeführt

  • Vollständiger Sleep/WakeUp-Zyklus über Ethernet verifiziert

  • Master/Slave-Matrix in voller Topologie gegen reale Verkabelung geprüft

  • EMV-Vormessung durchgeführt

  • Dauertest unter Vibration/Temperatur abgeschlossen

Diese Checkliste ersetzt keine projektspezifische Risikoanalyse. Insbesondere bei sicherheitsrelevanten Kommunikationspfaden (z. B. wenn über die Ethernet-Verbindung ASIL-relevante Daten übertragen werden) sind zusätzliche Nachweise gegen ISO 26262 erforderlich, die über den Rahmen dieser rein funktionalen Checkliste hinausgehen.

Zusammenfassung

ThemaKernaussage für die Migration

Physikalische Ebene

PAM3 statt MLT-3, Single-Pair statt Dual-Pair, Echo-Cancellation zwingend — komplett neue PHY-Generation

Auto-Negotiation

Entfällt komplett; Master/Slave muss statisch und konsistent zur realen Verkabelung konfiguriert sein

EthTrcv-Treiber

Vollständige Neu-Integration nötig, keine Anpassung eines bestehenden Treibers

WakeUp

WakeUp-Puls statt Energy-Detect — TX-Konfiguration unverändert übernehmen führt zu stillem Ausfall im Sleep-Betrieb

Höhere Schichten

EthIf, TCP/IP, SOME/IP, Dcm bleiben unverändert — die Migration bleibt auf Layer 1/2 begrenzt

Größtes Fehlerrisiko

Master/Slave-Konflikt und Impedanzprobleme — beide zeigen sich oft erst im Fahrzeug, nicht am Labortisch

Weiter in der EthTrcv-Serie: EthTrcv von der Hardwareseite — PHY-Architektur für Software-Entwickler