Figure 5.2: Interfaces required by Network Management from other Functional Clusters

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: UML-Komponenten- und Schnittstellendiagramm (AUTOSAR Adaptive Platform Metamodellierung).
• Technischer Zweck & Einordnung: Spezifikation der ausgehenden Abhängigkeiten und Dienstschnittstellen, die der funktionale Cluster Network Management (NM) der AUTOSAR Adaptive Platform zur Laufzeit von Nachbarclustern bzw. der Plattformbasis anfordert (required interfaces). Es ordnet NM architektonisch zwischen den Diagnose-/Logging-Diensten (Log and Trace) und den darunterliegenden Transport- und Netzwerkprotokollen des Betriebssystems (Operating System / TCP/IP Stack) ein.

2. Komponenten, Entitäten & Schnittstellen

• Komponenten / Functional Clusters:
  • «aapFunctionalCluster» Network Management: Konsument der Schnittstellen; zuständig für die Verwaltung des Netzwerkzustands (z. B. UDP-basiertes NM).
  • «aapFunctionalCluster» Log and Trace: Bereitstellender Cluster für plattformweites Logging und Tracing (ara::log).
  • Operating System: Bereitstellende Plattform-Entität für Low-Level-Netzwerktreiber und Socket-Infrastruktur.
• Schnittstellen & Entitäten:
  • «aapAPI, aapNativeInterface» Log and Trace::Logger:
    • Native C++-Programmierschnittstelle des Log-Clusters.
    • Operationen:
      • + IsEnabled()
      • + Log(MsgId, Params)
      • + LogDebug(): LogStream
      • + LogError(): LogStream
      • + LogFatal(): LogStream
      • + LogInfo(): LogStream
      • + LogVerbose(): LogStream
      • + LogWarn(): LogStream
      • + WithLevel(): LogStream
  • «aapInternal» TCP/IP Stack:
    • Plattforminterne Netzwerkschnittstelle/Stack (typischerweise POSIX-Sockets oder proprietäre OS-Sockets).
• Beziehungen & Abhängigkeiten:
  • Network Management besitzt eine gerichtete Nutzungsbeziehung («use») auf Log and Trace::Logger.
  • Network Management besitzt eine gerichtete Nutzungsbeziehung («use») auf TCP/IP Stack.
  • Log and Trace realisiert/implementiert (interface realization, gestrichelte Linie mit geschlossener Pfeilspitze) die Schnittstelle Log and Trace::Logger.
  • Operating System realisiert/implementiert die Schnittstelle TCP/IP Stack.

3. Dynamisches Verhalten & Sequenzablauf

• Zyklisches / Ereignisgesteuertes Senden & Empfangen (TCP/IP):
  • NM nutzt den TCP/IP Stack synchron oder asynchron (z. B. über BSD/POSIX-Sockets via UDP) zum Senden von periodischen NM-Botschaften (NM-PDUs) im Zustand Normal Operation bzw. Repeat Message sowie zum Abhören eingehender NM-Pakete zur Netzwerkhaltung (Network Request vs. Network Release).
• Logging & Tracing:
  • Synchroner Aufruf von Log and Trace::Logger bei Zustandswechseln (z. B. Wechsel von Ready Sleep nach Normal Operation), Timeout-Ereignissen (NM-Timeout) oder Socket-/Netzwerkfehlern.
  • Erzeugung von Log-Meldungen via Streaming-Operator (LogStream) auf den entsprechenden Severitätsstufen (LogInfo, LogWarn, LogError, etc.).

4. Normative Relevanz & Entwickler-Hinweise

• API-Vertrag & Zugriffsbeschränkung:
  • Für das Logging wird die standardisierte native C++-API von ara::log vorausgesetzt. Der NM-Stack muss eine Instanz von Logger mit spezifischem Context-/Applikations-ID-Präfix instanziieren.
  • Das Stereotyp «aapInternal» am TCP/IP Stack indiziert, dass hierfür keine standardisierte ARA-API (ara::*) nach außen vorgeschrieben ist, sondern eine betriebssystemspezifische bzw. plattforminterne Netzwerkschnittstelle (Standardmäßig POSIX Network API / Sockets).
• Konfigurations- und Portierungsanforderungen:
  • Socket-Konfiguration: Der NM-Daemon/Cluster benötigt Zugriffsrechte auf OS-Ebene für RAW- oder UDP-Sockets sowie Zuweisung zu den konfigurierten Multicast-/Unicast-Adressen und Ports für NM-Traffic.
  • Thread-Safety & Latenz: Aufrufe von LogStream müssen performant und thread-sicher erfolgen, um das zeitkritische Senden von NM-Botschaften im Millisekundenbereich nicht zu blockieren.