Figure 11.14: 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.
  • «aapInformative»: Kennzeichnet Interaktionen bzw. interne Methodenaufrufe mit rein informatorischem/erläuterndem Charakter ohne normative Implementierungsverpflichtung.
• 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.
  • «aapInformative» handleSynchronizationStatus() / «aapInformative» handleLeapJump() / «aapInformative» handleUserDataChanged(): Interne Verarbeitungsroutinen des Slaves, explizit als informativ gekennzeichnet.
  • 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

• Normative Einstufung: Erläuterndes Sequenzdiagramm aus EXP_SWArchitecture. Durch die explizite Hinzufügung des Stereotyps «aapInformative» an den internen Selbstaufrufen handleSynchronizationStatus(), handleLeapJump() und handleUserDataChanged() wird klargestellt, dass deren Ausführung rein exemplarisch ist und keine normative Vorgabe für die interne Slave-Architektur darstellt. Verbindlich normiert sind weiterhin die Methoden RegisterStatusChangeNotifier(), UnregisterStatusChangeNotifier() und das Callback-Verhalten von InvokeStatusFlagNotifier() gemäß SWS Time Synchronization (ara::ts).
• Entwickler- & Integrationshinweise:
  • Vorbedingung für den Benachrichtigungsempfang bleibt der synchrone Aufruf von RegisterStatusChangeNotifier().
  • Da die internen Handler explizit als «aapInformative» markiert sind, steht Plattform-Implementierern die genaue interne Kapselung der Statusevaluierung frei.
  • Der anwendungsseitige Handler für InvokeStatusFlagNotifier() darf nicht blockieren.
  • Vor dem Beenden der Applikation ist UnregisterStatusChangeNotifier() aufzurufen.