Figure 22.1: The Automotive API Gateway Connecting VSS data to in-vehicle services

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: Software-Architekturdiagramm / Komponenten- und Schnittstellenübersicht (UML-Komponentendiagramm-Anlehnung mit AUTOSAR-Port-Semantik).
• Technischer Zweck: Spezifikation des Automotive API Gateway im Kontext der AUTOSAR Adaptive Platform (AP). Es definiert das Brückenelement zwischen standardisierten fahrzeugexternen/off-board Schnittstellen (W3C Vehicle Information Service Specification, VISS / COVESA Vehicle Signal Specification, VSS) und fahrzeuginternen, herstellerspezifischen Service-Architekturen (ara::com / SOME/IP bzw. IPC).

2. Komponenten, Entitäten & Schnittstellen

• VISS Client:
  • Externer oder anwendungsnaher Konsument (z. B. Cloud-Backend, In-Vehicle-Infotainment/HMI oder Edge-Applikation), der über das standardisierte VISS-Protokoll (typischerweise WebSocket / HTTP REST) standardisierte Fahrzeugdaten abfragt oder steuert.
• Automotive API Gateway (Composite Scope):
  • VISS Interface: Protokolladapter/Endpunkt zur Terminierung des VISS-Protokolls. Wandelt VISS-Transportnachrichten in serviceorientierte Methoden-, Event- oder Field-Aufrufe der Adaptive Platform um.
  • Gateway SWC (<Composite>): Zusammengesetzte AUTOSAR Adaptive Software Component, welche die Transformation kapselt:
    • P-Ports (Provided Ports): Exponieren standardisierte, aus der Vehicle Signal Specification (VSS) abgeleitete Service Interfaces (VSS Derived Service Interface) gegenüber dem VISS Interface.
    • Mapping Application(s) (Programmed/Generated): Übersetzungseinheit (manuell ausprogrammiert oder über Generatoren aus Mapping-Modellen erzeugt). Mappt semantische VSS-Datenpunkte auf proprietäre interne Datenstrukturen, inklusive Datentypkonvertierung, Einheitenumrechnung, Skalierung und Validierung.
    • R-Ports (Required Ports): Konsumieren fahrzeuginterne Dienste über proprietäre Schnittstellen.
• Vehicle Internal Domain:
  • Providing SWC: Eine oder mehrere fahrzeuginterne Adaptive/Classic SWCs oder Sensor-/Aktor-Dienste, die über herstellerspezifische P-Ports (OEM Proprietary) Signale oder Services bereitstellen.
• Schnittstellenbeziehungen & Port-Kopplung:
  • VISS Client ↔ VISS Interface: Standardisiertes VISS v2 (WebSockets/REST/MQTT).
  • VISS Interface ↔ Gateway SWC (P-Ports): VSS-basierte standardisierte Service Interfaces (in AUTOSAR modelliert als ServiceInterface via ara::com).
  • Gateway SWC (R-Ports) ↔ Providing SWC (P-Ports): OEM-spezifische ServiceInterface-Instanzen (lokal via IPC oder netzwerkweit via SOME/IP / DDS).

3. Dynamisches Verhalten & Sequenzablauf

• Read / Subscription Pfad (Ingress fahrzeugintern → VISS Client):
  1. Providing SWC feuert ein Event oder aktualisiert ein Field über seinen P-Port.
  2. Gateway SWC empfängt die Daten an seinem R-Port via ara::com-Subscription (GetNewSamples(), Event-Callback).
  3. Mapping Application transformiert das OEM-spezifische Datenschema (z. B. Rohwerte, Festkomma, herstellerspezifische CAN/SOME/IP-Payload) in standardisierte VSS-Typen/Einheiten (SI-Einheiten, JSON-kompatible Typen).
  4. Die Daten werden über die VSS-P-Ports an das VISS Interface übergeben.
  5. Das VISS Interface serialisiert die Daten gemäß VISS-Spezifikation (z. B. JSON-Payload über WebSocket) und leitet sie asynchron an den VISS Client weiter.
• Write / RPC Pfad (Egress VISS Client → fahrzeugintern):
  1. VISS Client sendet set-Request oder subscribe an das VISS Interface.
  2. Prüfung von Zugriffsrechten/Policy (Security Gate / Access Control).
  3. Methodenaufruf an den P-Ports der Gateway SWC.
  4. Mapping Application validiert Wertebereiche und ruft synchron/asynchron (mittels ara::core::Future) Methoden oder Field-Setter an den OEM-R-Ports auf.
  5. Rückmeldung / Error-Handling wird über Rückgabewerte bzw. Fehlercodes (AUTOSAR ara::core::ErrorCode) zurück an den VISS-Client propagiert.

4. Normative Relevanz & Entwickler-Hinweise

• Architektur-Entkopplung (Anti-Corruption Layer):
  • Die Gateway SWC agiert als klassischer Anti-Corruption Layer. Applikationen außerhalb der Fahrzeugdomäne dürfen nicht an interne, proprietäre Schnittstellen gekoppelt werden.
• Generierung vs. Programmierung:
  • Entwickler sollten das Mapping zwischen VSS-Katalog und AUTOSAR-ARXML idealerweise über codegenerierte Mapping-Tabellen abbilden (model-driven), um manuelle Fehler bei Einheiten-/Datentypanpassungen zu minimieren.
• Konfigurationsaspekte (ara::com & Execution Management):
  • Für VSS-P-Ports und OEM-R-Ports müssen getrennte ServiceInstanceManifests und Deployment-Artefakte (SOME/IP- oder IPC-Bindings) konfiguriert werden.
  • Das VISS-Interface benötigt Netzwerkfreigaben (Ethernet, TLS, Port-Binding) und muss über das Execution Management (ExecutionManifest) mit adäquaten Rechten und Abhängigkeiten deployt werden.
• Laufzeit- und Threading-Restriktionen:
  • Asynchronität: Aufrufe aus dem VISS-Netzwerk dürfen interne echtzeitkritische Dienste nicht blockieren. Es ist auf strikte Thread-Trennung zwischen Socket-Verarbeitung (VISS-Server) und ara::com-Event-Loops zu achten.
• Sicherheit & Zugriffsschutz:
  • Da VISS Datenpunkte nach außen exponiert, ist dem VISS Interface eine strikte Autorisierungsprüfung (z. B. Token-basiert gemäß W3C VISS Access Control) vorzuschalten, bevor Aufrufe an interne Ports durchgereicht werden.