Figure 5.1: Interfaces provided by Network Management to other Functional Clusters

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: UML-Komponenten- und Schnittstellendiagramm (AUTOSAR Adaptive Platform Architecture Modeling).
• Technischer Zweck: Spezifikation der standardisierten Service-/Port-Schnittstelle zwischen den Functional Clusters (FC) Network Management (NM) und State Management (SM).
• Architektur-Kontext:
  • In der AUTOSAR Adaptive Platform (Release R23-11) ist das Network Management für die Überwachung und Anforderung des Kommunikationsbus-Zustands (z. B. Ethernet/CAN-NM-Cluster) zuständig.
  • Das State Management (als zentrale Instanz für Maschinen- und Funktionszustände) steuert koordinativ die partiellen Netze und Cluster über definierte Schnittstellen an, anstatt direkt auf Bussignale oder Treiber zuzugreifen.

2. Komponenten, Entitäten & Schnittstellen

Entitäten & Stereotypen

• «aapFunctionalCluster» State Management (Klassifikation: daemon-based):
  • Konsument/Client der Schnittstelle.
  • Agiert als zuständiger System-Daemon für ECU-/Machine-State-Übergänge und bindet die benötigte Schnittstelle über einen Required Port ein.
• «aapFunctionalCluster» Network Management (Klassifikation: daemon-based):
  • Provider/Server der Schnittstelle.
  • Realisiert die Kernlogik des Netzwerkmanagements (Netzwerk-Zustandsmaschine, Bus-Sleep, Repeat Message, Normal Operation) und ist explizit als prozessbasierter Daemon-Cluster spezifiziert.
• «aapAPI,aapPortInterface» NetworkHandle:
  • Abstrakte Schnittstellendefinition (ara::com / native C++ Schnittstelle), welche die Steuer- und Abfragemethoden bündelt:
    • GetNetworkRequestedState(): Synchroner Getter für den aktuell angeforderten Soll-Netzwerkzustand.
    • GetNetworkState(): Synchroner Getter für den tatsächlichen Ist-Zustand des Netzwerks (Bus-State).
    • SetNetworkRequestedState(): Setter zur Anforderung oder Freigabe des Netzwerks (Transition Trigger).
    • RegisterNetworkRequestedStateChangeNotifier() / UnregisterNetworkRequestedStateChangeNotifier(): Registrierungs-/Deregistrierungsmechanismus für Callbacks bei Änderung des Soll-Zustands.
    • RegisterNetworkStateChangeNotifier() / UnregisterNetworkStateChangeNotifier(): Registrierungs-/Deregistrierungsmechanismus für Callbacks bei Änderung des realen Bus-/Netzwerkzustands.

Beziehungen & Abhängigkeiten

• Interface Realization (Implementierung):
  • Gestrichelte Linie mit geschlossener, nicht gefüllter Pfeilspitze von Network Management auf NetworkHandle.
  • Network Management stellt die konkrete Implementierung der Schnittstelle bereit (ProvidedPort).
• Usage Dependency (Verwendung):
  • Gestrichelte Pfeillinie mit offener Spitze von State Management auf NetworkHandle, annotiert mit «use» und «aapRequiredPort».
  • State Management deklariert einen Abhängigkeits-Port auf die Schnittstelle NetworkHandle.

3. Dynamisches Verhalten & Sequenzablauf

Das Diagramm modelliert die statische Schnittstellenstruktur, impliziert jedoch folgendes dynamisches Interaktionsmuster zwischen State Management und Network Management:

1. Initialisierung & Observer-Registrierung (Asynchron/Event-driven):
   • SM ruft während der Initialisierung RegisterNetworkStateChangeNotifier() und RegisterNetworkRequestedStateChangeNotifier() auf.
   • NM speichert die bereitgestellten Funktionszeiger/Delegate-Instanzen (std::function bzw. Listener-Objekte).
2. Netzwerk-Aktivierung / Freigabe (Steuerungspfad):
   • Anforderung: SM entscheidet aufgrund von State-Transitions (z. B. Wechsel in den State Running), dass Netzwerkkommunikation erforderlich ist, und ruft synchron/blockierungsarm SetNetworkRequestedState(...) auf.
   • Quittierung & Monitoring: NM schaltet intern die NM-Zustandsmaschine um (z. B. Senden von NM-PDUs, Halten des Busses wach) und notifiziert das SM über die registrierten Notifier-Callbacks bei Statuswechseln.
3. Zustandsabfrage (Synchroner Polling-Pfad):
   • SM kann zu jedem Zeitpunkt über GetNetworkState() bzw. GetNetworkRequestedState() den aktuellen Zustand abfragen, um Vorbedingungen für weitere State-Transitions (z. B. Vorbereitung des System-Shutdowns/Sleep) zu prüfen.
4. De-Registrierung:
   • Vor dem Herunterfahren oder bei Rekonfiguration deregistriert SM die Observer über UnregisterNetwork*ChangeNotifier(), um Dangling-Pointer bzw. Callbacks auf terminierte Kontexte zu verhindern.

4. Normative Relevanz & Entwickler-Hinweise

• API-Vertrag (C++ Namespace ara::nm):
  • Entwickler von State-Management-Regeln müssen sich strikt an die NetworkHandle-Abstraktion halten; direkter Zugriff auf darunterliegende Busprotokolle (z. B. UDP-Sockets, CAN-Interfaces) ist architektonisch unzulässig.
• Thread-Safety & Reentrancy:
  • Die Notifier-Callbacks werden im Ausführungskontext des Network-Management-Daemons bzw. dessen Worker-Threads aufgerufen. SM-Entwickler müssen sicherstellen, dass Notifier-Routinen nicht-blockierend ausgelegt sind und keine Deadlocks durch synchrone Rückrufe (SetNetworkRequestedState) innerhalb des Notifier-Kontexts provozieren.
• Zustandssynchronisation:
  • GetNetworkRequestedState() spiegelt lediglich den logischen Anforderungsstatus wider. Ob der physische Bus tatsächlich kommunikationsbereit ist, liefert ausschließlich GetNetworkState() (bzw. dessen Notifier). State-Maschinen im SM dürfen erst nach Bestätigung des tatsächlichen Netzwerkzustands davon ausgehen, dass Kommunikation (ara::com Services) voll einsatzbereit ist.
• Port-Konfiguration im ARXML-Manifest:
  • Das Deployment erfordert die Deklaration eines entsprechenden RPortPrototype im Execution/Service-Manifest des State Management und eines korrespondierenden PPortPrototype im Network Management Cluster, gebunden über das interne IPC-/Service-Binding der Adaptive Platform.