DEENESPTFRRUARHIKOZHNL
AUTOSAR_AP_EXP_SWArchitecture FIG-c5450b86426b2d77 247 × 341 px 1 Release(s)

Figure 9.9: Notification interface for an Adaptive Application

SHA-256 Inhalts-Fingerabdruck: c5450b86426b2d777a09b3a314c72aa1824c11759b4f396ee1625c12c497a366
✦ 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

  • Diagrammtyp: UML-Komponentendiagramm mit Schnittstellen- und Realisierungsbeziehungen (Service-Interface-Modellierung der AUTOSAR Adaptive Platform).
  • Architektur-Kontext: AUTOSAR Adaptive Platform (AP), Release R24-11, Dokument AUTOSAR_AP_EXP_SWArchitecture.
  • Technischer Zweck: Spezifikation der Dienstschnittstelle (ara::com), über die der funktionale Cluster State Management (SM) Zustandstransitionen (z. B. Machine States oder Function Group States) an Standard-Applikationen (Adaptive Applications) propagiert. Es illustriert die Entkopplung von Plattform-Dämon und Applikation über standardisierte Service-Oriented Architecture (SOA)-Mechanismen.

2. Komponenten, Entitäten & Schnittstellen

  • State Management («aapFunctionalCluster», daemon-based):
    • Plattform-Kerncluster, realisiert als eigenständiger Betriebssystem-Prozess (Daemon).
    • Fungiert als Service Provider (Skeleton) für die Zustandsüberwachung.
    • Beziehung: Realisiert das Interface StateMachineNotification via UML-Interface-Realization (gestrichelte Linie mit geschlossener Pfeilspitze).
  • StateMachineNotification («aapAraComServiceInterface, aapAPI»):
    • Service Interface im Namensraum von ara::com / ara::sm.
    • Felder:
      • + CurrentState: Attribut mit den Stereotypen «aapAccessControlled» und «aapServiceField» (bzw. Field-Notifier).
      • «aapAccessControlled»: Zugriff unterliegt der Autorisierung durch das Identity and Access Management (IAM).
      • «aapServiceField»: Bereitstellung des aktuellen Zustands über ara::com::Field (Kombination aus Notifier-Event und optional Get-/Set-Methoden; hier primär Push-Notification / On-Change-Update).
  • Adaptive Application (UML-Komponente):
    • Verbraucher/Client (Proxy).
    • Beziehung: Verwendet das Service Interface über eine Abhängigkeitsbeziehung («use», gestrichelter Pfeil).

3. Dynamisches Verhalten & Sequenzablauf

  1. Service Discovery & Binding:
    • Die Adaptive Application sucht via ara::com::runtime::ResolveServiceInstances bzw. FindService nach der Instanz des StateMachineNotification-Service.
    • IAM prüft, ob die Prozess-ID/Manifest-Rechte der Applikation den Lesezugriff auf das Interface und das Feld CurrentState erlauben.
  2. Subscription & Initial State:
    • Die Applikation abonniert das Notifier-Event des Feldes CurrentState (CurrentState.Subscribe()).
    • Initialer Zustandsabruf: Entweder via Field-Getter (Get()) oder via automatische Erst-Notification des aktuellen Zustands beim Subscribe.
  3. Zustandstransition & Benachrichtigung:
    • Ein Trigger (z. B. Transition im Execution Management, externe Diagnoseanforderung oder internes Ereignis) ändert die State Machine im State Management Daemon.
    • Der Daemon publiziert den neuen Zustand asynchron über den Field-Notifier (CurrentState.Update()).
    • Alle abonnierten Applikationen erhalten das Update über registrierte Callbacks (SetReceiveHandler()), werten den neuen Zustand aus und passen ihr lokales Verhalten an (z. B. Ressourcendrosselung, Deinitialisierung bei State-Exit, Vorbereitung auf Shutdown).

4. Normative Relevanz & Entwickler-Hinweise

  • Applikations-Entwickler (Adaptive Application):
    • Kein direkter IPC/Systemaufruf: Der Zugriff auf Systemzustände erfolgt strikt SOA-basiert über generierte ara::com-Proxies (StateMachineNotificationProxy).
    • Asynchrone Event-Verarbeitung: Zustandsänderungen müssen non-blocking im Receive-Handler verarbeitet werden; aufwändige Vorbereitungen auf Zustandswechsel sind in separate Applikations-Worker-Threads auszulagern.
    • Fehlerbehandlung: Unerwartete Offline-Zustände des State Management Daemons (z. B. Communication Link Down) müssen im Proxy-Lifecycle abgefangen werden (ServiceAvailability).
  • Integrations- & Manifest-Konfiguration (ARXML):
    • IAM-Policy: Ein passendes Grant / SecurityEventContext muss modelliert werden, da CurrentState «aapAccessControlled» ist. Fehlt das Deployment-Manifest-Grant, verweigert der IPC-Stack den Service-Connect oder das Event-Subscription.
    • Service Deployment: Mapping von StateMachineNotification auf das lokale IPC-Binding (ara::com IPC-Deployment) zwischen dem SM-Daemon-Prozess und den Ziel-Applikationsprozessen.
    • Instance Specifier: Korrekte Zuweisung des PortInterfaceDeployment und RPortPrototype an der AdaptiveApplicationSwComponent.

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

R24-11 → R25-11 keine inhaltliche Änderung Vorgänger: FIG-de38c94f48235cc3

Keine inhaltlichen Änderungen erkennbar.

Zugeordnete Anforderungen

Diese Angaben zeigt der Versions-Explorer.

Aus dem Dokument extrahierter Text & Kontext

Beschriftungen im Schaubild:

«aapFunctionalCluster» | State Management | daemon-based | «aapAraComServiceInterface,aapAPI» | StateMachineNotification | «aapAccessControlled, aapServiceFie... + CurrentState | Adaptive Application | «use»

Vorkommen in AUTOSAR-Releases (1)

Release Dokument Seite Nr. Bildunterschrift im Dokument
R25-11 AUTOSAR_AP_EXP_SWArchitecture S. 52 9.9 Figure 9.9: Notification interface for an Adaptive Application