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

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

SHA-256 Inhalts-Fingerabdruck: aaa6de398d06d45ac20b456c4747dc08b40ec075a352dd4db8f0a1cf7bbcc0b7

✦ 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 zwischen dem Functional Cluster State Management und den Functional Clustern Update and Configuration Management sowie Platform Health Management. Das Diagramm zeigt die Zuordnung von Provided- und Required-Ports für die jeweiligen Cluster.

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()
- 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()
- Bereitstellung durch Platform Health Management als Provided Port (gestrichelte Linie mit geschlossener Pfeilspitze).
- Nutzung durch State 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). Über das Feld ResetMachineNotifier werden Benachrichtigungen zu Maschinenresets ausgetauscht.
An der Schnittstelle RecoveryAction stellt Platform Health Management das Interface bereit, während State Management die Schnittstelle als Client nutzt («use»). RecoveryAction enthält Lebenszyklus-Methoden (Offer(), StopOffer()) sowie die Callback-Methode RecoveryHandler().

4. Normative Relevanz & Entwickler-Hinweise

Architektur- und Implementierungsvorgaben für Adaptive Platform Daemons:

State Management fungiert als Provider für die ara::com-Service-Schnittstelle UpdateRequest («aapAraComServiceInterface») inklusive Zugriffskontrolle («aapAccessControlled») für Methoden und das Feld ResetMachineNotifier.
State Management bindet die Port-Schnittstelle RecoveryAction («aapPortInterface, aapAPI») als Consumer («use») ein, während Platform Health Management als Provider der Schnittstelle fungiert.
Alle beteiligten Einheiten sind als eigenständige Daemons konzipiert.

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

R24-11 → R25-11 normative Änderung Vorgänger: FIG-eb88b8b547533d9a

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:

Begleitender Spezifikationstext:

Specification of State Management AUTOSAR AP R25-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
R25-11	AUTOSAR_AP_SWS_StateManagement	S. 16	5.1	Figure 5.1: Interfaces provided by State Management to other Functional Clusters