DEENESPTFRRUARHIKOZHNL
AUTOSAR_AP_EXP_SWArchitecture FIG-a58784c6f478bc6d 206 × 373 px 2 Release(s)

Figure 9.76: Interfaces for recovery

SHA-256 Inhalts-Fingerabdruck: a58784c6f478bc6dc5164b5b13c58aeb7fdd4372f5df72caef3df1656c0505d1

Im Versions-Explorer öffnen

Kanonischer Bildausschnitt (144 DPI WebP, gerendert aus Original-Vektorgrafik) · nicht öffentlich, nur mit Anmeldung und Freigabe
✦ KI-generierte Bildanalyse & technische Beschreibung Modell: gemini-3.8-flash (via agy) · Rezept figure-series@1 · erstellt am 2026-10-08

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.
      • «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. Fehlerbehandlung:
    • State Management verarbeitet den gemeldeten Überwachungsfehler und leitet entsprechende Wiederherstellungsmaßnahmen ein (z. B. Function Group State Transition via Execution Management oder Prozess-Neustart).
  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).

Versionsvergleich KI-generiert · gemini-3.8-flash (via agy)

R22-11 → R23-11 normative Änderung Vorgänger: FIG-86c868319a553b26
  • Platform Health Management::RecoveryAction: Die Methode + GetGlobalSupervisionStatus() wurde aus der Port-Schnittstelle entfernt.
R24-11 → R25-11 normative Änderung Nachfolger: FIG-c1bde4e24dcfadf2
  • State Management daemon-based: Die Beziehungsrichtung zur Schnittstelle RecoveryAction wurde umgekehrt; State Management greift nun als Klient über eine Abhängigkeitsbeziehung («use») auf die Schnittstelle zu (zuvor Schnittstellenbereitstellung via «aapProvidedPort»).
  • Platform Health Management daemon-based: Realisiert nun die Schnittstelle RecoveryAction über eine Schnittstellenrealisierung (gestrichelte Linie mit geschlossener, nicht ausgefüllter Pfeilspitze; zuvor Klient via «use»).
  • «aapProvidedPort»: Das Stereotyp am Port von State Management wurde entfernt.

Zugeordnete Anforderungen

Diese Angaben zeigt der Versions-Explorer.

Aus dem Dokument extrahierter Text & Kontext

Beschriftungen im Schaubild:

«aapFunctionalCluster» Platform Health Management daemon-based | «aapFunctionalCluster» | State Management daemon-based | «aapPortInterface,aapAPI» Platform Health Management:: | RecoveryAction | + Offer() + StopOffer() | «aapCallbackMethod» + RecoveryHandler() | «use» | «aapProvidedPort»

Begleitender Spezifikationstext:

Explanation of Adaptive Platform Software Architecture AUTOSAR AP R24-11 Name: SupervisedEntity Technology: Port interface Generated: No Meta-model interface type: PhmSupervisedEntityInterface Usage: Public API Description: This interface provides functions to report checkpoints to Platform Health Management. Operations: ReportCheckpoint Reports an occurrence of a checkpoint. 9.6.1.1.2 Interfaces for recovery Platform Health Management defines the RecoveryAction API to trigger a recovery action in case a supervision failed (see Figure 9.76). «aapFunctionalCluster» Platform Health Management daemon-based «aapFunctionalCluster» State Management daemon-based «aapPortInterface,aapAPI» Platform Health Management:: RecoveryAction + Offer() + StopOffer() «aapCallbackMethod» + RecoveryHandler() «use» «aapProvidedPort» Figure 9.76: Interfaces for recovery Name: RecoveryAction Technology: Port interface Generated: No Meta-model interface type: PhmRecoveryActionInterface Usage: Public API Description: This interface provides functions to control triggering of recovery actions, to determine the status of the supervision and a callback to perform recovery. Offer Enables potential invocations of the callback RecoveryHandler(). RecoveryHandler Callback to be invoked by Platform Health Management upon a supervision failure. The handler invocation needs to be enabled before using Offer(). Operations: StopOffer Disables potential invocations of the callback RecoveryHandler(). 126 of 250 Docume

Vorkommen in AUTOSAR-Releases (2)

Release Dokument Seite Nr. Bildunterschrift im Dokument
R23-11 AUTOSAR_AP_EXP_SWArchitecture S. 110 9.68 Figure 9.68: Interfaces for recovery
R24-11 AUTOSAR_AP_EXP_SWArchitecture S. 126 9.76 Figure 9.76: Interfaces for recovery