DEENESPTFRRUARHIKOZHNL
AUTOSAR_AP_SWS_StateManagement FIG-eb88b8b547533d9a 438 × 435 px 1 Release(s)

Figure 5.1: Interfaces provided by State Management to other Functional Clusters

SHA-256 Inhalts-Fingerabdruck: eb88b8b547533d9a5193d03a43ca0952111fa537e2f2430ef6f614fad6dc733d

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-Klassendiagramm / Komponentendiagramm zur Darstellung der Schnittstellenbeziehungen der AUTOSAR Adaptive Platform. Das Diagramm spezifiziert die vom Functional Cluster State Management für die Functional Cluster Update and Configuration Management und Platform Health Management bereitgestellten Schnittstellen (Provided Ports) und deren Nutzung über Required Ports.

2. Komponenten, Entitäten & Schnittstellen

Das Diagramm definiert drei als «aapFunctionalCluster» typisierte funktionale Cluster (jeweils mit Eigenschaft daemon-based):

  • State Management (untere Ebene)
  • Update and Configuration Management (obere Ebene links)
  • Platform Health Management (obere Ebene rechts)

Dazwischen liegen zwei Schnittstellendefinitionen:

  • UpdateRequest mit Stereotypen «aapAraComServiceInterface, aapInterface...»:
    • Feld-Bereich «aapAccessControlled, aapServiceField...»: + ResetMachineNotifier
    • Methoden-Bereich «aapAccessControlled, aapServiceMethod...»: + PrepareRollback(), + PrepareUpdate(), + RequestUpdateSession(), + ResetMachine(), + StopUpdateSession(), + VerifyUpdate()
    • Realisierung / Bereitstellung durch State Management über «aapProvidedPort» (gestrichelte Linie mit geschlossener Pfeilspitze).
    • Nutzung durch Update and Configuration Management über «aapRequiredPort» mit «use» (durchgezogene Linie mit offener Pfeilspitze).
  • RecoveryAction mit Stereotypen «aapPortInterface, aapAPI»:
    • Methoden: + Offer(), + StopOffer()
    • Stereotypbereich «aapCallbackMethod»: + RecoveryHandler()
    • Realisierung / Bereitstellung durch State Management über «aapProvidedPort» (gestrichelte Linie mit geschlossener Pfeilspitze).
    • Nutzung durch Platform Health Management über «use» (durchgezogene Linie mit offener Pfeilspitze).

3. Dynamisches Verhalten & Sequenzablauf

Interaktionsmuster über funktionale Cluster-Grenzen hinweg:

  • Update and Configuration Management steuert Aktualisierungsprozesse über das servicebasierte Interface UpdateRequest (Sitzungsanforderung, Update- und Rollback-Vorbereitung, Verifikation und Maschinenreset). Zusätzlich existiert mit dem Feld ResetMachineNotifier ein Benachrichtigungsmechanismus für Maschinenreset-Ereignisse.
  • Platform Health Management triggert bei erkannten Systemzuständen Wiederherstellungsaktionen über RecoveryAction, wobei State Management den Callback RecoveryHandler() bereitstellt und über Offer()/StopOffer() die Verfügbarkeit steuert.

4. Normative Relevanz & Entwickler-Hinweise

Architektur- und Implementierungsvorgaben für Adaptive Platform Daemons:

  • State Management fungiert als Server/Provider für zwei funktionale Schnittstellen (UpdateRequest und RecoveryAction).
  • Einsatz einer ara::com-Service-Schnittstelle («aapAraComServiceInterface») für UpdateRequest, die Methoden und Felder mit Zugriffskontrolle («aapAccessControlled») kombiniert.
  • Einsatz einer portbasierten C++-API («aapPortInterface, aapAPI») für RecoveryAction mit Server-seitigem Offer-Lifecycle (Offer(), StopOffer()) und Client-seitiger Callback-Registrierung.
  • Alle beteiligten Einheiten sind als eigenständige Daemons konzipiert.

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

R23-11 → R24-11 normative Änderung Vorgänger: FIG-5394fab9ce388fa5
  • Der Functional Cluster Diagnostic Management und das von State Management bereitgestellte Interface EcuResetRequest (mit den Operationen EnableRapidShutdown(), ExecuteReset(), Offer(), RequestReset(), StopOffer()) sowie die zugehörigen Port-Verbindungen entfallen.
  • Im Interface UpdateRequest wird das Service-Feld ResetMachineNotifier («aapAccessControlled, aapServiceField...») hinzugefügt.
R24-11 → R25-11 normative Änderung Nachfolger: FIG-aaa6de398d06d45a
  • Die Rollenverteilung an der Schnittstelle RecoveryAction kehrt sich um: Platform Health Management stellt nun das Interface über einen Provided-Port bereit (gestrichelte Linie mit geschlossener Pfeilspitze zeigt auf RecoveryAction), während State Management die Schnittstelle als Required-Port verwendet (durchgezogene Linie mit offener Pfeilspitze und Stereotyp «use»).

Zugeordnete Anforderungen

Diese Angaben zeigt der Versions-Explorer.

Aus dem Dokument extrahierter Text & Kontext

Beschriftungen im Schaubild:

«aapFunctionalCluster» | State Management daemon-based | «aapAraComServiceInterface,aapInte... | UpdateRequest | «aapAccessControlled, aapServiceFie... + ResetMachineNotifier | «aapAccessControlled, aapServiceMe... + PrepareRollback() + PrepareUpdate() + RequestUpdateSession() + ResetMachine() + StopUpdateSession() + VerifyUpdate() | «aapPortInterface,aapAPI» | RecoveryAction | + Offer() + StopOffer() | «aapCallbackMethod» + RecoveryHandler() | «aapFunctionalCluster» Platform Health Management | daemon-based | «aapFunctionalCluster» Update and Configuration | Management daemon-based | «aapProvidedPort» «aapProvidedPort» | «use» «aapRequiredPort» «use»

Begleitender Spezifikationstext:

Specification of State Management AUTOSAR AP R24-11 5 Dependencies to other Functional Clusters This chapter provides an informative guideline of the interaction of State Management with other Functional Clusters in the AUTOSAR Adaptive Platform. Section 5.1 “Provided Interfaces” lists the public interfaces provided by State Management to other Functional Clusters. Section 5.2 “Required Interfaces” lists the public interfaces required by State Management. The goal is to provide a clear understanding of Functional Cluster boundaries and interaction, without specifying syntactical details. This ensures compatibility between documents specifying different Functional Clusters and supports parallel implementation of different Functional Clusters. Details of internal interfaces are up to the platform provider. Additional internal interfaces, parameters and return values can be added. A detailed technical architecture documentation of the overall AUTOSAR Adaptive Platform is provided in [12]. 5.1 Provided Interfaces «aapFunctionalCluster» State Management daemon-based «aapAraComServiceInterface,aapInte... UpdateRequest «aapAccessControlled, aapServiceFie... + ResetMachineNotifier «aapAccessControlled, aapServiceMe... + PrepareRollback() + PrepareUpdate() + RequestUpdateSession() + ResetMachine() + StopUpdateSession() + VerifyUpdate() «aapPortInterface,aapAPI» RecoveryAction + Offer() + StopOffer() «aapCallbackMethod» + RecoveryHandler() «aapFunctionalCluster» Platform Health Managem

Vorkommen in AUTOSAR-Releases (1)

Release Dokument Seite Nr. Bildunterschrift im Dokument
R24-11 AUTOSAR_AP_SWS_StateManagement S. 14 5.1 Figure 5.1: Interfaces provided by State Management to other Functional Clusters