Figure 7.3: Interaction between S2RSatellite and S2RHub

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: UML-Komponenten- und Kollaborationsdiagramm (Architektur-Interaktionsmodell mit Port-/Interface-Konnektoren nach AUTOSAR-Metamodell-Semantik).
• Technischer Zweck: Spezifikation des entkoppelten Abfrage- und Rückmeldemechanismus für den Sicherheits- und Bereitschaftsstatus (Safe-to-Run / S2R) zwischen dem zentralen Plattform-Cluster State Management (SM) und den über das Execution Management (EM) gestarteten Applikationsprozessen.
• Funktionale Einordnung: Verankert in der AUTOSAR Adaptive Platform (AP) unter AUTOSAR_AP_SWS_StateManagement (Kapitel 7.3, R25-11). Das Muster dient dazu, vor oder während koordinierter Zustandswechsel (z. B. Function Group Transitions, Machine State Changes, De-Escalation, Shutdown/Reset) eine synchrone/asynchrone Statusvalidierung über Prozessgrenzen hinweg ohne Punkt-zu-Punkt-Kopplung durchzuführen.

2. Komponenten, Entitäten & Schnittstellen

• State Management (S2R Hub):
  • Rolle: Zentrale Steuerungs- und Aggregationsinstanz innerhalb des Functional Clusters State Management.
  • Schnittstellen-Semantik: Besitzt einen Receptive Port (Socket-Symbol ( / Client-/Consumer-Charakteristik für Antworten; Initiator für Broadcast/Multicast-Requests).
• Executable launched as Process (S2R Satellite):
  • Rolle: Dezentrale Agenten-/Bibliothekskomponente innerhalb des Adressraums jedes instanziierten Applikationsprozesses (Kardinalität 1 … N, im Diagramm exemplarisch mit 2 Instanzen dargestellt).
  • Schnittstellen-Semantik: Besitzt einen Provided Port (Ball-Symbol O / Server- bzw. Provider-Charakteristik für die Bereitstellung des lokalen Prozesszustands).
• Konnektoren & Kommunikationspfade:
  • Multicast Request (gestrichelte Linie, 1-zu-N-Auffächerung): Unidirektionaler Request-Kanal vom Hub an alle relevanten Satelliten (realisiert über IPC-Multicast, Publish/Subscribe-Event oder Broadcast-Socket).
  • Unicast Response (durchgezogene Linien, N-zu-1-Rückführung): Unidirektionale Punkt-zu-Punkt-Antwortkanäle von jedem einzelnen Satelliten zurück zum Hub (realisiert über deterministische IPC-Queues, Unix Domain Sockets oder Methoden-Returns).

3. Dynamisches Verhalten & Sequenzablauf

1. Trigger: State Management initiiert eine Zustandsänderung (FunctionGroupState oder MachineState) oder evaluiert periodische/ereignisgesteuerte Sicherheitsbedingungen (RS_SM_00402).
2. Request Fan-Out (SWS_SM_00684):
   • Der S2R Hub sendet einen synchronen oder asynchronen Multicast Request an alle registrierten S2R Satellites.
   • Vermeidet sequentielle Round-Trip-Latenzen (O(1)-Versandaufwand bezüglich des Initiators).
3. Lokale Zustandsermittlung:
   • Jeder Prozess wertet über den eingebetteten S2R Satellite seine internen Vorbedingungen aus (z. B. Ressourcenintegrität, Pufferentleerung, ASIL-Status, deterministischer Checkpoint-Zustand).
4. Response Fan-In (SWS_SM_00706):
   • Jeder S2R Satellite formuliert unabhängig eine Unicast Response mit dem qualifizierten Status (z. B. Safe, Not Safe, Fehlerschlüssel) und sendet diese direkt an den S2R Hub.
5. Aggregation & Timeout-Handling (SWS_SM_00714):
   • Der S2R Hub sammelt alle Antworten innerhalb eines strikt konfigurierten Zeitfensters (Deadline/Timeout).
   • Abbruch-/Fehlerpfad: Antwortet ein Satellit nicht rechtzeitig oder meldet Not Safe, bricht der S2R Hub die Zustandsüberführung ab und triggert die hinterlegte Recovery-Strategie (z. B. Eskalation an das Platform Health Management (PHM), Rollback oder Übergang in den Safe State).
   • Erfolgspfad: Treffen alle erwarteten Positiv-Quoten/Acks ein, vollzieht State Management den Moduswechsel.

4. Normative Relevanz & Entwickler-Hinweise

• API-Vertrag & Callback-Implementierung: Applikationsentwickler müssen den S2R Satellite über die vorgesehene Middleware-Schnittstelle in der Prozess-Hauptschleife bedienen. Die Ermittlung des Safe-to-Run-Status muss absolut nicht-blockierend sein und ein striktes Worst-Case Execution Time (WCET)-Budget einhalten, um Hub-Timeouts zu verhindern.
• Manifest- & Prozess-Konfiguration:
  • Im Execution Manifest / State Management Manifest muss deklariert werden, welche Executables als S2R-Teilnehmer fungieren und welche Timeouts für die Multicast-to-Unicast-Runde gelten (SWS_SM_00714).
  • Nicht alle Prozesse eines Adaptive Systems müssen zwingend einen S2R Satellite instanziieren; die Bindung erfolgt rollenbasiert je nach Sicherheitsintegritätslevel (ASIL) und Relevanz für den Zustandsübergang.
• Stack-Entwicklung (IPC & OS): Der zugrundeliegende IPC-Transport für Multicast Request muss Prioritätsinversion ausschließen. Fehlt native OS-Multicast-Unterstützung für Shared-Memory/IPC, muss die State-Management-Plattformschicht den Fan-Out deterministisch und verzögerungsarm virtualisieren.