Figure 9.42: 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).
• «aapFunctionalCluster» Execution Management:
  • Rolle: Plattform-Service Provider (Lebenszyklus- und Prozessverwaltung für funktionale Cluster und Prozesse).
  • Eigenschaft: daemon-based (zentraler OS-Prozess für Startup- und Shutdown-Koordination).
• 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.
• «aapAPI, aapNativeInterface» ExecutionClient:
  • Realisiert durch: «aapFunctionalCluster» Execution Management (UML-Interface-Realisierung, gestrichelte Linie mit geschlossener, nicht ausgefüllter Pfeilspitze).
  • API-Methoden (C++ Native Interface):
    • + Create() – Statische Fabrikmethode zur Instanziierung der Client-Schnittstelle.
    • + ReportExecutionState(ExecutionState) – Übermittlung des aktuellen Prozess- und Lebenszykluszustands (z. B. kRunning, kTerminating) an das Execution Management.
• «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»}}$ ExecutionClient: Gerichtete Nutzungsbeziehung (gerichtete Abhängigkeit) auf die standardisierte C++-API von ara::exec.
• 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

• Prozess-Initialisierung & Lebenszyklusmeldung (ara::exec):
  1. Nach dem Start des Prozesses instanziiert das Automotive API Gateway die Kommunikationsschnittstelle zum Plattform-Management über die statische Methode ExecutionClient::Create().
  2. Sobald die interne Initialisierung abgeschlossen ist und alle Netzwerk-Sockets bereitstehen, meldet das Gateway seinen Ausführungszustand via ReportExecutionState(ExecutionState::kRunning) an das Execution Management.
  3. Beim geordneten Herunterfahren signalisiert das Gateway vor der Terminierung den Zustand ReportExecutionState(ExecutionState::kTerminating).
• Netzwerk-Initialisierung & Socket-Bindung (Synchron / Blockierend oder Non-Blocking via OS):
  1. Das Gateway instanziiert 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

• Lebenszyklus-Steuerung & Zustandsmeldung (ara::exec):
  • Als daemon-based Functional Cluster unterliegt das Automotive API Gateway der Verpflichtung zur aktiven Zustandsrückmeldung über ara::exec::ExecutionClient.
  • Das Ausbleiben des Aufrufs ReportExecutionState(kRunning) innerhalb des im Execution Manifest spezifizierten Start-Timeouts führt zur Einstufung als fehlgeschlagener Startup durch das Execution Management und zu Recovery-Aktionen (z. B. Watchdog-Reaktion, Neustart).
• 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, der Zuordnung der Logging-Kontexte (LogAndTraceInstantiation) sowie der Konfiguration der Startup-Parameter inklusive State-Reporting.