Figure 5.2: Interfaces required by Time Synchronization from other Functional Clusters

1. Diagrammtyp & Architektur-Kontext

• Diagrammtyp: UML-Komponenten- und Schnittstellendiagramm (Statisches Architektur- und Abhängigkeitsmodell der AUTOSAR Adaptive Platform).
• Architektur-Kontext: Spezifiziert die externen Abhängigkeiten (Required Interfaces) des Functional Clusters Time Synchronization (AP Release R24-11, SWS TimeSynchronization, Kapitel 5.2).
• Funktionale Einordnung: Dargestellt ist eine daemon-basierte Implementierung (daemon-based). Der Time-Synchronization-Daemon fungiert als Service-Consumer und stützt sich auf Basisfunktionalitäten des Betriebssystems (Low-Level-Netzwerkzugriff für PTP/gPTP) sowie der Nachbar-Cluster Log and Trace (Plattform-Diagnose), Persistency (nichtflüchtige Speicherung von Zeit-Offsets und Parametern) und Cryptography (kryptografische Authentifizierung und Absicherung von PTP-Paketen über den CryptoStack).

2. Komponenten, Entitäten & Schnittstellen

Komponenten (Consumer & Provider)

• «aapFunctionalCluster» Time Synchronization (Consumer):
  • Eigenschaft: daemon-based (Ausführung als autonomer Hintergrund-Prozess/Daemon im Plattform-Kontext).
• Operating System (Provider):
  • Plattform-Betriebssystem (POSIX/Kernel-Ebene), das native Socket- und Netzwerk-Treiberressourcen bereitstellt.
• «aapFunctionalCluster» Log and Trace (Provider):
  • Adaptiver Funktionscluster für standardisiertes Logging (ara::log).
• «aapFunctionalCluster» Persistency (Provider):
  • Adaptiver Funktionscluster für strukturierte Datenpersistierung (ara::per).
• «aapFunctionalCluster» Cryptography (Provider):
  • Eigenschaft: daemon-based. Adaptiver Funktionscluster zur Bereitstellung kryptografischer Primitiven und Sicherheitsdienste (ara::crypto).

Schnittstellen & Realisierungen (Mittelebene)

• «aapInternal» Raw Socket API:
  • Typ: OS-interne Low-Level-Schnittstelle.
  • Zweck: Direkter Layer-2-/Ethernet-Frame-Zugriff ohne Protokoll-Overhead zur Übertragung von PTP-/IEEE-802.1AS-Paketen sowie Abruf von Hardware-Timestamps (SO_TIMESTAMPING).
  • Realisierungsbeziehung: Wird vom Operating System über Interface-Realisierung implementiert.
• «aapAPI, aapNativeInterface» Logger:
  • Typ: C++ Native API (ara::log).
  • Methoden:
    • + IsEnabled(): bool
    • + Log(MsgId, Params)
    • + LogDebug(): LogStream, + LogError(): LogStream, + LogFatal(): LogStream, + LogInfo(): LogStream, + LogVerbose(): LogStream, + LogWarn(): LogStream, + WithLevel(): LogStream
  • Realisierungsbeziehung: Realisiert durch «aapFunctionalCluster» Log and Trace.
• «aapAPI, aapPortInterface» KeyValueStorage:
  • Typ: Port-basiertes C++ API (ara::per).
  • Methoden:
    • + DiscardPendingChanges(), + GetAllKeys(), + GetCurrentValueSize(), + GetValue(), + KeyExists(), + RecoverKey(), + RemoveAllKeys(), + RemoveKey(), + ResetKey(), + SetValue(), + SyncToStorage()
  • Realisierungsbeziehung: Realisiert durch «aapFunctionalCluster» Persistency.
• «aapAPI, aapNativeInterface» CryptoStack:
  • Typ: Nativer Schnittstellen-Stack (ara::crypto).
  • Zweck: Bereitstellung von Krypto-Operationen (z. B. Signatur-/MAC-Prüfung und -Erzeugung für PTP Security TLVs nach IEEE 802.1AS).
  • Realisierungsbeziehung: Realisiert durch «aapFunctionalCluster» Cryptography.

Abhängigkeitsbeziehungen

• Time Synchronization nutzt Raw Socket API, Logger und CryptoStack über gerichtete UML-Nutzungsabhängigkeiten («use»).
• Der Zugriff auf KeyValueStorage erfolgt über eine als Port modellierte Nutzungsabhängigkeit («use», «aapRequiredPort»).

3. Dynamisches Verhalten & Sequenzablauf

Aus dem statischen Schnittstellenvertrag leiten sich für den Time-Sync-Daemon folgende Interaktionsphasen ab:

1. Initialisierungs- & Bootstrapping-Phase:
   • Persistenzabruf: Abfrage bestehender Konfigurationen, initialer Offsets oder zuletzt gespeicherter Zeitstempel via KeyExists() und GetValue(). Vorab-Größenprüfung mittels GetCurrentValueSize().
   • Krypto-Initialisierung: Initialisierung von Schlüsselkontexten und Krypto-Providern über CryptoStack zur Vorbereitung abgesicherter PTP-Kommunikation.
   • Socket-Bind: Initialisierung der Ethernet-Interfaces über Raw Socket API, Binden an den PTP-Port (Ethertype 0x88F7 bzw. UDP-Ports 319/320) und Aktivierung der Hardware-RX/TX-Timestamping-Flags im Kernel.
   • Status-Logging: Ausgabe des Initialisierungsstatus via LogInfo().
2. Zyklische Synchronisationsphase (PTP / IEEE 802.1AS & SecPTP):
   • Paketverarbeitung: Senden und Empfangen zeitkritischer Sync-, Follow_Up-, Pdelay_Req- und Pdelay_Resp-Nachrichten über die Raw Socket API.
   • Kryptografische Absicherung: Authentifizierung eingehender PTP-Nachrichten (Prüfung von MACs/Signaturen) und Signieren ausgehender Zeitnachrichten über CryptoStack.
   • Jitter-/Fehlerbehandlung: Protokollierung von Synchronisationsverlusten, Authentifizierungsfehlern oder Drift-Überschreitungen über LogWarn() bzw. LogError().
3. Persistierungs- & Shutdown-Phase:
   • Sichern akkumulierter Werte: Aktualisierung persistenter Zeitbasen (z. B. relative Clock-Drift oder Epoch-Daten) via SetValue().
   • Flushing: Atomares Commit der geänderten Schlüssel auf den Festspeicher mittels SyncToStorage().

4. Normative Relevanz & Entwickler-Hinweise

• OS-Privilegien & POSIX-Capabilities: Da Raw Socket API als «aapInternal» deklariert ist, erfordert der Daemon erhöhte Betriebssystem-Rechte (unter Linux/POSIX typischerweise CAP_NET_RAW für Raw Sockets und CAP_SYS_TIME für Clock-Disziplinierung via clock_adjtime/clock_settime).
• Latenz- und Jitter-Entkopplung:
  • SyncToStorage() blockiert I/O und darf keinesfalls im zeitsynchronen Callback-Pfad der PTP-Paketverarbeitung aufgerufen werden; Persistierungsoperationen müssen asynchron oder in dedizierten Hintergrund-Threads erfolgen.
  • Kryptografische Berechnungen über CryptoStack dürfen den Hardware-Timestamping- und Sende-/Empfangspfad zeitlich nicht unzulässig verzögern.
  • Logging via LogStream in der PTP-Hotpath-Schleife ist strikt über IsEnabled() abzufragen, um Jitter durch String-Formatierung und IPC-Queues zu vermeiden.
• Manifest-Konfiguration & Port-Modellierung:
  • Der Zugriff auf KeyValueStorage ist explizit als «aapRequiredPort» modelliert und erfordert ein entsprechendes Port-Interface-Design im Execution Manifest / Service Instance Manifest.
  • Für Logger und CryptoStack sind native C++ Bindings (ara::log, ara::crypto) im Manifest zu konfigurieren.
• Architekturprinzip: Time Synchronization umgeht für den PTP-Transport bewusst die Service-Orientierte Kommunikation (ara::com), um Sub-Mikrosekunden-Latenz und deterministisches Hardware-Timestamping auf Schicht 2 zu gewährleisten.