Figure 7.4: Non-Synchronized Application State handling

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: UML 2.x Sequenzdiagramm (sd Application State transition(asynchronous)).
• Kontext & Spezifikation: AUTOSAR Adaptive Platform (AP), spezifiziert in AUTOSAR_AP_SWS_StateManagement (Kapitel 7, Functional Specification).
• Technischer Zweck: Spezifikation des nicht-synchronisierten, ereignisgesteuerten Zustandswechsels auf Applikationsebene (Non-Synchronized Application State Handling).
• Funktionale Einordnung: Dient der asynchronen Koordination von Anwendungszuständen zwischen entkoppelten Adaptive Applications via State Management (SM). Im Gegensatz zu synchronisierten Zustandswechseln (z. B. Function Group States via Execution Management mit striktem Handshake/Quittierung) agiert SM hier als zustandsprüfender Broker (Rule Engine): Ein eingehender Trigger wird gegen Guards validiert und als State-Event ohne Blockierung oder Ausführungsbestätigung an Konsumenten verteilt (Fire-and-Forget / Publish-Subscribe).

2. Komponenten, Entitäten & Schnittstellen

• Application1: Adaptive Application (Initiator / Trigger-Quelle). Agiert als Service Consumer bzw. Producer eines Zustandstriggers.
• State Management (Zentraler Funktions-Cluster / Daemon):
  • TriggerIn: Eingangs-Port / Schnittstellen-Adapter (Provided Service Interface / Skeleton) zur Entgegennahme von externen Trigger-Ereignissen oder Steuerungsanforderungen.
  • SM-Core (Zentrale Lebenslinie): Interne Zustandsmaschine bzw. Regel-Engine zur Zustandshaltung und Auswertung logischer Guard-Bedingungen.
  • TriggerOut: Ausgangs-Port / Service-Schnittstelle (Provided Service Interface / Skeleton) zur Verteilung von Zustandsaktualisierungen via Events oder Fields.
• Application2: Adaptive Application (Konsument / Rezipient). Empfängt Statusänderungen und leitet daraus lokale Aktionen ab.
• Schnittstellen & Interaktionstypen:
  • Kommunikationsparadigma: Serviceorientierte Kommunikation via ara::com.
  • Kardinalität: 1:n-Publish/Subscribe am Ausgang (TriggerOut bedient potenziell mehrere subskribierte Applikationen).

3. Dynamisches Verhalten & Sequenzablauf

1. Abonnement (subscribe):
   • Vorab subskribiert Application2 asynchron den Event-/Field-Port TriggerOut an der SM-Instanz (subscribe()).
2. Trigger-Einspeisung (write / event):
   • Application1 ruft write() auf dem Eingangs-Endpunkt TriggerIn auf.
   • TriggerIn leitet den Aufruf als internes event() an den SM-Kern weiter.
3. Validierung (checkGuardCondition(s)):
   • Der SM-Kern führt einen synchronen Selbstaufruf checkGuardCondition(s) aus.
   • Prüfkriterien: Logische Vorbedingungen, aktuelle System-/Subsystemzustände, Abhängigkeiten oder Entprellungen.
4. Zustandspropagierung (write(state) / event):
   • Bei erfolgreicher Guard-Auswertung triggert der SM-Kern write(state) auf TriggerOut.
   • TriggerOut versendet ein asynchrones event() via ara::com an alle registrierten Abonnenten (Application2).
5. Applikationsverarbeitung (do something):
   • Application2 empfängt das Event im Dispatcher/Callback und führt autark die interne Aktion aus (do something()).

• Synchronisationsverhalten & Abbruch:
  • Streng asynchron: Keine Rückmeldung oder Quittierung von Application2 an SM oder Application1.
  • Scheitert checkGuardCondition(s), wird der Ablauf verworfen; write(state) unterbleibt ohne Benachrichtigung des Initiators.

4. Normative Relevanz & Entwickler-Hinweise

• Architektur-Constraint (Eventual Consistency):
  • Nicht zulässig für sicherheitskritische Zustandswechsel (z. B. ASIL-relevante Degrationspfade oder Not-Halt), bei denen der Abschluss der Transition garantiert vor Folgeschritten eintreten muss. Dafür ist das synchrone Function Group State Handling via Execution Management (ara::exec) vorgeschrieben.
  • Application1 darf nach write() keine Annahmen über den Fertigstellungszeitpunkt oder den tatsächlichen Erfolg in Application2 treffen (Race Condition-Gefahr).
• Service Deployment & Manifeste:
  • TriggerIn und TriggerOut müssen im Service Interface Deployment und Execution Manifest als Port-Interfaces sauber typisiert und zugeordnet sein (ara::com Event- oder Field-basierte Schnittstellen).
• Echtzeit- & Threading-Regeln:
  • Der Event-Handler in Application2 darf keine blockierenden Operationen im Kontext des ara::com-Worker-Threads ausführen (do something() muss rechenzeitbeschränkt sein oder Aufgaben an anwendungseigene Worker-Threads delegieren).
• Fehlerbehandlung:
  • Da keine synchrone Fehlerübertragung an Application1 existiert, müssen Fehlschläge von Guards im State Management über ara::log erfasst oder über separate Diagnose-/Health-Monitoring-Kanäle (ara::phm) gemeldet werden.