Figure 9.41: Interfaces required by the Automotive API Gateway

1. Diagrammtyp & Architektur-Kontext

• Diagrammtyp: UML-Komponentendiagramm / Schnittstellendiagramm (AUTOSAR Adaptive Platform Profile mit Stereotypen «aap*»).
• Architektur-Kontext & Zweck:
  • Das Diagramm spezifiziert die externen Plattformabhängigkeiten und Schnittstellenanforderungen des Functional Clusters Automotive API Gateway innerhalb der AUTOSAR Adaptive Platform (AP, Release R24-11).
  • Das Automotive API Gateway dient als standardisierter Vermittler zwischen fahrzeuginterner Kommunikation (z. B. ara::com, Signal-to-Service) und fahrzeugexternen oder übergeordneten APIs (z. B. W3C VSS, REST/HTTP, WebSockets, gRPC).
  • Es ist als daemon-based Functional Cluster klassifiziert: Es läuft als eigenständiger POSIX-Betriebssystemprozess (Daemon) und greift nicht nur über C++-Bibliotheken, sondern auch direkt auf OS-Ressourcen zu.

2. Komponenten, Entitäten & Schnittstellen

Komponenten & Funktionscluster

• «aapFunctionalCluster» Automotive API Gateway:
  • Rolle: Konsument / Client («use»).
  • Eigenschaft: daemon-based (eigenständiger OS-Prozess unter Prozesskontrolle durch das Execution Management).
• «aapFunctionalCluster» Log and Trace:
  • Rolle: Plattform-Service Provider (Bereitstellung des standardisierten Logging-Subsystems ara::log).
• Operating System:
  • Rolle: Plattform-Basis (POSIX-kompatibles Betriebssystem / Kernel-Layer).

Schnittstellen & Stereotypen

• «aapAPI, aapNativeInterface» Logger:
  • Realisiert durch: «aapFunctionalCluster» Log and Trace (UML-Interface-Realisierung, gestrichelte Linie mit geschlossener, nicht ausgefüllter Pfeilspitze).
  • API-Methoden (C++ Native Interface):
    • + IsEnabled(): bool – Prüfung, ob der Logging-Kanal/Level aktiv ist.
    • + Log(MsgId, Params) – Strukturiertes Logging mit Nachrichten-Identifikator und Parametern.
    • + LogDebug(): LogStream – Logging mit Severity-Level Debug.
    • + LogError(): LogStream – Logging mit Severity-Level Error.
    • + LogFatal(): LogStream – Logging mit Severity-Level Fatal.
    • + LogInfo(): LogStream – Logging mit Severity-Level Info.
    • + LogVerbose(): LogStream – Logging mit Severity-Level Verbose.
    • + LogWarn(): LogStream – Logging mit Severity-Level Warning.
    • + WithLevel(): LogStream – Dynamische Zuweisung des Logging-Levels zur Laufzeit.
• «aapInternal» TCP/IP Stack:
  • Realisiert durch: Operating System (UML-Interface-Realisierung).
  • Stereotyp «aapInternal»: Markiert eine nicht-normierte, plattforminterne OS-Schnittstelle (POSIX Sockets / OS Network Layer).

Relationen & Kardinalitäten

• Automotive API Gateway $\xrightarrow{\text{«use»}}$ Logger: Gerichtete Nutzungsbeziehung (gerichtete Abhängigkeit) auf die standardisierte C++-API von ara::log.
• Automotive API Gateway $\xrightarrow{\text{«use»}}$ TCP/IP Stack: Gerichtete Nutzungsbeziehung (gerichtete Abhängigkeit) auf den internen IP-Stack des Betriebssystems für externe Netzwerkanbindungen.

3. Dynamisches Verhalten & Sequenzablauf

• Netzwerk-Initialisierung & Socket-Bindung (Synchron / Blockierend oder Non-Blocking via OS):
  1. Das Gateway instanziiert nach Start durch den Execution Manager POSIX-Netzwerk-Sockets über den TCP/IP Stack (socket(), bind(), listen()).
  2. Externe Client-Anfragen (z. B. TLS-gesicherte HTTP/WebSocket-Verbindungen) triggern asynchrone I/O-Events (epoll/select), die im Kontext des Gateway-Daemons abgearbeitet werden.
• Logging-Ablauf (ara::log):
  1. Tritt ein Lebenszyklus-, Verbindungs- oder Protokollereignis auf, erzeugt das Gateway einen LogStream über die typisierten Methoden (LogInfo(), LogError(), etc.).
  2. Der LogStream serialisiert Parameter stream-basiert (operator<<) und übergibt die strukturierte Nachricht an den Log and Trace-Daemon (interprozessual über Shared Memory / IPC) zur Weiterleitung (z. B. DLT – Diagnostic Log and Trace).
  3. Bei deaktivierten Log-Leveln vermeidet IsEnabled() teure String-Konstruktionen im Voraus.

4. Normative Relevanz & Entwickler-Hinweise

• POSIX-Stack-Zugriff («aapInternal»):
  • Das Gateway nutzt den OS-TCP/IP-Stack direkt und umgeht für die Gateway-Endpoints die serviceorientierte Kommunikation (ara::com).
  • Für Stack- und Plattform-Integratoren bedeutet dies: Das zugrunde liegende Ziel-OS muss entsprechende Netzwerk-Socket-Treiber, Stack-Konfigurationen und Zugriffsrechte (POSIX Capabilities, SELinux/AppArmor-Policies) für den Gateway-Daemon bereitstellen.
• Kopplung an ara::log:
  • Verbindliche Nutzung der standardisierten C++-Klasse ara::log::Logger.
  • Kein proprietäres Logging (kein direktes std::cout, syslog oder POSIX printf), um Traceability und DLT-Konformität im Gesamtfahrzeugverbund zu garantieren.
• Einschränkungen & Deployment:
  • Das Deployment erfordert die Definition des Gateways als Process im Execution Manifest (ProcessExecutionManifest) mit Bindung an die OS-Ressourcen sowie der Zuordnung der Logging-Kontexte (LogAndTraceInstantiation).