Figure 12.1: Overview NM

1. Diagrammtyp & Architektur-Kontext

• Diagrammtyp: Strukturelles Block- und Architekturdiagramm (Komponentenebene AUTOSAR Adaptive Platform).
• Funktionaler Kontext: Spezifiziert die Architektur des Functional Clusters Network Management (NM) in der AUTOSAR Adaptive Platform (AUTOSAR_AP_EXP_PlatformDesign, Kapitel Network Management) und dessen Einbindung in das Gesamtsystem:
  • Entkopplung der logischen Kommunikationsanforderungen des State Management (SM) von der physischen Netzwerktopologie.
  • Kapselung der Partial Network (PN)-Verwaltung und deren Mapping auf mehrere heterogene oder redundante physische Übertragungskanäle (Ethernet/CAN).

2. Komponenten, Entitäten & Schnittstellen

• State Management (SM):
  • Übergeordnete Kontrollinstanz der Adaptive Platform zur Steuerung von Function Groups und Plattform-Betriebszuständen; interagiert als Client über die NM-C++-Schnittstelle zur Anforderung und Freigabe von Netzwerkressourcen.
• ara::nm::NetworkHandle:
  • Standardisierte C++-Programmierschnittstelle (API im Namensraum ara::nm) zwischen State Management und dem Functional Cluster Network Management. Ersetzt die vormals dienstorientierte ara::com-Schnittstelle durch direkte Methodenaufrufe (z. B. zur Anforderung und Freigabe von Network Handles sowie zur Überwachung von Teilnetzzuständen).
• NM API (Functional Cluster):
  • Network Handle Instances (Instance 1, 2, 3): Logische Repräsentanzen für Kommunikationsanforderungen seitens SM/Applikationen. Abstrakte Aggregationsebene für Teilnetzanforderungen.
  • Partial Network State Machines (PNSM): Dedizierte Zustandsautomaten pro Teilnetz (PN1, PN2, PN3), welche den logischen Lebenszyklus (z. B. No Communication, Full Communication) unabhängig vom physischen Trägermedium verwalten.
  • NM Instances (NM Instance 1, NM Instance 2): Kanalspezifische Controller-Instanzen (eine Instanz pro physischem Netzwerk/VLAN). Jede Instanz kapselt eine standardisierte Network State Machine (klassischer NM-Zustandsraum: Bus-Sleep Mode, Prepare Bus-Sleep Mode, Network Mode mit Repeat Message, Normal Operation, Ready Sleep).
• Beziehungen & Kardinalitäten (Mapping-Ebene):
  • M:N-Mapping zwischen PNs und physischen Netzwerken:
    • Network 1 bedient PN1 und PN2.
    • Network 2 bedient PN2 und PN3.
    • PN2 ist kanalübergreifend über beide physischen Netzwerke (Network 1 und Network 2) aufgespannt und synchronisiert damit Teilnetzaktivitäten über Busgrenzen hinweg.

3. Dynamisches Verhalten & Sequenzablauf

• Netzwerkanforderung (SM-getriggert):
  1. Request: SM fordert über die API ara::nm::NetworkHandle ein spezifisches logisches Network Handle an.
  2. PN-Aktivierung: Das Handle aktiviert die referenzierten logischen Teilnetze (z. B. Handle für PN2). Die zugehörige Partial Network State Machine wechselt synchron in den Zustand Full Communication.
  3. Kanal-Aggregation: Die PNSM fordert alle physischen Kanäle an, auf die sie gemappt ist (hier: NM Instance 1 und NM Instance 2).
  4. Bus-Wakeup: Befindet sich ein Kanal im Bus-Sleep, erzwingt die NM-Instanz den Übergang in den Network Mode (Repeat Message → Normal Operation) und triggert das zyklische Senden von NM-PDUs mit gesetztem PN-Filterbit im Payload-Vektor.
• Externer Weckruf / PN-PDU-Empfang:
  1. NM-PDU trifft auf Network 1 ein.
  2. NM Instance 1 parst den empfangenen PN-Vektor gegen die konfigurierte PnFilterMask.
  3. Ist das Relevanz-Bit für PN2 gesetzt, wird die entsprechende PNSM aktiviert.
  4. Bei konfigurierter Gateway-/Routing-Funktionalität weckt die PNSM von PN2 konsekutiv auch NM Instance 2 auf Network 2 auf.
• Abschaltpfad (Release & Bus-Sleep):
  1. SM gibt das Handle über ara::nm::NetworkHandle frei.
  2. PNSM wechselt nach Ablauf von Haltefristen in den Zustand Ready Sleep.
  3. Eine physische NM Instance geht erst dann von Normal Operation über Ready Sleep nach Prepare Bus-Sleep über, wenn alle auf diesem Kanal gemappten PNs freigegeben sind (logisches ODER aller PNSMs des Kanals).

4. Normative Relevanz & Entwickler-Hinweise

• Architektur & Applikations-Entkopplung:
  • Applikationen und SM dürfen niemals direkte Hardware- oder Buskanalbezüge herstellen. Die Steuerung erfolgt ausschließlich über abstrakte Handles (ara::nm::NetworkHandle) bzw. PN-Cluster.
• Konfigurationsverträge (Manifest / ARXML):
  • PN-Vektor-Definition: Exakte Zuordnung der Byte- und Bit-Positionen im User Data der NM-PDU (PnInfoOffset, PnFilterMask). Inkonsistenzen führen zu ungewolltem Dauer-Wachbleiben (Battery Drain) oder Kommunikationsabriss.
  • Kanalzuordnung: Die Zuordnung NetworkHandle → PartialNetwork → EthernetCommunicationController / Vlan muss im Manifest redundantfrei deklariert sein.
• Laufzeit- & API-Eigenschaften:
  • Der Zugriff erfolgt über die direkte C++-API ara::nm::NetworkHandle statt über ara::com-Service-Kommunikation. Trotz lokaler Schnittstelle müssen asynchrone Zustandswechsel und Bus-Zustandsübergänge (Transceiver-Wakeup, Ethernet PHY Link Up) mit signifikanten Latenzen im zweistelligen Millisekundenbereich berücksichtigt werden.