Figure 9.29: Interfaces required by Network Management

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: UML-Komponenten- und Schnittstellendiagramm (statische Architekturansicht mit AUTOSAR-Adaptive-Stereotypen).
• Architektur-Kontext: AUTOSAR Adaptive Platform (ARA/AAP), Spezifikation AUTOSAR_EXP_SWArchitecture (Release R21-11).
• Technischer Zweck: Spezifikation der externen Schnittstellenabhängigkeiten des Functional Clusters Network Management (NM) zu anderen funktionalen Clustern und der Basisinfrastruktur (OS/Plattformebene).

2. Komponenten, Entitäten & Schnittstellen

Entitäten & Stereotypen

• «aapFunctionalCluster» Network Management:
  • Konsument (Client).
  • Realisiert die NM-Zustandsmaschine (z. B. UdpNm-Zustände wie Repeat Message, Normal Operation, Ready Sleep) und koordiniert den Netzwerkstatus der Adaptive Platform.
• «aapAPI,aapNativeInterface» Log and Trace::Logger:
  • Öffentliche, standardisierte C++-Laufzeitschnittstelle (ara::log::Logger).
  • Deklarierte Operationen:
    • + IsEnabled(): Abfrage, ob das konfigurierte Log-Level aktiv ist.
    • + Log(MsgId, Params): Strukturiertes Logging mit Nachrichten-ID und Parametern.
    • + LogDebug(): LogStream, + LogError(): LogStream, + LogFatal(): LogStream, + LogInfo(): LogStream, + LogVerbose(): LogStream, + LogWarn(): LogStream: Bereitstellung von typisierten Log-Streams für die jeweiligen Schweregrade.
    • + WithLevel(): LogStream: Dynamische Zuweisung des Log-Levels zur Laufzeit.
• «aapInternal» TCP/IP Stack:
  • Nicht-öffentliche Plattform-/OS-Schnittstelle («aapInternal»).
  • Stellt Netzwerk-I/O-Dienste (L4/L3, typischerweise UDP/IP) für das Senden und Empfangen von NM-Botschaften bereit.
• «aapFunctionalCluster» Log and Trace:
  • Plattform-Cluster, der den Logging-Dienst kapselt und die physische Weiterleitung (z. B. via DLT – Diagnostic Log and Trace) abstrahiert.
• Operating System:
  • Basis-Laufzeitumgebung (POSIX-kompatibles Betriebssystem gemäß PSE51/PSE52). Beherbergt den Netzwerk-Treiberstack und Kernel-Netzwerkpuffer.

Beziehungen & Kardinalitäten

• Verwendungsabhängigkeiten («use», gestrichelte Pfeile mit offener Spitze):
  • Network Management → Log and Trace::Logger: Bindung an das standardisierte Application Interface des Logging-Clusters.
  • Network Management → TCP/IP Stack: Direkte Nutzung der Netzwerk-Transportschicht für NM-PDUs.
• Schnittstellenrealisierungen (Interface Realization, gestrichelte Pfeile mit geschlossener Dreiecksspitze):
  • Log and Trace → Log and Trace::Logger: Der funktionale Cluster implementiert die native API.
  • Operating System → TCP/IP Stack: Das Betriebssystem stellt den Netzwerk-Stack intern bereit.

3. Dynamisches Verhalten & Interaktionsmuster

• Initialisierung & Startup:
  • NM erzeugt eine Logger-Instanz mit spezifischer Context- und App-ID über die Laufzeitumgebung von ara::log.
  • NM öffnet Sockets über den TCP/IP Stack (OS-Systemaufrufe wie socket(), bind() auf dem konfigurierten NM-Port/Multicast-Adresse).
• Zyklischer Betrieb & Ereignisbehandlung:
  • PDU-Transfer (asynchron/synchron): Senden periodischer NM-Pakete über Non-blocking/Blocking UDP-Sockets (sendto()); Empfang eingehender NM-Pakete via Socket-Events (epoll(), pselect(), recvfrom()).
  • Diagnose & Tracing: Zustandsübergänge der NM-State-Machine und Bus-Timeouts werden über RAII-basierte LogStream-Objekte synchron in den lokalen Puffer von ara::log geschrieben (z. B. logger.LogInfo() << "Entering Normal Operation";).
• Shutdown / Bus-Sleep:
  • Übergang in Bus-Sleep: Freigabe der OS-Socket-Deskriptoren, Absetzen finaler Shutdown-Logs vor Transition in den Standby.

4. Normative Relevanz & Entwickler-Hinweise

• API-Vertrag («aapAPI,aapNativeInterface» vs. «aapInternal»):
  • Log and Trace: Die Interaktion erfolgt zwingend über den standardisierten C++-Header ara/log/logger.h. Entwickler dürfen keine plattformspezifischen Logging-Systemaufrufe (wie syslog oder printf) innerhalb des NM-Clusters nutzen.
  • TCP/IP Stack: Da die Schnittstelle als «aapInternal» klassifiziert ist, existiert hierfür keine standardisierte funktionale ara::-Client-API im NM-Kontext. Der NM-Daemon interagiert plattformspezifisch – in der Praxis über die POSIX-Socket-API des Host-Betriebssystems oder vendor-spezifische OSAL-Treiber.
• Prozess- und Rechtemodell:
  • Der NM-Cluster läuft als eigenständiger OS-Prozess. Für die Socket-Bindung (Raw-Sockets, Multicast-Joins oder reservierte Ports) sind entsprechende OS-Privilegien (z. B. CAP_NET_RAW / CAP_NET_BIND_SERVICE unter Linux/QNX) im Deployment-Manifest zu konfigurieren.
• Thread-Sicherheit & Latenzen:
  • LogStream-Aufrufe müssen thread-safe und blockierungsfrei arbeiten, um das deterministische Timing der NM-Zustandsüberwachung (Überwachung von NM_TIMEOUT, MSG_CYCLE_TIME) nicht zu verletzen.