DEENESPTFRRUARHIKOZHNL
AUTOSAR_AP_EXP_SWArchitecture FIG-c1bde4e24dcfadf2 206 × 373 px 1 Release(s)

Figure 9.81: Interfaces for recovery

SHA-256 Inhalts-Fingerabdruck: c1bde4e24dcfadf204105863dcc1bbf95c244384468b67a93846d12ce4bbf4e7

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» Platform Health Management (daemon-based): Überwachungsinstanz und Dienstanbieter; implementiert und realisiert die Schnittstelle RecoveryAction.
    • «aapFunctionalCluster» State Management (daemon-based): Zielinstanz für Wiederherstellungsaktionen; fungiert als Klient («use»-Abhängigkeit) der Schnittstelle RecoveryAction.
  • Port-Interface & Methoden:
    • «aapPortInterface, aapAPI» Platform Health Management::RecoveryAction: Namensraum-zugehöriges Interface zur Fehlereskalation.
      • + Offer(): Aktiviert die Dienstbereitschaft der Recovery-Schnittstelle im Platform Health Management.
      • + StopOffer(): Zieht die Bereitstellung des Recovery-Services im Platform Health Management zurück.
      • «aapCallbackMethod» + RecoveryHandler(): Callback-Methode zur Signalisierung von Überwachungsfehlern an das State Management.
  • Beziehungssemantik:
    • Platform Health Management implementiert die Schnittstelle über eine Schnittstellenrealisierung (gestrichelte Linie mit weißer Dreiecksspitze).
    • State Management bindet die Schnittstelle via «use» an und konsumiert den Dienst.

3. Dynamisches Verhalten & Sequenzablauf

  1. Initialisierung & Service Offering:
    • Platform Health Management startet im Systemstart und ruft Offer() auf, um den Dienst RecoveryAction bereitzustellen.
  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 (Callback-Pfad):
    • PHM initiiert den Aufruf der Callback-Methode 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 Platform Health 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)

R24-11 → R25-11 normative Änderung Vorgänger: FIG-a58784c6f478bc6d
  • 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»

Begleitender Spezifikationstext:

Explanation of Adaptive Platform Software Architecture AUTOSAR AP R25-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.81). «aapFunctionalCluster» Platform Health Management daemon-based «aapFunctionalCluster» State Management daemon-based «aapPortInterface,aapAPI» Platform Health Management:: RecoveryAction + Offer() + StopOffer() «aapCallbackMethod» + RecoveryHandler() «use» Figure 9.81: 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 Recovery Handler(). 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 Recovery Handler(). 129 of 269 Document ID 982: AUTOS

Vorkommen in AUTOSAR-Releases (1)

Release Dokument Seite Nr. Bildunterschrift im Dokument
R25-11 AUTOSAR_AP_EXP_SWArchitecture S. 129 9.81 Figure 9.81: Interfaces for recovery