Figure 7.3: Time Validation mechanism

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: UML-Sequenzdiagramm (Interaktionsdiagramm zur Darstellung des Nachrichtenaustauschs und der Kontrollflüsse über der Zeitachse).
• Technischer Zweck & funktionale Einordnung: Veranschaulicht den standardisierten Time Validation Mechanismus der AUTOSAR Adaptive Platform (Time Synchronization Functional Cluster gemäß RS_TS_00034). Dient der Erkennung von Übertragungsfehlern, Clock-Drifts, Timestamping-Ungenauigkeiten und böswilligen Manipulationen (z. B. Delay-Attacks, Man-in-the-Middle) bei gPTP-/PTP-basierten Zeitbasen (IEEE 802.1AS). Durch den Abgleich von Sende-/Empfangszeitstempeln und Korrekturwerten auf Master- und Slave-Ebene wird die Integrität der synchronisierten Zeitbasis für funktionale Sicherheit (ISO 26262) und Security (ISO/SAE 21434) verifiziert.

2. Komponenten, Entitäten & Schnittstellen

• Beteiligte Akteure & Lifelines:
  • Master Application / Valdiator (im Diagramm mit Tippfehler „Valdiator“): Validierungsinstanz (typischerweise Safety-/Monitoring-Applikation), die Timing-Rohdaten von Master und Slave korreliert, plausibilisiert und bewertet.
  • Responder/Master: Grandmaster- bzw. Master-Port des AUTOSAR AP Time Synchronization Stacks (Time Base Provider für Sync- und Pdelay-Responder).
  • Initiator/Slave: Slave-Port des AUTOSAR AP Time Synchronization Stacks (Time Base Consumer für Sync- und Pdelay-Initiator).
  • Slave Application: Lokale Applikationsinstanz auf dem Slave-Knoten zur Entgegennahme der lokalen Messwerte und Weiterleitung an den Validator.
• Schnittstellen & Interaktionskanäle:
  • Netzwerk-Protokollnachrichten (schwarz, IEEE 802.1AS / gPTP):
    • Sync message & Follow_Up message: Zweistufige Synchronisationsnachrichten (Master → Slave).
    • pDelayRequest, pDelayResponse, Pdelay_Resp_Follow_Up: Peer-Delay-Mechanismus zur Bestimmung der Leitungs- und Verarbeitungsverzögerung.
  • Stack-interne Validierungsschnittstellen (rot dargestellt, normative AUTOSAR SWS-Hooks):
    • SetMasterTimingData (SWS_TS_00424): Lokaler Transfer der Master-Sync-Messdaten (t_1, Sequenz-ID) an den Validator.
    • SetSlaveTimingData (SWS_TS_00425): Lokaler Transfer der Slave-Sync-Messdaten (t_1, t_2, CorrectionField, Sequenz-ID) an die Slave Application.
    • SetPdelayResponderData (SWS_TS_00426): Lokaler Transfer der Responder-Pdelay-Daten (t_2, t_3, Sequenz-ID) an den Validator.
    • SetPdelayInitiatorData (SWS_TS_00427): Lokaler Transfer der Initiator-Pdelay-Daten (t_1, t_4, Sequenz-ID) an die Slave Application.
  • Anwendungsspezifischer Rückkanal (blau):
    • User defined Feedback Message: Protokoll-agnostischer E2E-Kommunikationskanal (z. B. via ara::com / SOME/IP Event oder Method) vom Slave zum Validator.

3. Dynamisches Verhalten & Sequenzablauf

1. Synchronisationsphase:
   • Responder/Master sendet Sync message an Initiator/Slave und erfasst den Hardware-Egress-Timestamp t_1.
   • Der Master-Stack übergibt über SetMasterTimingData (SWS_TS_00424) diesen Zeitstempel und Kontextdaten an Master Application / Valdiator.
   • Responder/Master sendet Follow_Up message (enthält den präzisen Ursprungszeitstempel t_1 und akkumulierte Korrekturfelder).
   • Nach Empfang der Follow-Up-Nachricht und Erfassung des Ingress-Timestamps t_2 übergibt der Slave-Stack die gesammelten Messwerte via SetSlaveTimingData (SWS_TS_00425) an die Slave Application.
2. Propagation-Delay-Messphase (Peer-to-Peer):
   • Initiator/Slave triggert die Messung mit pDelayRequest (Sendezeitpunkt t_1,pdelay).
   • Responder/Master empfängt den Request (t_2,pdelay) und antwortet mit pDelayResponse (Sendezeitpunkt t_3,pdelay).
   • Responder/Master sendet Pdelay_Resp_Follow_Up (Übertragung von t_3,pdelay bzw. der Differenz t_3,pdelay - t_2,pdelay).
   • Der Master-Stack meldet die Responder-Timings via SetPdelayResponderData (SWS_TS_00426) an den Validator.
   • Nach Empfang der Pdelay-Antworten und Erfassung des Empfangszeitstempels t_4,pdelay übergibt der Slave-Stack die Initiator-Timings via SetPdelayInitiatorData (SWS_TS_00427) an die Slave Application.
3. Validierung & Konsistenzprüfung:
   • Die Slave Application aggregiert die lokalen Zeitstempeldaten (SetSlaveTimingData und SetPdelayInitiatorData) und überträgt diese asynchron über die User defined Feedback Message an den Master Application / Valdiator.
   • Der Validator korreliert die Master-Daten mit den empfangenen Slave-Daten anhand der Sequenz-IDs, berechnet Drift, Jitter sowie Laufzeitabweichungen und verifiziert, ob die Abweichung innerhalb konfigurierter Schwellwerte liegt.

4. Normative Relevanz & Entwickler-Hinweise

• Stack- & Schnittstellen-Konfiguration (SWS_TS_00424 bis SWS_TS_00427):
  • Entwickler des Adaptive Time Synchronization Stacks müssen Callback- bzw. Observer-Mechanismen bereitstellen, die Timing-Informationen unmittelbar nach Paketabschluss deterministisch an die Applikationsschicht übergeben.
  • Datenstrukturen umfassen mindestens: Sequenz-Identifikator, Domain-ID, Hardware-Zeitstempel (t_1 bis t_4) und Korrekturfelder (CorrectionField in ns/sub-ns).
• Hardware-Timestamping (PHY/MAC):
  • Die Integrität des Validierungsmechanismus setzt zwingend Hardware-Timestamping (IEEE 802.1AS MII/GMII) voraus. Software-generierte Timestamps verfälschen die Delay- und Driftberechnungen und führen zu Fehlalarmen im Validator.
• Applikationsdesign des Feedback-Pfads:
  • Der Feedback-Kanal (User defined Feedback Message) ist normativ bewusst anwendungsdefiniert. Für ASIL-Relevanz muss dieser Pfad zwingend gegen Ausfall, Verfälschung und Vertauschung abgesichert werden (E2E-Protection nach AUTOSAR E2E-Profile bzw. SecOC/TLS).
• Fehlerreaktion & Degradation:
  • Schlägt die Validierung im Validator fehl (z. B. berechnete Abweichung überschreitet Grenzwerte oder Sequenz-IDs driften auseinander), muss die Applikation die Zeitbasis als ungültig markieren (TimeBaseStatus verliert Synchronization-Flag) und das Gesamtsystem in den definierten Safe State überführen.