Figure 5.1: A basic application State transition example

1. Diagrammtyp & Architektur-Kontext

• Diagrammtyp: UML-Sequenzdiagramm (sd Application State transition(asynchronous)).
• Architektur-Kontext: AUTOSAR Adaptive Platform (AP), Functional Cluster State Management (ara::sm).
• Funktionaler Zweck: Modellierung einer asynchronen, vollständig entkoppelten Zustandsüberführung zwischen zwei AUTOSAR Adaptive Applications (AAs) über das State Management unter Verwendung Service-orientierter Kommunikation (ara::com).

2. Komponenten, Entitäten & Schnittstellen

• Application1: Client-/Trigger-Applikation; fungiert als Initiator einer Zustandsänderung (z. B. HMI, Diagnose-Client oder externer Event-Detektor).
• State Management: Zentraler Plattform-Orchestrator zur Verwaltung von Maschinen-, Funktionsgruppen- und Applikationszuständen.
  • TriggerIn: Eingehender Port/Skeleton-Endpunkt zur Entgegennahme von Zustandswechsel-Anforderungen via ara::com.
  • Core Logic (State Engine): Interne Zustandsmaschine zur Überprüfung von Transitionen und Systemintegrität.
  • TriggerOut: Ausgehender Port/Event-Publisher-Endpunkt zur Notifizierung abhängiger Prozesse über erreichte Zustände.
• Application2: State-Consumer/Worker-Applikation; passt ihr Betriebsverhalten an den vom State Management gemeldeten Systemzustand an.
• Kommunikationsbeziehungen:
  • Loose Kopplung über Publish/Subscribe- und Event-Mechanismen (ara::com).
  • Keine direkte Punkt-zu-Punkt-Abhängigkeit zwischen Application1 und Application2.

3. Dynamisches Verhalten & Sequenzablauf

1. Subscription-Phase (Prä-Kondition):
   • Application2 registriert sich mittels subscribe() asynchron am Ausgangsport TriggerOut auf Zustandsereignisse.
2. Trigger-Eingang:
   • Application1 initiiert den Vorgang via write() auf die Schnittstelle TriggerIn.
   • TriggerIn delegiert den Trigger über ein internes Signal event() an die Kernlogik des State Managements.
3. Zustandsvalidierung (Guard Evaluation):
   • Das State Management führt synchron checkGuardCondition(s) aus (Validierung von Vorbedingungen, Safety-Integrität, Abhängigkeiten und aktuellem Systemkontext).
4. Transition & Zustands-Publikation:
   • Bei erfolgreicher Guard-Prüfung übergibt der State-Management-Kern den neuen Zustand via write(state) an den Port TriggerOut.
5. Asynchrone Notifikation & Ausführung:
   • TriggerOut propagiert den Zustandswechsel über event() an abonnierte Konsumenten.
   • Application2 empfängt das Event und initiiert die zustandsspezifische Verhaltensänderung (do something()).

4. Normative Relevanz & Entwickler-Hinweise

• API- & Architektur-Vertrag:
  • Applikationen dürfen Zustände weder direkt anfordern noch untereinander aushandeln; der Kontrollfluss muss zwingend über die Guard-Logik des State Managements kanalisiert werden.
  • Die Entkopplung erfordert non-blocking Event-Handler (z. B. über ara::com::Event::SetReceiveHandler oder Event-Polling-Mechanismen).
• Guard-Condition-Design:
  • Guards im State Management müssen deterministisch und zeitinvariant implementiert sein. Schlägt eine Guard-Bedingung fehl, bricht die Kette ab, ohne dass write(state) ausgelöst wird (stilles Verwerfen oder dediziertes Error-Handling erforderlich).
• Echtzeit- und Latenz-Einschränkungen:
  • Der Ablauf ist vollständig asynchron. Entwickler dürfen keine Annahmen über synchrone Reaktionszeiten von Application2 relativ zum Aufruf von Application1 treffen. Quittierungen müssen bei Bedarf als explizite Rückmelde-Events modelliert werden.