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

1. Diagrammtyp & Architektur-Kontext

UML-Komponenten- und Schnittstellendiagramm der AUTOSAR Adaptive Platform (SWS Communication Management, Kapitel 5). Es dokumentiert die infrastrukturellen und funktionalen Abhängigkeiten des daemon-basierten Communication Management zu Nachbar-Clustern (Log and Trace, Cryptography), der Manifest-Registry sowie dem zugrundeliegenden Betriebssystem (Operating System).

2. Komponenten, Entitäten & Schnittstellen

• Communication Management («aapFunctionalCluster», Tag daemon-based, hellblau): Zentraler Kommunikations-Daemon in Konsumenten-Rolle mit vier ausgehenden «use»-Abhängigkeiten.
• Schnittstellen:
  • Logger («aapAPI,aapNativeInterface»): Native Logging-Schnittstelle mit den Operationen + IsEnabled(), + Log(MsgId, Params), + LogDebug(): LogStream, + LogError(): LogStream, + LogFatal(): LogStream, + LogInfo(): LogStream, + LogVerbose(): LogStream, + LogWarn(): LogStream, + WithLevel(): LogStream.
  • CryptoStack («aapAPI,aapNativeInterface»): Native Krypto-Schnittstelle (ara::crypto) zur kryptografischen Absicherung (ohne explizit gelistete Operationen).
  • ManifestAccessor («aapInternal,aapNativeInterface»): Plattforminterne native Schnittstelle zum Auslesen von Manifestdaten (ohne gelistete Operationen).
  • TCP/IP Stack («aapInternal»): Plattforminternes Netzwerk-Interface des Betriebssystems (ohne gelistete Operationen).
• Realisierende Entitäten:
  • Log and Trace («aapFunctionalCluster», rot): Realisiert Logger.
  • Cryptography («aapFunctionalCluster», Tag daemon-based, gelb): Realisiert CryptoStack.
  • Registry (Komponente, beige): Realisiert ManifestAccessor.
  • Operating System (Komponente, beige): Realisiert TCP/IP Stack.

3. Dynamisches Verhalten & Sequenzablauf

1. Initialisierung & Manifestauswertung: Während des Hochlaufs liest der CM-Daemon über ManifestAccessor Konfigurationsdaten (Service- und Kommunikationsmanifeste, Endpoint-Parameter, Socket-Optionen) aus der Registry.
2. Netzwerkkommunikation: Zur Übertragung und Entgegennahme von Ethernet-Frames sowie Socket-Verbindungen (TCP/UDP) greift CM über TCP/IP Stack auf die Socket-Schichten des Operating System zu.
3. Kryptografische Absicherung: Eingehende oder ausgehende gesicherte Kommunikation (z. B. TLS, SecOC, MAC-Prüfung) nutzt synchrone Aufrufe an den CryptoStack der Cryptography-Bibliotheken.
4. Betriebs- und Fehlerprotokollierung: Zur Laufzeit protokolliert CM Statusänderungen, Warnungen und Fehlerzustände über die typisierten Stream- und Logging-Methoden (LogDebug, LogInfo, LogWarn, LogError, LogFatal, Log) der Logger-Schnittstelle an Log and Trace.

4. Normative Relevanz & Entwickler-Hinweise

• Schnittstellenklassifikation: Unterscheidung zwischen «aapAPI,aapNativeInterface» (standardisierte C++-APIs wie ara::log und ara::crypto), «aapInternal,aapNativeInterface» (plattforminterne Manifestabfrage) und «aapInternal» (Betriebssystembindung via POSIX-Sockets).
• Prozess- und Performance-Aspekte: Logger und CryptoStack werden in der Regel über In-Process-Client-Bibliotheken angebunden, die bei Bedarf IPC zu Daemon-Instanzen nutzen. Der Zugriff auf den TCP/IP Stack erfordert Kernel-Systemaufrufe.
• Stream-Semantik: Die Logger-Operationen geben LogStream-Objekte zurück; dies erzwingt synchrone Formatierung und RAII-basierte Ressourcenfreigabe vor der Pufferung in Log and Trace.