DEENESPTFRRUARHIKOZHNL
AUTOSAR_AP_SWS_StateManagement FIG-5394fab9ce388fa5 607 × 393 px 1 Release(s)

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

SHA-256 Inhalts-Fingerabdruck: 5394fab9ce388fa52404384281a1b68493b2a140a8f2c2e96c724f73628c9cfb

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 andere Functional Cluster (Diagnostic Management, Update and Configuration Management, Platform Health Management) bereitgestellten Schnittstellen (Provided Ports) und deren Nutzung über Required Ports im Rahmen der Plattform-Interaktion.

2. Komponenten, Entitäten & Schnittstellen

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

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

Dazwischen liegen drei Schnittstellendefinitionen:

  • EcuResetRequest mit Stereotypen «aapPortInterface, aapAPI»:
    • Methoden: + EnableRapidShutdown(), + ExecuteReset(), + Offer(), + RequestReset(), + StopOffer()
    • Realisierung / Bereitstellung durch State Management über «aapProvidedPort» (gestrichelte Linie mit geschlossener Pfeilspitze).
    • Nutzung durch Diagnostic Management über «aapRequiredPort» mit «use» (durchgezogene Linie mit offener Pfeilspitze).
  • UpdateRequest mit Stereotypen «aapAraComServiceInterface, aapInterface...»:
    • Stereotypbereich «aapAccessControlled, aapServiceMethod...» mit Methoden: + 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» mit Methode: + 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:

  • Diagnostic Management initiiert über EcuResetRequest Steuerungsbefehle an State Management für Reset-Vorgänge (Anfrage, Ausführung, Rapid Shutdown).
  • Update and Configuration Management steuert Aktualisierungsprozesse über das servicebasierte Interface UpdateRequest (Sitzungsanforderung, Update- und Rollback-Vorbereitung, Verifikation und Maschinenreset).
  • 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 muss als Server/Provider für drei funktionale Schnittstellen fungieren.
  • Trennung der Interaktionsparadigmen: direkte C++-API/Port-Schnittstellen («aapPortInterface, aapAPI» für EcuResetRequest und RecoveryAction) mit explizitem Offer-Lebenszyklus vs. ara::com-Service-Schnittstelle («aapAraComServiceInterface» für UpdateRequest) mit feingranularer Zugriffskontrolle («aapAccessControlled»).
  • Alle beteiligten Einheiten sind als eigenständige Daemons konzipiert.

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

R23-11 → R24-11 normative Änderung Nachfolger: FIG-eb88b8b547533d9a
  • 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.

Zugeordnete Anforderungen

Diese Angaben zeigt der Versions-Explorer.

Aus dem Dokument extrahierter Text & Kontext

Beschriftungen im Schaubild:

«aapFunctionalCluster» | State Management daemon-based | «aapFunctionalClust... Diagnostic Management | daemon-based | «aapPortInterface,aapAPI» | EcuResetRequest | + EnableRapidShutdown() + ExecuteReset() + Offer() + RequestReset() + StopOffer() | «aapAraComServiceInterface,aapInte... | UpdateRequest | «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 | «use» «aapRequiredPort» | «aapProvidedPort» | «use» «use» «aapRequiredPort» | «aapProvidedPort»

Begleitender Spezifikationstext:

Specification of State Management AUTOSAR AP R23-11 5 Dependencies to other Functional Clusters This chapter provides an overview of the dependencies to other Functional Clusters in the AUTOSAR Adaptive Platform. Section 5.1 “Provided Interfaces” lists the interfaces provided by State Management to other Functional Clusters. Section 5.2 “Required Interfaces” lists the interfaces required by State Management. A detailed technical architecture documentation of the AUTOSAR Adaptive Platform is provided in [9]. 5.1 Provided Interfaces «aapFunctionalCluster» State Management daemon-based «aapFunctionalClust... Diagnostic Management daemon-based «aapPortInterface,aapAPI» EcuResetRequest + EnableRapidShutdown() + ExecuteReset() + Offer() + RequestReset() + StopOffer() «aapAraComServiceInterface,aapInte... UpdateRequest «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 «use» «aapRequiredPort» «aapProvidedPort» «use» «use» «aapRequiredPort» «aapProvidedPort» Figure 5.1: Interfaces provided by State Management to other Functional Clusters Figure 5.1 shows interfaces provided by State Management to other Functional Clusters within the AUTOSAR Ada

Vorkommen in AUTOSAR-Releases (1)

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