Figure 11.9: Scenario: Receive Notification

1. Diagrammtyp & Architektur-Kontext

• Diagrammtyp: UML 2.x Sequenzdiagramm (Interaktionsdiagramm) mit kombiniertem Fragment (alt).
• Architektur-Kontext: AUTOSAR Adaptive Platform (AP), Release R23-11, Functional Cluster Time Synchronization (ara::ts).
• Technischer Zweck: Spezifikation des ereignisgesteuerten Benachrichtigungsmechanismus (Observer-/Callback-Muster) zwischen einer Adaptive Application (Consumer) und dem Time Synchronization Slave Functional Cluster bei Statusänderungen, Zeitsprüngen (Leap Jumps) oder aktualisierten Anwenderdaten (User Data) einer synchronisierten Zeitbasis.

2. Komponenten, Entitäten & Schnittstellen

• Akteure / Lebenslinien:
  • Consumer: Adaptive Application: Anwendungsinstanz/Prozess im POSIX-Anwendungsraum der Adaptive Platform, die auf Ereignisse einer Zeitbasis reagiert.
  • «aapFunctionalCluster» Slave: Time Synchronization: Lokale Instanz des Functional Clusters für Zeitsynchronisation im Slave-Modus, zuständig für den Empfang von Zeitnachrichten, lokale Drift-/Offset-Kompensation und Statusverwaltung.
  • «aapFunctionalCluster» Master: Time Synchronization: Zeitgebende Instanz (lokal oder netzwerkweit über Ethernet/gPTP nach IEEE 802.1AS bzw. Generic Time Synchronization).
• Stereotypen:
  • «aapFunctionalCluster»: Kennzeichnet standardisierte funktionale Plattform-Cluster der AUTOSAR Adaptive Platform Architecture.
• Schnittstellen / Methoden:
  • RegisterStatusChangeNotifier(): Synchrone Registrierungsmethode der API (Consumer → Slave), um Callbacks für Statusflag-Änderungen zu abonnieren.
  • sync(): Asynchrone/ereignisbasierte Synchronisationsnachricht bzw. PTP-Ereignis (Master → Slave), welche Zeittelegramme übermittelt.
  • handleSynchronizationStatus() / handleLeapJump() / handleUserDataChanged(): Interne Zustandsverarbeitungsroutinen des Slaves.
  • InvokeStatusFlagNotifier(): Synchroner Callback-Aufruf (Slave → Consumer) zur Übermittlung des geänderten Statusflags.
  • UnregisterStatusChangeNotifier(): Synchrone Deregistrierungsmethode zur Freigabe des Callback-Handles.

3. Dynamisches Verhalten & Sequenzablauf

1. Initialisierung & Registrierung:
   • Der Consumer ruft synchron RegisterStatusChangeNotifier() am Time Synchronization Slave auf. Die Aktivierung am Slave bestätigt die erfolgreiche Registrierung des Notifiers.
2. Netzwerk-Trigger:
   • Der Time Synchronization Master sendet eine sync()-Interaktion (z. B. PTP Sync / Follow_Up Frame) an den Slave.
3. Bedingte interne Auswertung (alt-Fragment):
   • Abhängig vom Inhalt des Telegramms und internem Tracking triggert der Slave genau einen der drei Guard-Pfade:
     • [Synchronization status changed]: Aufruf von handleSynchronizationStatus() bei Änderung des Sync-Zustands (z. B. Wechsel von kSynchronized auf kSyncLoss oder Timeout).
     • [Leap Jump]: Aufruf von handleLeapJump() bei Überschreitung des konfigurierten Schwellenwerts für sprunghafte Zeitkorrekturen.
     • [User Data Changed]: Aufruf von handleUserDataChanged() bei Änderung der im Zeittelegramm eingebetteten nutzerspezifischen Zusatzdaten (z. B. TLVs).
4. Ereignis-Notification (Callback):
   • Nach Durchlauf der internen Behandlung feuert der Slave InvokeStatusFlagNotifier() auf der Lebenslinie der Adaptive Application. Die Ausführung erfolgt synchron im Kontext des Notifier-Handlers.
5. Deregistrierung:
   • Bei Beendigung oder Wegfall des Überwachungsbedarfs ruft der Consumer synchron UnregisterStatusChangeNotifier() auf, um Callbacks zu stoppen und Ressourcen freizugeben.

4. Normative Relevanz & Entwickler-Hinweise

• API-Vertrag & Reentrancy:
  • Die Registrierung (RegisterStatusChangeNotifier) ist zwingende Vorbedingung für den Empfang jeglicher asynchroner Statusmeldungen.
  • Der Callback (InvokeStatusFlagNotifier) darf den ausführenden Thread des Time Synchronization Stacks nicht blockieren (Non-Blocking Contract), um Synchronisationsjitter des PTP-Engines zu vermeiden.
• Leap Jump Handling:
  • Applikationen, die zeitsensitive Regelkreise oder monotone Zeitstempel verwenden, müssen den [Leap Jump]-Zustand explizit abfangen, da hier Zeitdiskontinuitäten (z. B. Schaltsekunden oder sprunghafte Master-Korrekturen) vorliegen.
• Lebenszyklus- & Thread-Sicherheit:
  • Vor Zerstörung des Consumer-Objekts bzw. Terminierung der Adaptive Application muss UnregisterStatusChangeNotifier() garantiert aufgerufen werden (Dangling-Pointer- / UAF-Prävention auf OS-Thread-Ebene).