Figure 9.11: Interface for handling a Power Mode request

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: UML-Komponenten- und Schnittstellendiagramm unter Verwendung des AUTOSAR Adaptive Platform (AP) UML-Profils («aap...»).
• Technischer Zweck: Modellierung der serviceorientierten Interaktion (ara::com) zwischen einer Client-Applikation (Adaptive Application) und dem Plattform-Dienst State Management (SM) zur Anforderung und Rückmeldung von Power-Mode-Zuständen (z. B. Standby, Suspend-to-RAM, Shutdown, Normal Operation).
• Funktionale Einordnung: Verortet in der AUTOSAR Adaptive Platform (Release R21-11). Das State Management fungiert als zentraler Orchestrator für Machine States und Function Group States; das Diagramm formalisiert die Trennung zwischen Applikationslogik und dem als Daemon ausgeführten Plattform-Cluster über definierte IPC-Serviceschnittstellen.

2. Komponenten, Entitäten & Schnittstellen

• Komponenten:
  • Adaptive Application (UML-Komponente): Konsument/Client der Schnittstelle (z. B. Power-Coordinator, HMI oder System-Controller). Besitzt einen «aapRequiredPort» mit «use»-Abhängigkeit.
  • State Management daemon-based («aapFunctionalCluster», UML-Komponente): Server-Komponente; stellt als Hintergrund-Daemon die Plattform-Implementierung bereit und realisiert die Schnittstelle über einen «aapProvidedPort» (Interface Realization).
• Service-Schnittstelle:
  • PowerMode («aapAPI, aapAraComServiceInterface»): Abstrahiert den Servicevertrag über das AUTOSAR Adaptive Communication Management (ara::com).
  • Schnittstellenelemente (unter Stereotyp «aapAccessControlled, aapServiceInterfaceElement»):
    • + message(PowerModeMsg*): Nachrichten-/Methodenaufruf von der Adaptive Application an das State Management zur Übergabe einer Power-Mode-Anforderung.
    • + event(PowerModeRespMsg*): Asynchrones ara::com-Event (Publish/Subscribe), mit dem das State Management Status- und Quittierungsnachrichten an Abonnenten meldet.

3. Dynamisches Verhalten & Sequenzablauf

1. Initialisierung & Service Discovery:
   • State Management instanziiert das Service-Skeleton und bietet den Service PowerMode über ara::com an (OfferService).
   • Die Adaptive Application findet den Service via Proxy (FindService) und abonniert das Event PowerModeRespMsg* (Subscribe).
2. Request-Phase (Asynchron / Message-basiert):
   • Die Applikation setzt message(PowerModeMsg*) ab. Dies transportiert den Anforderungstyp (Ziel-Power-Mode, Wakeup-Gründe, Timeout-Parameter).
3. Plattform-Verarbeitung & Validierung:
   • Der SM-Daemon validiert die Berechtigung des Aufrufers gegen das Identity and Access Management (IAM, indiziert durch «aapAccessControlled»).
   • SM evaluiert interne State-Transition-Rules und koordiniert nachgelagerte Functional Clusters (z. B. Execution Management für das Herunterfahren/Einfrieren von Function Groups).
4. Response-/Notification-Phase (Event-basiert):
   • SM publiziert das Event PowerModeRespMsg* mit dem Ergebnis der Transition (Erfolg, Ablehnung oder aktueller Übergangsstatus).
   • Bei fehlerhaften Transitions oder verweigerter IAM-Autorisierung wird das Fehlerhandling asynchron über den Event-Payload bzw. ara::core-Fehlercodes signalisiert.

4. Normative Relevanz & Entwickler-Hinweise

• ara::com-Modellierung & Codegenerierung:
  • PowerMode muss im AUTOSAR-ARXML-Modell als ServiceInterface mit zugeordneten Event- und Method-/Message-Definitionen deklariert werden. Daraus generieren die Werkzeuge die typsicheren C++-Klassen PowerModeProxy und PowerModeSkeleton.
• IAM-Konfiguration (Identity and Access Management):
  • Der Stereotyp «aapAccessControlled» verpflichtet Entwickler zur Konfiguration korrespondierender IAM-Policies im Service Instance Manifest bzw. Execution Manifest. Fehlt dem Applikations-Prozess das Access-Right für message(PowerModeMsg*), verwirft der IAM-Enforcement-Layer den IPC-Aufruf auf Systemebene.
• IPC & Daemon-Architektur:
  • Da State Management als separater POSIX-Daemon-Prozess läuft, findet zwingend eine prozessübergreifende Kommunikation statt. Entwickler müssen berücksichtigen, dass Power-Mode-Übergänge nicht-blockierend/asynchron sind; die Applikation darf nach Absetzen von PowerModeMsg* keinen synchronen Zustandswechsel voraussetzen, sondern muss auf das Eintreffen von PowerModeRespMsg* synchronisieren.