Figure 6.2: Multiple Automotive API Gateway deployment

1. Diagrammtyp & Architektur-Kontext

• Diagrammtyp: Systemweites Verteilungs- und Topologiediagramm (High-Level Deployment Architecture) mit Cloud-to-Vehicle-Grenzziehung.
• Architektur-Kontext: AUTOSAR Adaptive Platform (AP), Functional Cluster Automotive API Gateway (spezifiziert in AUTOSAR_AP_EXP_AutomotiveAPI, Releases R24-11, R25-11).
• Technischer Zweck: Darstellung einer Multi-Gateway-Topologie zur Anbindung fahrzeuginterner, serviceorientierter Architekturen (SOA) an fahrzeugexterne Domänen. Das Szenario skizziert die Verteilung und Aggregation standardisierter Fahrzeugdaten (W3C VISS / COVESA VSS) über mehrere parallele On-Board-Gateway-Instanzen hinweg, flankiert durch ein zentrales Backend-Gateway (ASP Cloud).

2. Komponenten, Entitäten & Schnittstellen

Off-Board-Ebene (Cloud & Remote Clients)

• Client Devices (z. B. Smartphone): Externe VISS-Clients, die über webbasierte APIs (WebSockets / HTTP REST) Daten anfordern oder steuern.
• Non-Automotive Service Provider: Drittanbieter-Backends (3rd Party Cloud), die standardisierten Zugriff auf aggregierte Fahrzeugdaten über ein autorisiertes OEM-Interface erhalten.
• ASP (Automotive Service Provider Cloud) / VISS Server: Zentraler Backend-Aggregator und Reverse-Proxy des OEMs. Terminiert externe Client-Verbindungen, übernimmt Authentifizierung/Autorisierung (z. B. OAuth 2.0 / W3C VISS Access Control) und routet VSS-Signalabfragen an die jeweiligen fahrzeuginternen Gateways.

In-Vehicle-Ebene (ECU / HPC / Zonen-Ebene)

• VISS Server 1 & VISS Server 2: Mehrfach instanziierte Automotive API Gateway Functional Cluster auf der AUTOSAR Adaptive Platform (z. B. verteilt auf unterschiedlichen High-Performance Compute Nodes oder Zonen-Controllern).
  • Funktion: Übersetzung zwischen dem externen VISS-Protokoll (VSS-Baumstruktur) und fahrzeuginternen ara::com-Service-Schnittstellen.
  • Verbindungspunkte: Physische/logische Telematik-Endpunkte (Zelluläre Anbindung via IP/TLS/WSS).
• Services Set 1, 2, 3 (In-Vehicle Services): AUTOSAR Adaptive Service Provider (oder via SOME/IP-Gateway angebundene Classic Platform Application Layer Services).
  • Services Set 1: Exklusiv an VISS Server 1 gebunden (z. B. Infotainment-/Telematik-relevante Domänensignale).
  • Services Set 2 (Shared Service Set): Dual-homed an VISS Server 1 und VISS Server 2 angebunden. Stellt geteilte fahrzeugweite Basisdaten bereit (z. B. Fahrzeuggeschwindigkeit, Lokalisierung, Energiemanagement/Batteriestatus).
  • Services Set 3: Exklusiv an VISS Server 2 gebunden (z. B. Karosserie-, Chassis- oder spezifische Zonensteuerungsdaten).

Beziehungen & Kardinalitäten

• Clients : ASP VISS Server: n:1 (Vielzahl externer Konsumenten greift auf zentralen Cloud-Endpunkt zu).
• ASP VISS Server : In-Vehicle VISS Server: 1:m (Cloud-Broker dispatched Anfragen basierend auf Signalpfad/VSS-Namensraum auf On-Board-Server 1 oder 2).
• VISS Server : Services Sets: m:n (Überlappende Zuordnung; VISS Server 1 bedient Set 1 & Set 2; VISS Server 2 bedient Set 2 & Set 3).

3. Dynamisches Verhalten & Sequenzablauf

1. Request-Initiierung (Off-Board):
   • Smartphone oder Drittanbieter-Dienst sendet eine VISSv2-Anfrage (get, set, subscribe) über WebSocket/HTTPS an den ASP Cloud VISS Server.
2. Autorisierung & Signalpfad-Routing (ASP):
   • Der ASP VISS Server validiert Access Tokens gegen Zugriffsmatrizen für den angeforderten VSS-Signalpfad (z. B. Vehicle.Speed vs. Vehicle.Cabin.Door.Row1.Left.IsOpen).
   • Adressierungsentscheidung: Bestimmung, welcher In-Vehicle VISS Server den Teilbaum hält.
3. In-Vehicle Dispatching & Protokolltransformation:
   • Weiterleitung der VISS-Nachricht über sichere WAN-Verbindung an das zuständige On-Board-Gateway (VISS Server 1 oder VISS Server 2).
   • Das adressierte Gateway führt die Protokolltransformation durch:
     • VISS JSON Payload → ara::com-Methodenaufruf (Skeleton::MethodCall), Field-Get/-Set oder Event-Subscription via SOME/IP bzw. POSIX IPC.
4. Shared Access Handling (Services Set 2):
   • Bei Signalen aus Services Set 2 erfolgt der Zugriff je nach Routing-Konfiguration entweder lastverteilt, domänenspezifisch separiert oder redundant (z. B. Failover-Strategie).
5. Response- & Notification-Propagation:
   • Interne Service-Events/Antworten werden im On-Board-Gateway in standardisierte VISS-JSON-Nachrichten verpackt, an den ASP VISS Server gestreamt und asynchron an die registrierten Subskribenten der externen Clients verteilt.

4. Normative Relevanz & Entwickler-Hinweise

• Instanziierung & Execution Manifest (Adaptive Platform):
  • Entwickler müssen das Automotive API Gateway als eigenständige Prozesse (Process, StartupConfig) mehrfach im Manifest instanziieren (VISS_Server_Instance_1, VISS_Server_Instance_2).
  • Jede Instanz erfordert eine dedizierte Machine- und NetworkEndpoint-Zuweisung.
• Signal-to-Service Mapping (ServiceInstanceManifest):
  • Konfiguration des VSS-Baums (W3C/COVESA VSS Catalog): Jedem Signal muss eindeutig ein ara::com-Service-Interface (Port-Prototype, Method-, Event- oder Field-Identifier) zugeordnet werden.
  • Bei isolierten Sets (Set 1 & Set 3) verbleibt der Signalraum strikt getrennt.
• Konfliktvermeidung bei Shared Services (Services Set 2):
  • Schreibzugriffe (set): Es muss ein striktes Ownership-/Locking-Konzept vorliegen, um inkonsistente Zustände oder Race Conditions zu verhindern, wenn beide Gateways denselben Service-Endpunkt modifizieren wollen.
  • Event-Subscriptions (subscribe): Filter- und Zykluszeiten (minChange, samplingPeriod) müssen auf Gateway-Ebene konfiguriert werden, um den internen Bus (SOME/IP über Ethernet) nicht durch doppelte Event-Registrierungen aus beiden Servern zu überlasten.
• Security & Isolation:
  • Die Trennung in zwei On-Board VISS Server ermöglicht Zonen- und Safety-Isolation: Ein Gateway kann für unkritische Infotainment-Dienste zuständig sein, während das zweite Gateway erhöhte ASIL-/Sicherheitsanforderungen mit strengeren Authentifizierungsmechanismen kapselt.
  • Kein externer Client interagiert direkt mit fahrzeuginternen Gateways; der ASP Cloud VISS Server dient als zwingend vorgeschaltete Security-Boundary.