Figure 9.66: Interfaces for recovery

1. Diagrammtyp & Architektur-Kontext

• Diagrammtyp: UML-Klassendiagramm / Komponentenschnittstellendiagramm (AUTOSAR Adaptive Platform Profil mit «aap...»-Stereotypen).
• Architektur-Kontext: Interaktion zwischen den funktionellen Clustern Platform Health Management (PHM) und State Management (SM) auf der AUTOSAR Adaptive Platform (Release R21-11).
• Funktionaler Zweck: Bereitstellung eines standardisierten Recovery-Mechanismus bei Überwachungsfehlern (Alive-, Deadline-, Logical- oder Health-Channel-Supervision). Scheitert eine Überwachung in PHM, delegiert PHM die Einleitung von Fehlerbehebungsmaßnahmen (z. B. Prozess-Neustart, Zustandsübergang in Safe State) über die Schnittstelle RecoveryAction an das State Management.

2. Komponenten, Entitäten & Schnittstellen

• Akteure / Funktionale Cluster:
  • «aapFunctionalCluster» State Management (daemon-based): Zielinstanz für Wiederherstellungsaktionen; realisiert und exponiert den Server-Port («aapProvidedPort») für die Recovery-Logik.
  • «aapFunctionalCluster» Platform Health Management (daemon-based): Überwachungsinstanz; fungiert als Klient («use»-Abhängigkeit) und ruft Recovery-Aktionen bei erkannten Anomalien auf.
• Port-Interface & Methoden:
  • «aapPortInterface, aapAPI» Platform Health Management::RecoveryAction: Namensraum-zugehöriges Interface zur Fehlereskalation.
    • + Offer(): Aktiviert die Dienstbereitschaft der Recovery-Schnittstelle im State Management.
    • + StopOffer(): Zieht die Bereitstellung des Recovery-Services zurück.
    • + GetGlobalSupervisionStatus(): Ermöglicht das synchrone Abfragen des aggregierten Überwachungsstatus aller überwachten Entitäten durch das State Management.
    • «aapCallbackMethod» + RecoveryHandler(): Asynchroner Benachrichtigungskanal/Callback, über den PHM das Eintreffen eines Überwachungsfehlers (Supervision Failure) an State Management meldet.
• Beziehungssemantik:
  • State Management implementiert den Port («aapProvidedPort»), d. h. SM stellt die Handler-Logik bereit.
  • PHM bindet die Schnittstelle via «use» an, konsumiert den Service und triggert den RecoveryHandler().

3. Dynamisches Verhalten & Sequenzablauf

1. Initialisierung & Service Offering:
   • SM startet im Systemstart und ruft Offer() auf, um die Bereitschaft zur Entgegennahme von Recovery-Triggern zu signalisieren.
2. Überwachung & Fehlerdetektion:
   • PHM erfasst Checkpoints von Adaptive Applications (SupervisedEntity.ReportCheckpoint()).
   • Bei Verletzung von Timing-, Sequenz- oder Lebendigkeitsbedingungen wechselt der interne Status auf EXPIRED / STOPPED.
3. Triggering der Recovery Action (asynchroner Pfad):
   • PHM initiiert den Call an RecoveryHandler() am State Management (daemon-übergreifendes IPC).
   • Übergabeparameter umfassen typischerweise die Identifikation der fehlgeschlagenen Entität bzw. die konfigurierte Recovery-Aktions-ID.
4. Zustandsabfrage & Fehlerauflösung (synchroner Pfad):
   • SM fragt bei Bedarf über GetGlobalSupervisionStatus() den Gesamtzustand ab, um kontextabhängige Zustandswechsel (z. B. Function Group State Transition via Execution Management) einzuleiten.
5. Deinitialisierung:
   • Bei kontrolliertem Shutdown des State Managements wird der Dienst über StopOffer() deregistriert.

4. Normative Relevanz & Entwickler-Hinweise

• Architektur-Trennung: PHM entscheidet wann ein Fehler vorliegt, führt aber keine direkten Prozessabbrüche oder State-Transitions durch. Die Exekutivrechte zur Fehlerreaktion liegen exklusiv beim State Management (in Kooperation mit Execution Management).
• Daemon-IPC-Kopplung: Da beide Entitäten als Daemons realisiert sind, erfolgt der Aufruf von RecoveryHandler() über die plattformspezifische IPC-Bindung (z. B. ara::com Binding oder direkte Unix Domain Sockets / Shared Memory).
• Konfigurationsaspekt (ARXML):
  • PhmRecoveryActionInterface muss im Manifest als Service-Port definiert und zwischen der AdaptiveApplicationSwComponent des PHM und des SM instanziiert (ServiceInstanceToPortPrototypeMapping) werden.
  • Entwickler müssen sicherstellen, dass Timeouts auf RecoveryHandler() die Echtzeitanforderungen des Sicherheitskonzepts (FTTI – Fault Tolerant Time Interval) nicht verletzen.
• Fehlerbehandlung: Bietet SM keinen Service (Offer() ausstehend), muss PHM plattformspezifische Fallbacks vorsehen (z. B. direkter Hardware-Watchdog-Trigger bei Nicht-Erreichbarkeit des State Managements).