DEENESPTFRRUARHIKOZHNL
AUTOSAR_SWS_ExecutionManagement FIG-962f831032e8601f 932 × 880 px 1 Release(s)

Figure 7.9: Adaptive Platform - Recovery Action Architecture

SHA-256 Inhalts-Fingerabdruck: 962f831032e8601ff009efa6d7160156e444d6566bfa64e6354b39b8182f08f8

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

UML-Komponentendiagramm (cmp Component View Recovery Actions) zur Architektur der Wiederherstellungsmaßnahmen (Recovery Actions) in der AUTOSAR Adaptive Platform. Das Diagramm spezifiziert das Zusammenspiel und die Schnittstellenbeziehungen zur Laufzeitüberwachung und Fehlerbehebung zwischen Applikationsebene, Plattformüberwachung (Platform Health Management) und Prozessverwaltung (Execution Management).

2. Komponenten, Entitäten & Schnittstellen

Komponenten:

  • Application: Funktionale Adaptive Application.
  • Platform Health Management: Plattforminstanz zur Überwachung des System- und Anwendungszustands.
  • Execution Management: Plattformkomponente zur Prozesssteuerung und Lebenszyklusverwaltung.

Klassen / Schnittstellenbausteine:

  • «ara::exec» RecoveryActionClient: Schnittstelle mit den Operationen + OverrideState() und + RestartProcess().
  • «ara::exec» ApplicationClient: Schnittstelle mit der Operation + ReportApplicationState().

Ports und Interfaces:

  • ApplicationClient: Bereitgestellt als Required-Port von Application und Platform Health Management, verbunden mit dem Provided-Port von Execution Management über die Client-Klasse ApplicationClient.
  • RecoveryActionClient: Bereitgestellt als Required-Port von Platform Health Management, verbunden mit dem Provided-Port von Execution Management über die Client-Klasse RecoveryActionClient.

3. Dynamisches Verhalten & Sequenzablauf

  • Statusmeldung: Application und Platform Health Management melden ihren Ausführungsstatus über ApplicationClient (ReportApplicationState()) an Execution Management.
  • Fehlererkennung & Überwachung: Platform Health Management überwacht Application sowie Execution Management über Kontrollbeziehungen (Monitor).
  • Wiederherstellung & Intervention: Bei Fehlern fordert Platform Health Management über RecoveryActionClient Recovery-Aktionen bei Execution Management an (OverrideState() oder RestartProcess()).
  • Lebenszyklussteuerung: Execution Management startet und terminiert Prozesse von Application sowie Platform Health Management (Start / Terminate).

4. Normative Relevanz & Entwickler-Hinweise

  • Normative Architekturvorgabe für Adaptive Platform Implementierungen zur Trennung von Zustandsüberwachung (Platform Health Management) und Ausführungssteuerung (Execution Management).
  • Für Entwickler relevant ist die Nutzung des standardisierten C++-API ara::exec (ApplicationClient für Zustandsberichte an den Execution Manager sowie RecoveryActionClient für plattforminterne Wiederherstellungsanforderungen).

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

R17-10_R1.2.0 → R18-03_R1.4.0 normative Änderung Nachfolger: FIG-c7227369a8d3b124
  • Interaktionsmodell zwischen Platform Health Management und Execution Management aufgeteilt: Das Interface RecoveryActionClient (OverrideState(), RestartProcess()) wird durch zwei getrennte Schnittstellen mit dem Stereotyp «IFC Interface» ersetzt: Request Process Restart mit # *RestartProcess*() und Request Immediate State Transition mit # *OverrideState*().
  • Die Ports und Schnittstellenbezeichnungen zwischen PHM und EM wurden entsprechend aufgeteilt in zwei separate Port-/Interface-Verbindungen.

Zugeordnete Anforderungen

Diese Angaben zeigt der Versions-Explorer.

Vorkommen in AUTOSAR-Releases (1)

Release Dokument Seite Nr. Bildunterschrift im Dokument
R17-10_R1.2.0 AUTOSAR_SWS_ExecutionManagement S. 40 7.9 Figure 7.9: Adaptive Platform - Recovery Action Architecture