DEENESPTFRRUARHIKOZHNL
AUTOSAR_AP_SWS_NetworkManagement FIG-0389039a254e9b0c 751 × 497 px 10 Release(s)

Figure 1.1: Architecture overview with example applications

SHA-256 Inhalts-Fingerabdruck: 0389039a254e9b0cb20674c61e4b75d506128cfee0a21da076914ef94e77b0b5

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-description@2 · erstellt am 2026-10-07

1. Diagrammtyp & Architektur-Kontext

  • Diagrammtyp: Informelles Architektur- und Schichtenübersichtsdiagramm (Blockdiagramm).
  • Funktionale Einordnung: AUTOSAR Adaptive Platform (AP), Functional Cluster Network Management (ara::nm). Das Schaubild visualisiert die Entkopplung von Applikationen von der direkten Netzwerkverwaltung und definiert die zentrale Rolle des State Management (ara::sm) als Vermittlungsinstanz zwischen Anwendungslogik und physischer bzw. partieller Netzwerkkoordination (Physical Networks, Partial Networks / PN).

2. Komponenten, Entitäten & Schnittstellen

  • Akteure & Funktionscluster:
    • Application (ara::* Client-Instanzen): Adaptive Applications (AA), die Kommunikationsbedarf besitzen, jedoch keine direkte Verbindung zu Network Management aufbauen.
    • State Management (ara::sm): Zentraler Koordinator für Maschinen-, Funktionsgruppen- und Netzwerkzustände auf der Adaptive-Plattform.
    • Network Management (ara::nm): Plattform-Cluster zur Steuerung der Busaktivität, Überwachung der Busruhe und Aggregation partieller Netzwerkanforderungen.
    • Physical Networks (Physical Network 1, Physical Network 2): Physische Bussysteme bzw. logische Bussegmente (z. B. Ethernet-VLANs, CAN-Interfaces).
    • Partial Networks (PN1, PN2, PN3): Partielle Netzwerkcluster (PNCs), die sich segment- oder physisch netzwerkübergreifend erstrecken (farblich codiert als identische funktionale Cluster über mehrere physische Interfaces).
  • Schnittstellen & Beziehungen:
    • Application → State Management (Unidirektional / n:1): Applikationen fordern funktionale Zustände bzw. Kommunikationsbereitschaft bei ara::sm an (z. B. via Function Group State Interfaces / Port-basierte IPC).
    • State Management ↔ Network Management (Bidirektional / 1:1):
      • Abwärts (SM → NM): Übergabe aggregierter Netzwerkanforderungen (NetworkHandle, PNC-Aktivierung/Deaktivierung, Anforderung von Full Communication oder Freigabe in Richtung Ready Sleep).
      • Aufwärts (NM → SM): Statusrückmeldungen, Wake-up-Indikationen von externen Steuergeräten und Statuswechsel partieller Netzwerke an das State Management zur Triggern von Zustandswechseln.
    • Network Management → Physical/Partial Networks (1:n): Abbildung logischer PNC-Bitvektoren auf die konkreten physischen Kanäle via NM-PDUs (z. B. UDP-NM-Frames).

3. Dynamisches Verhalten & Sequenzablauf

  1. Kommunikationsanforderung: Eine oder mehrere AAs signalisieren ara::sm ihren Kommunikationsbedarf.
  2. Zustandsaggregation & Vermittlung: ara::sm aggregiert die Anforderungen gegen das aktuelle Sicherheits- und Maschinenprofil und ruft die Service-Schnittstelle von ara::nm auf, um den jeweiligen Netzzweig oder PNC anzufordern (Network Request).
  3. NM-Zustandsmaschine & PDU-Versand:
    • ara::nm wechselt von Bus-Sleep Mode bzw. Prepare Bus-Sleep Mode in den Network Mode (Repeat Message State → Normal Operation State).
    • Periodischer Versand von NM-PDUs (insb. UDP-NM bei Ethernet) mit gesetzten Bits im Partial Network Info-Feld über die zugewiesenen physischen Netzwerke (Physical Network 1/2).
  4. Externer Wake-up / Remote Request: Empfang einer NM-PDU mit relevantem PNC-Bit auf Physical Network 1 oder 2 versetzt ara::nm in den aktiven Zustand und meldet das Wake-up-Event synchron/asynchron an ara::sm, welches daraufhin die Ziel-Applikationen hochfährt.
  5. Freigabe / Busruhe: Beenden alle AAs ihren Bedarf, schaltet ara::sm die Anforderung an ara::nm ab. ara::nm stoppt das eigene Senden von NM-Frames (Ready Sleep State), überwacht das NM-Timeout und signalisiert ara::sm nach Ablauf der Busruhe den Übergang in den Schlafzustand.

4. Normative Relevanz & Entwickler-Hinweise

  • Kapselung & API-Zugriff (Strict Decoupling): Applikationsentwickler dürfen niemals direkt auf NM-APIs zugreifen. Sämtliche Netzanforderungen müssen zwingend über ara::sm (State Management) modelliert und verhandelt werden.
  • Manifest- & PNC-Konfiguration:
    • Integratoren müssen im Execution Manifest und Machine Manifest die Zuordnung der PNCs (PN1–PN3) zu den jeweiligen physischen Schnittstellen (z. B. Ethernet-Controller, Socket-Adressen, VLAN-Tags) und PDU-Offsets konsistent konfigurieren.
    • Ein identischer PNC (z. B. PN1) über mehrere physische Netzwerke erfordert im NM-Stack ein entsprechendes Routing bzw. koordinierte PDU-Filterung/Weiterleitung.
  • Timing & Timeouts: Im UDP-NM müssen Sendezyklen (Msg Cycle Time), Überwachungszeiträume (NM Timeout Time) und Wait Bus Sleep Time strikt auf die maximalen Latenzen des State Managements und die Wake-up-Zeiten der Applikationen abgestimmt sein, um verfrühte Bus-Sleep-Events oder hängende Aufwachzyklen zu verhindern.

Zugeordnete Anforderungen

Diese Angaben zeigt der Versions-Explorer.

Vorkommen in AUTOSAR-Releases (15)

Release Dokument Seite Nr. Bildunterschrift im Dokument
R18-10_R4.4.0_R1.5.0 AUTOSAR_SWS_NetworkManagement S. 5 1.1 Figure 1.1: Architecture overview with example applications
R18-10_R4.4.0_R1.5.0 AUTOSAR_SWS_NetworkManagement S. 5 1.1 Figure 1.1: Architecture overview with example applications
R18-10-1 AUTOSAR_SWS_NetworkManagement S. 5 1.1 Figure 1.1: Architecture overview with example applications
R19-03 AUTOSAR_SWS_NetworkManagement S. 5 1.1 Figure 1.1: Architecture overview with example applications
R19-03 AUTOSAR_SWS_NetworkManagement S. 5 1.1 Figure 1.1: Architecture overview with example applications
R19-11 AUTOSAR_SWS_NetworkManagement S. 5 1.1 Figure 1.1: Architecture overview with example applications
R19-11 AUTOSAR_SWS_NetworkManagement S. 5 1.1 Figure 1.1: Architecture overview with example applications
R20-11 AUTOSAR_SWS_NetworkManagement S. 5 1.1 Figure 1.1: Architecture overview with example applications
R20-11 AUTOSAR_SWS_NetworkManagement S. 5 1.1 Figure 1.1: Architecture overview with example applications
R21-11 AUTOSAR_SWS_NetworkManagement S. 5 1.1 Figure 1.1: Architecture overview with example applications
R21-11 AUTOSAR_SWS_NetworkManagement S. 5 1.1 Figure 1.1: Architecture overview with example applications
R22-11 AUTOSAR_SWS_NetworkManagement S. 6 1.1 Figure 1.1: Architecture overview with example applications
R23-11 AUTOSAR_AP_SWS_NetworkManagement S. 6 1.1 Figure 1.1: Architecture overview with example applications
R24-11 AUTOSAR_AP_SWS_NetworkManagement S. 7 1.1 Figure 1.1: Architecture overview with example applications
R25-11 AUTOSAR_AP_SWS_NetworkManagement S. 8 1.1 Figure 1.1: Architecture overview with example applications