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; agiert als Service-Consumer für NM-Ressourcen.
• ara::com service interface for NM requests:
  • Dienstorientierte IPC-Schnittstelle (Skeleton/Proxy-Muster via ara::com). Stellt Methoden und Events/Fields bereit, über die SM Netzwerk-Handles anfordert (RequestNetwork), freigibt (ReleaseNetwork) und Zustandsänderungen überwacht.
• NM Service (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 setzt über das ara::com-Interface einen Request für ein spezifisches Network Handle ab.
  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 via ara::com 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 NetworkHandleIds 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 Execution/Service Deployment Manifest redundantfrei deklariert sein.
• Laufzeit- & Echtzeit-Einschränkungen:
  • Aufrufe über ara::com zwischen SM und NM sind asynchron auszulegen; Statusrückmeldungen müssen über Events überwacht werden, da Bus-Zustandsübergänge (Transceiver-Wakeup, Ethernet PHY Link Up) signifikante Latenzen im zweistelligen Millisekundenbereich aufweisen.