Figure 4.7: Sync/Follow_Up message flow with Timestamping points for Sync for Time Aware Bridge with GTM not as Management CPU

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: Nachrichtenfluss-, Topologie- und Zeitstempelpunkt-Diagramm (IEEE 802.1AS / gPTP Architekturmodell mit Hardware-/Software-Schnittstellen).
• Funktionale Einordnung: Spezifikation des Ethernet Time-Aware Bridge-Verhaltens (AUTOSAR_FO_PRS_TimeSyncProtocol, Kap. 4.10) für den Anwendungsfall, dass der Global Time Master (GTM) nicht die interne Management-CPU der Bridge ist, sondern als externe Netzknoten-Instanz einspeist.
• Architektonischer Zweck: Definition der exakten Mess- und Korrekturpunkte für Ingress-, Egress- und Host-Uplink-Verzögerungen, um sowohl die lokale Management-CPU auf T_0' zu synchronisieren (TimeSlave-Rolle) als auch den PTP-Datenstrom unter Verweilzeitkompensation (correctionField T_c) an kaskadierte TimeSlaves weiterzuleiten (Bridge-Rolle).

2. Komponenten, Entitäten & Schnittstellen

• GTM (Global Time Master / Grandmaster Clock): Externe Zeitquelle; sendet Sync- und Follow_Up-PDUs mit Master-Ursprungszeitstempel T_0 (preciseOriginTimestamp).
• TimeSlave / Bridge (Kombinierte Netzwerkeinheit):
  • Switch (TSN / PTP Hardware Core): Multiport-Switch mit portbezogenen Hardware-Timestamping-Einheiten:
    • Port 3: Ingress-Slave-Port, angebunden an den GTM.
    • Port 1: Interner Management-/Uplink-Port (z. B. MII, RGMII, PCIe) zur Host-CPU.
    • Port 2: Egress-Master-Port in Richtung nachgelagerter PTP-Slaves.
    • Port 4, ...: Weitere Switch-Ports (inaktiv oder für regulären Datenverkehr).
  • Management CPU (Host-Controller): Führt den AUTOSAR-Stack aus (Classic: EthTSyn, StbM, EthIf, Eth, EthSwt; Adaptive: ARA::TSYN / Daemon). Fungiert als interner TimeSlave für die lokale Zeitbasis T_0'.
• Time Slave (Aktiv, links unten): Kaskadierte externe Endstation (ECU); empfängt weitergeleitete Zeitinformationen und synchronisiert die lokale Uhr auf T_0''.
• TimeSlave (Inaktiv/ausgegraut, rechts unten): Optionale Topologie-Erweiterung an weiteren Switch-Ports.
• Nachrichten/PDUs:
  • Sync (Event-Message, PTP-Nachrichtentyp 0x0, hardware-zeitgestempelt).
  • Follow_Up (General-Message, PTP-Nachrichtentyp 0x8, transportiert T_0, TLVs und modifiziertes correctionField).

3. Dynamisches Verhalten & Sequenzablauf

1. Einspeisung durch GTM (T_0 → T_4):
   • Der GTM generiert einen Sync-Frame und erfasst den Austrittszeitpunkt als Hardware-Timestamp T_0.
   • Der Frame erreicht Port 3 des Switches; dort wird der Ingress-Zeitstempel T_4 auf MAC/PHY-Ebene determiniert.
2. Interner Uplink zur Management CPU (T_4 → T_5 → T_6):
   • Der Sync-Frame wird über Port 1 zur Management CPU geroutet.
   • Beim Verlassen des Switch-Cores an Port 1 wird T_5 erfasst. Die Ingress-Verweilzeit (Rx to Uplink Residence Time) beträgt $\Delta t_{\text{rx}} = T_5 - T_4$.
   • Am MAC-Interface der Management CPU wird der Eintreffzeitpunkt T_6 gelatcht.
   • Berechnung der lokalen Slave-Zeit T_0': Die Management CPU synchronisiert ihre interne Uhr mittels T_0, der gemessenen Link-Verzögerung ($\text{Pdelay}_{\text{GTM}\to\text{Port3}}$) und der internen Ingress-Laufzeit (T_5 - T_4) sowie Interface-Laufzeit (T_6 - T_5).
3. Egress & Weiterleitung an nachgelagerten Slave (T_4 → T_7):
   • Der Sync-Frame wird über Port 2 weitergeleitet.
   • Am Austrittspunkt von Port 2 wird der Egress-Hardware-Timestamp T_7 erfasst.
   • Kompensation im Correction Field (T_c): Die Gesamtverweilzeit der Bridge beträgt $\Delta t_{\text{residence}} = T_7 - T_4$. Das im nachfolgenden Follow_Up-Frame transportierte correctionField wird aktualisiert: $$\text{correctionField}_{\text{out}} = \text{correctionField}_{\text{in}} + (T_7 - T_4) + \text{Pdelay}_{\text{upstream}}$$
4. Synchronisation des nachgelagerten Slaves (T_0''):
   • Der nachgeschaltete Time Slave empfängt Sync und das aktualisierte Follow_Up und stellt seine Uhr auf T_0'' ein (unter Einrechnung von T_0, dem kumulierten T_c und dem eigenen Pdelay zu Port 2).

4. Normative Relevanz & Entwickler-Hinweise

• Messmethoden vs. statische Konfiguration (PRS_TS_00059, RS_TS_20048, RS_TS_20059):
  • Dynamische Messung (Standard): Wenn rx_residence_time == 0 und tx_residence_time == 0, muss der Ethernet-Switch-Treiber (EthSwt) die interne Verweilzeit über Hardware-Zeitstempel (T_4, T_5, T_7) live ermitteln (PRS_TS_00168, PRS_TS_00169).
  • Statischer Fallback: Sind rx_residence_time > 0 und tx_residence_time > 0 konfiguriert, wird die Summe beider Werte als statische Switch-Verweilzeit (T_7 - T_4) verwendet, anstatt Hardwaredifferenzen zu berechnen (PRS_TS_00170, PRS_TS_00171).
• Secured Time Synchronization & TLV-Behandlung (PRS_TS_00207 – PRS_TS_00209):
  • Enthält Follow_Up ein AUTOSAR Sub-TLV:Time Secured, schützt eine CRC (CRC_Time_1) das correctionField (geprüft über Bitmask 0x04 in CRC_Time_Flags).
  • Da die Bridge das correctionField modifiziert (T_c), muss die CRC vor dem Aussenden an Port 2 zwingend neu berechnet werden (PRS_TS_00209).
  • Schlägt die Ingress-Validierung der CRC fehl, muss der Frame laut PRS_TS_00208 sofort verworfen werden (kein Forwarding).
  • Bei Nutzung von Sub-TLV:Time Authenticated (PRS_TS_00253 – PRS_TS_00255) muss der ICV (Integrity Check Value) nach der correctionField-Modifikation neu generiert werden.
• Hardware- & Treiberanforderungen:
  • Der Switch-Baustein muss zeitgleiches Multi-Port-Timestamping (Ingress an Port 3, Egress an Port 1 und Port 2) ohne FIFO-Überlauf unterstützen.
  • Takt-Drift zwischen der Switch-internen Hardware-Clock und der Host-CPU-Clock muss bei der Übergabe T_5 → T_6 über RateRatio-Kompensation berücksichtigt werden.