DEENESPTFRRUARHIKOZHNL
AUTOSAR_AP_EXP_SWArchitecture FIG-d7ef80c65c369f12 332 × 383 px 1 Release(s)

Figure 9.35: Users of Network Management interfaces

SHA-256 Inhalts-Fingerabdruck: d7ef80c65c369f12ca7071b4ee42a5aa4d422a71caf9f4d1631cb3c8dcef1859

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-Komponentendiagramm im Kontext der AUTOSAR Adaptive Platform (Systemarchitektur). Das Diagramm visualisiert die Schnittstellenbeziehung zwischen den Functional Clustern State Management und Network Management über ein direktes C++-Port-Interface (API).

2. Komponenten, Entitäten & Schnittstellen

Das Diagramm umfasst zwei AUTOSAR Adaptive Functional Cluster sowie ein Port-Interface:

  • Functional Cluster State Management (Stereotyp «aapFunctionalCluster», Ausprägung daemon-based): Fungiert als Nutzer («use», «aapRequiredPort») der Schnittstelle.
  • Functional Cluster Network Management (Stereotyp «aapFunctionalCluster», Ausprägung daemon-based): Realisiert das Interface (Realisierungspfeil mit geschlossener Dreiecksspitze).
  • Port-Interface NetworkHandle (Stereotypen «aapAPI,aapPortInterface»): Methodenbasierte Schnittstelle mit folgenden Operationen:
    • + GetNetworkRequestedState()
    • + GetNetworkState()
    • + RegisterNetworkRequestedStateChangeNotifier()
    • + RegisterNetworkStateChangeNotifier()
    • + SetNetworkRequestedState()
    • + UnregisterNetworkRequestedStateChangeNotifier()
    • + UnregisterNetworkStateChangeNotifier()

3. Dynamisches Verhalten & Sequenzablauf

Interaktionsmuster über direkte API-Aufrufe (C++ Port-Interface):

  • Das State Management fordert über SetNetworkRequestedState() Netzwerkzustandsänderungen an.
  • Der aktuelle und der angeforderte Zustand können synchron über GetNetworkState() und GetNetworkRequestedState() abgefragt werden.
  • Zustandsänderungsbenachrichtigungen werden über Observer-Registrierung (RegisterNetworkStateChangeNotifier(), RegisterNetworkRequestedStateChangeNotifier()) und Deregistrierung (Unregister...) synchronisiert.

4. Normative Relevanz & Entwickler-Hinweise

Normative Relevanz für Adaptive Platform Architekten und Entwickler:

  • Sowohl State Management als auch Network Management sind als daemon-based Functional Cluster klassifiziert.
  • Die Kopplung zwischen beiden Clustern erfolgt über die funktionale C++-API NetworkHandle («aapAPI,aapPortInterface») mit Notifier-Registrierung und Getter/Setter-Methoden.

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

R24-11 → R25-11 redaktionell Vorgänger: FIG-48268bb28bf27487
  • Beim Functional Cluster Network Management wird die Eigenschaftsbezeichnung links unten um daemon-based ergänzt.

Zugeordnete Anforderungen

Diese Angaben zeigt der Versions-Explorer.

Aus dem Dokument extrahierter Text & Kontext

Beschriftungen im Schaubild:

«aapFunctionalCluster» | State Management daemon-based | «aapAPI,aapPortInterface» | NetworkHandle | + GetNetworkRequestedState() + GetNetworkState() + RegisterNetworkRequestedStateChangeNotifier() + RegisterNetworkStateChangeNotifier() + SetNetworkRequestedState() + UnregisterNetworkRequestedStateChangeNotifier() + UnregisterNetworkStateChangeNotifier() | «aapFunctionalCluster» | Network Management daemon-based | «use» «aapRequiredPort»

Vorkommen in AUTOSAR-Releases (1)

Release Dokument Seite Nr. Bildunterschrift im Dokument
R25-11 AUTOSAR_AP_EXP_SWArchitecture S. 78 9.35 Figure 9.35: Users of Network Management interfaces