Dieser Post baut auf dem vorherigen Post zum MDIO-Zugriff auf — dort ging es darum, wie Software überhaupt Register im PHY-Chip lesen und schreiben kann. Diesmal nutzen wir genau diesen Zugriffsweg für ein einziges, aber zeitkritisches Feature: das Zeitstempeln von Ethernet-Frames für IEEE 802.1AS, besser bekannt als gPTP (generalized Precision Time Protocol).
Wer sich mit Ethernet-Switches im Fahrzeug beschäftigt, sollte außerdem den EthSwt-Post kennen — denn gPTP funktioniert nur, wenn auch die Switches im Netz die Protokollnachrichten korrekt weiterleiten und dabei ihre eigene Durchlaufzeit korrekt in die Nachricht einrechnen.
Warum Zeitsynchronisation im Fahrzeugnetzwerk?
Ein modernes Fahrzeug ist kein einzelner Rechner mit ein paar Sensoren dran — es ist ein verteiltes System aus Dutzenden Steuergeräten, die sich auf eine gemeinsame Vorstellung von "jetzt" einigen müssen. Drei Beispiele, warum das wichtig ist:
ADAS-Sensorfusion: Ein Radarsensor liefert eine Objektliste, eine Kamera liefert Bounding Boxes, ein Lidar liefert eine Punktwolke. Damit die Fusion diese drei Datenquellen demselben physischen Objekt zuordnen kann, müssen die Zeitstempel der drei Sensoren auf demselben Zeitraster liegen. Bei 130 km/h legt ein Fahrzeug 36 mm pro Millisekunde zurück — ein Zeitversatz von wenigen hundert Mikrosekunden zwischen zwei Sensoren verschiebt ein Objekt bereits sichtbar im Fusionsergebnis.
Audio/Video Bridging (AVB/TSN): Wird Audio über Ethernet verteilt (z. B. für Soundsysteme oder Mikrofon-Freisprecheinrichtungen), müssen alle Endpunkte mit demselben Takt abspielen bzw. abtasten — sonst entstehen hörbare Knackser oder Laufzeitunterschiede zwischen Lautsprecherkanälen.
Diagnose- und Logging-Zeitstempel: Ereignisse aus verschiedenen Steuergeräten (Fehlerspeichereinträge, Tachograph-relevante Ereignisse, Blackbox-Logs für Unfallrekonstruktion) müssen sich in eine gemeinsame Zeitlinie einordnen lassen. Ohne synchronisierte Uhr lässt sich nicht rekonstruieren, welches Ereignis zuerst passiert ist.
Alle drei Anwendungsfälle haben eine gemeinsame Anforderung: nicht die absolute Genauigkeit der Uhr zählt (die kann von einer GNSS-Quelle kommen oder frei laufen), sondern die relative Synchronität zwischen den Steuergeräten im Netzwerk. |
IEEE 802.1AS (gPTP) Grundlagen
IEEE 802.1AS ist ein Profil des Precision Time Protocol (PTP, IEEE 1588), zugeschnitten auf Ethernet-basierte Echtzeitnetzwerke. Im Automotive-Umfeld hat sich dafür der Name gPTP (generalized PTP) etabliert.
Master/Slave-Hierarchie
gPTP baut einen Baum aus Zeitquellen auf. An der Wurzel steht der Grandmaster,
meist ein Steuergerät mit besonders stabiler Uhr (Oszillator mit hoher Güte,
teils an ein GNSS-Zeitsignal gekoppelt). Der Best Master Clock Algorithm (BMCA)
bestimmt automatisch, welches Gerät im Netz diese Rolle übernimmt, basierend auf
Kriterien wie Uhrenqualität (clockClass, clockAccuracy) und Priorität.
┌───────────────┐
│ Grandmaster │ (z. B. Gateway-ECU mit GNSS-Referenz)
└───────┬───────┘
│ Sync
┌───────────┴───────────┐
┌─────▼─────┐ ┌─────▼─────┐
│ EthSwt A │ │ EthSwt B │
└─────┬─────┘ └─────┬─────┘
┌─────────┴────────┐ │
┌────▼───┐ ┌────▼───┐ ┌────▼───┐
│ ADAS-ECU│ │ Zonal-ECU│ │ Audio-ECU│
└────────┘ └────────┘ └────────┘Jedes Steuergerät zwischen Grandmaster und Blatt-Knoten ist entweder reiner Slave (Zeit annehmen), reiner Master (Zeit weitergeben) oder — bei Switches mit mehreren Ports — beides gleichzeitig auf unterschiedlichen Ports.
Sync und Follow_Up — die Zeitverteilung
Der Master verteilt seine Zeit periodisch (typisch alle 125 ms bis 1 s) über
zwei Nachrichten: Sync und Follow_Up.
Master Slave
│ │
│── Sync ──────────────────────────────────────────►│ t2 = Ingress-Timestamp
│ (Sendezeitpunkt t1 wird NICHT im Sync-Paket │ (hardware-erfasst)
│ selbst übertragen — "Two-Step Clock") │
│ │
│── Follow_Up ──────────────────────────────────────►│
│ (enthält t1 aus Egress-Timestamp │
│ + akkumulierte correctionField │
│ aller durchlaufenen Switches) │
│ │
│ Offset = t2 − t1 − Link-Delay − Residence-TimeDer Grund für das Zwei-Nachrichten-Verfahren (Two-Step Clock): Der exakte
Sendezeitpunkt t1 steht erst fest, nachdem das Sync-Paket den PHY verlassen hat —
er kann also nicht mehr rechtzeitig in dasselbe Paket geschrieben werden. Also
wird er nachträglich per Follow_Up-Nachricht übermittelt. (One-Step Clocks,
die t1 "on the fly" ins auslaufende Paket patchen, existieren auch, sind aber
in Automotive-Steuergeräten seltener anzutreffen als Two-Step-Implementierungen.)
Pdelay — die Link-Verzögerung
Sync/Follow_Up allein reicht nicht, denn zwischen Master und Slave liegt
eine Kabelstrecke mit Laufzeit, die kompensiert werden muss. Dafür misst gPTP
die Peer Delay — pro physischem Link, unabhängig von der Master/Slave-Rolle,
mit einem eigenen Nachrichtenpaar:
Requestor Responder
│ │
│── Pdelay_Req ─────────────────────────────────────►│ t2 = Ingress-Timestamp
│ t1 = Egress-Timestamp │ (hardware-erfasst)
│ (hardware-erfasst) │
│ │
│◄── Pdelay_Resp ─────────────────────────────────────│ t3 = Egress-Timestamp
│ (enthält t2, grobe Zeitangabe) │ (hardware-erfasst)
│ │
│◄── Pdelay_Resp_Follow_Up ────────────────────────────│
│ (enthält exakten t3) │
│ │
│ t4 = Ingress-Timestamp (hardware-erfasst) │
│ │
│ Link-Delay = ((t4 − t1) − (t3 − t2)) / 2 │Die Formel eliminiert den unbekannten Uhren-Offset zwischen den beiden Geräten,
weil sie nur Zeitdifferenzen verwendet, die jeweils auf derselben lokalen Uhr
gemessen wurden (t4 − t1 auf der Requestor-Uhr, t3 − t2 auf der Responder-Uhr).
Vorausgesetzt: Hin- und Rückweg sind symmetrisch — eine Annahme, die bei
100BASE-T1/1000BASE-T1 (Single-Pair, bidirektional) in der Praxis gut erfüllt ist.
Residence Time und correctionField
Läuft eine Nachricht durch mehrere Switches (siehe Baum oben), addiert jeder
Switch seine eigene Verweildauer im Chip (Residence Time) und die gemessene
Peer Delay des ausgehenden Ports in das correctionField der Follow_Up-Nachricht.
Der Slave am Ende der Kette bekommt so die Summe aller Verzögerungen mitgeliefert
und muss nicht selbst wissen, wie viele Hops dazwischenlagen.
Jeder Switch im Pfad muss selbst gPTP-fähig sein und Residence Time präzise messen — sonst akkumuliert sich der Fehler über mehrere Hops. Das ist einer der Gründe, warum EthSwt-Chips im Fahrzeug eigene Timestamp-Hardware brauchen, genau wie EthTrcv-PHYs. Mehr dazu im EthSwt-Post. |
Die Rolle des PHY bei gPTP
Hier kommt der PHY-Chip ins Spiel — und der Grund, warum dieser Post in der EthTrcv-Serie steht statt in einer reinen Protokoll-Serie.
Warum Software-Timestamping nicht präzise genug ist
Die naheliegende Idee: Der Zeitstempel wird gesetzt, sobald die Software (Interrupt Service Routine oder Task) das Frame sieht. Das Problem: bis dahin hat das Frame bereits einen langen, variablen Weg zurückgelegt.
Kabel → MDI → PMA → PCS → RGMII → MAC-FIFO → DMA → Interrupt → ISR → Task
└──────────────── variable Latenz ────────────────────────┘
(100 ns bis mehrere zehn Mikrosekunden)Aus dem vorherigen Hardware-Post wissen wir bereits: allein der Weg durch PCS und PMA im PHY-Chip kostet 150–500 ns — und dieser Wert ist nicht konstant, sondern hängt von Temperatur, Versorgungsspannung, Chip-Exemplarstreuung und sogar vom aktuellen Verkehr auf dem Bus ab. Kommt danach noch Interrupt-Latenz, DMA-Warteschlangen und Betriebssystem-Scheduling-Jitter hinzu, landen Software-Timestamps schnell im Bereich von 10–100 µs Unsicherheit — für gPTP, das Sub-Mikrosekunden-Genauigkeit anstrebt, viel zu ungenau.
Es geht bei Hardware-Timestamping nicht in erster Linie darum, die Verzögerung zu minimieren — ein konstanter Offset lässt sich problemlos herausrechnen. Entscheidend ist die Varianz (Jitter) dieser Verzögerung. Genau die ist bei Software-Timestamping hoch und bei Hardware-Timestamping niedrig. |
Wo im Signalpfad der Zeitstempel entstehen muss
Die Lösung: den Zeitstempel so nah wie möglich am physikalischen Signal erfassen — im PHY-Chip selbst, direkt an der Erkennung des Start Frame Delimiter (SFD) auf Leitungsebene, bevor PCS-Decodierung, RGMII-Transfer und MAC-FIFO zusätzlichen und variablen Jitter einbringen.
Kabel → MDI → [SFD-Erkennung + Timestamp-Capture] → PMA → PCS → RGMII → MAC
▲
hier entsteht der Zeitstempel — mit einer lokalen,
hochauflösenden Uhr im PHY-Chip (meist PLL-basiert,
abgeleitet vom Referenztakt)Hardware-Timestamping im PHY-Chip
Ingress- und Egress-Timestamp-Units
Moderne Automotive-PHYs für 100BASE-T1/1000BASE-T1 integrieren dafür zwei dedizierte Hardware-Blöcke:
┌─────────────────────────────────────────────────────────┐
│ PHY-Chip │
│ │
│ MDI ──►[SFD-Detect]──►[Ingress Timestamp Unit (ITU)]──┐ │
│ │ │
│ Lokale Zeitbasis (Free-Running │
│ Counter, meist ns-Auflösung, │ │
│ gespeist vom PHY-Referenztakt) │ │
│ │ │
│ MDI ◄──[SFD-Insert]◄──[Egress Timestamp Unit (ETU)]────┘ │
│ │
└──────────────────────┬─────────────────────────────────┘
│ MDIO (Register-Zugriff, siehe MDIO-Post)
▼
EthTrcv / Eth-TreiberIngress Timestamp Unit (ITU) erfasst den Empfangszeitpunkt beim Erkennen des SFD auf der Leitung. Egress Timestamp Unit (ETU) erfasst analog den Zeitpunkt, an dem der SFD tatsächlich auf die Leitung gelegt wird — nicht wann die Software das Sendekommando gegeben hat. Beide Werte werden in Timestamp-Registern abgelegt, die über MDIO (typisch Clause 45, siehe vorheriger Post) ausgelesen werden.
Chip-Beispiele: NXP TJA1102 und Marvell 88Q2122
| Chip | Interface | Timestamping-Eigenschaften |
|---|---|---|
NXP TJA1102 | Dual 100BASE-T1 | Integrierte Timestamp Unit mit typ. ±8 ns Auflösung, SFD-basierte Erfassung, Zeitstempel über MMD-Register (Clause 45) auslesbar, unterstützt IEEE 802.1AS direkt in Silizium |
Marvell 88Q2122 | 1000BASE-T1 / 100BASE-T1 | Ingress/Egress-Timestamp-Einheiten mit Sub-10-ns-Auflösung, konfigurierbare Interrupt-Meldung bei neuem Zeitstempel, PTP-Hardware-Clock (PHC) im Chip |
Beide Chip-Familien sind Beispiele — die konkreten Registeradressen und Auflösungswerte unterscheiden sich je nach Silizium-Revision und müssen immer im aktuellen Datenblatt geprüft werden. Das Prinzip (ITU/ETU nahe an der SFD-Erkennung) ist bei praktisch allen Automotive-PHYs mit gPTP-Unterstützung identisch. |
AUTOSAR StbM & EthTrcv — der Weg des Zeitstempels
Der Zeitstempel liegt jetzt als Registerwert im PHY. Bis daraus eine synchronisierte, für Applikations-Software nutzbare Systemzeit wird, durchläuft er mehrere AUTOSAR-Basissoftwareschichten.
Vom PHY-Register zu StbM_BusSetGlobalTime
PHY-Chip (ITU/ETU-Register)
│
│ MDIO-Zugriff (Clause 45, Vendor-spezifische MMD-Register)
▼
EthTrcv
│ Vendor-API aktiviert/konfiguriert die Timestamp Unit im PHY
│ (kein Teil der standardisierten AUTOSAR EthTrcv-API,
│ sondern Vendor-Extension analog zu EthTrcv_VendorSpecific-Funktionen)
▼
Eth (Ethernet-Treiber)
│ Eth_GetIngressTimeStamp() / Eth_GetEgressTimeStamp()
│ standardisierte AUTOSAR-Schnittstelle zum Auslesen der Zeitstempel
▼
EthTSyn (Ethernet Time Synchronization)
│ implementiert das gPTP-Protokoll selbst:
│ Sync/Follow_Up senden bzw. empfangen, Pdelay-Mechanismus,
│ Offset- und Link-Delay-Berechnung, BMCA
▼
StbM_BusSetGlobalTime()
│ meldet der Zeitbasisverwaltung die berechnete globale Zeit
▼
StbM (Synchronized Time-Base Manager)
│ hält die synchronisierte Zeitbasis vor, macht sie über
│ StbM_GetCurrentTime() für andere Module verfügbar
▼
Konsumenten: Dcm (Diagnose-Zeitstempel), Datenlogging,
ADAS-SWCs (Sensorfusion), Com (zeitgestempelte Signale)Modul-Verantwortlichkeiten im Überblick
| Modul | Verantwortung im gPTP-Kontext |
|---|---|
EthTrcv | Konfiguriert und aktiviert die Timestamp-Hardware im PHY über MDIO (Vendor-Erweiterung); liefert grundsätzlich Link-Status, nicht die Zeitstempel selbst |
Eth | Standardisierte Schnittstelle zum Lesen der Ingress-/Egress-Zeitstempel
( |
EthTSyn | Implementiert IEEE 802.1AS: sendet/empfängt Sync, Follow_Up, Pdelay_Req/Resp, wertet BMCA aus, berechnet Offset und Link-Delay |
StbM | Verwaltet eine oder mehrere synchronisierte Zeitbasen, stellt sie applikationsweit über eine einheitliche API zur Verfügung |
|
Konfiguration
PHY-seitige Aktivierung des Timestamping
Auf Registerebene (vereinfachtes, chip-typisches Beispiel über eine Vendor-spezifische MMD, siehe MDIO-Post für die Clause-45-Grundlagen):
MMD-Adresse (DEVAD): 30 (Vendor Specific 1, chip-abhängig)
Register: PTP_CONFIG (Beispieladresse 0x0834)
Bit 0 TS_EN — Timestamp Unit aktivieren
Bit 1 TS_SFD_MODE — Erfassung am SFD statt am Frame-Ende
Bit 4 TS_INT_EN — Interrupt bei neuem Zeitstempel aktivieren
Register: PTP_STATUS (Beispieladresse 0x0836)
Bit 0 TS_VALID — neuer Zeitstempel verfügbar
Bit 1 TS_OVERFLOW — Zeitstempel nicht rechtzeitig abgeholt
|
AUTOSAR-seitige StbM-Konfiguration
Auf AUTOSAR-Seite werden vor allem folgende Konfigurationselemente relevant:
StbMSynchronizedTimeBase
StbMTimeBaseId — eindeutige ID der Zeitbasis (z. B. 0 = gPTP-Domain 0)
StbMOffsetTimeBase — false (globale, nicht lokal-relative Zeitbasis)
StbMEthSyncClient / StbMEthGlobalTimeMaster (je nach Rolle im Netz)
StbMSyncFrameTimeout — max. Zeit ohne gültige Sync-Nachricht bis "not synchronized"
StbMSyncInterval — erwartetes Sync-Sendeintervall (z. B. 125 ms)
EthTSynGlobalTimeDomain
EthTSynPdelayReqInterval — Sendeintervall der Pdelay_Req-Nachrichten
EthTSynSyncInterval — Sendeintervall der Sync-Nachrichten (nur am Master)
EthTSynPortRole — MASTER_PORT / SLAVE_PORT je Ethernet-Port
|
Genauigkeit in der Praxis
Der entscheidende Vergleich — was Hardware-Timestamping tatsächlich bringt:
| Timestamp-Methode | Typische Genauigkeit | Hauptquelle der Unsicherheit |
|---|---|---|
Software (Task-Ebene) | 10–100 µs | OS-Scheduling, IP-Stack-Verarbeitung, Task-Priorität |
Software (Interrupt/ISR-Ebene) | 1–10 µs | Interrupt-Latenz, DMA-Warteschlangen |
MAC-Timestamping (SoC-integriert, ohne PHY-Unit) | 100 ns – 1 µs | Variable PCS-/PMA-Durchlaufzeit im PHY (150–500 ns, temperatur- und exemplarabhängig) |
Hardware-Timestamping im PHY (ITU/ETU an der SFD-Erkennung) | < 100 ns (oft 8–40 ns laut Datenblatt) | Nur noch Jitter der lokalen PLL/Referenztakt-Quelle |
Für die eingangs genannten Anwendungsfälle heißt das konkret: IEEE 802.1AS in Kombination mit PHY-Hardware-Timestamping erreicht in gut konfigurierten Automotive-Netzwerken End-to-End-Synchronisationsgenauigkeiten im Bereich weniger hundert Nanosekunden bis niedriger Mikrosekunden über mehrere Hops — ausreichend für ADAS-Sensorfusion und AVB-Audiostreaming. Reines Software-Timestamping liegt dagegen häufig eine bis zwei Größenordnungen darüber und reicht für diese Anwendungsfälle nicht aus.
Die Genauigkeit des Gesamtsystems ist nur so gut wie das schwächste Glied in der Kette. Ein PHY mit ±8 ns Timestamp-Auflösung nützt wenig, wenn dazwischen ein Switch-Port ohne Hardware-Timestamping die Residence Time nur grob schätzt statt zu messen. |
Zusammenfassung
| Thema | Kernaussage für Software-Entwickler |
|---|---|
Warum Zeitsync nötig ist | Sensorfusion, AVB und Diagnose-Logging brauchen eine gemeinsame Zeitlinie über mehrere Steuergeräte hinweg |
gPTP-Grundmechanik | Sync/Follow_Up verteilt die Zeit, Pdelay_Req/Resp misst die Link-Verzögerung unabhängig von der Master/Slave-Rolle |
PHY-Rolle | Software-Timestamping ist zu jitterbehaftet; Hardware-Timestamping erfasst den Zeitstempel direkt an der SFD-Erkennung auf Leitungsebene |
AUTOSAR-Modulkette | EthTrcv konfiguriert die PHY-Timestamp-Hardware, Eth liest sie aus, EthTSyn implementiert gPTP, StbM verwaltet die globale Zeitbasis |
Konfigurationsfallstricke |
|
Genauigkeit | Hardware-Timestamping bringt < 100 ns statt > 1 µs — eine Größenordnung, die für ADAS und AVB tatsächlich den Unterschied macht |
Weiter in der EthTrcv-Serie: EthTrcv & Functional Safety — ASIL-Anforderungen und Fehlererkennungsmechanismen