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 R23-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) und Persistency (nichtflüchtige Speicherung von Zeit-Offsets und Clock-Drift-Parametern).

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).

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 Realization (..|>) implementiert.
• «aapAPI, aapNativeInterface» Log and Trace::Logger:
  • Typ: C++ Native API (In-Process-Aufruf ohne IPC-Serialisierung).
  • Methoden:
    • + IsEnabled()
    • + 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» Persistency::KeyValueStorage:
  • Typ: Port-basiertes C++ API (ara::per).
  • Methoden:
    • + DiscardPendingChanges(), + GetAllKeys(), + GetValue(), + KeyExists(), + RecoverKey(), + RemoveAllKeys(), + RemoveKey(), + ResetKey(), + SetValue(), + SyncToStorage()
  • Realisierungsbeziehung: Realisiert durch «aapFunctionalCluster» Persistency.

Abhängigkeitsbeziehungen

• Time Synchronization nutzt alle drei Schnittstellen über gerichtete UML-Nutzungsabhängigkeiten: «use» (-->).

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().
   • 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):
   • Paketverarbeitung: Senden und Empfangen zeitkritischer Sync-, Follow_Up-, Pdelay_Req- und Pdelay_Resp-Nachrichten über die Raw Socket API.
   • Jitter-/Fehlerbehandlung: Protokollierung von Synchronisationsverlusten, Asymmetriefehlern 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.
  • Logging via LogStream in der PTP-Hotpath-Schleife ist strikt über IsEnabled() zu gaten, um Jitter durch String-Formatierung und IPC-Queues zu vermeiden.
• Manifest-Konfiguration:
  • Für den Daemon müssen in den Adaptive-Manifesten (Execution Manifest / Service Instance Manifest) Zugriffsrechte auf den jeweiligen KeyValueStorage-Port von ara::per sowie die LogTraceProcessConfig für ara::log explizit modelliert werden.
• 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.