Figure 4.2: Automotive API Gateway.

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: Architekturelles Schichten- und Komponenten-/Blockdiagramm (Gateway-Topologie).
• Technischer Zweck & Einordnung:
  • Dargestellt ist das Integrationskonzept des Automotive API Gateway innerhalb der AUTOSAR Adaptive Platform (spezifiziert in AUTOSAR_AP_EXP_AutomotiveAPI).
  • Es dient als standardisierte Brücke zwischen externen Konsumenten (Off-Board/Cloud, Infotainment, Drittanbieter-Apps) und der fahrzeuginternen serviceorientierten Architektur (SOA).
  • Das Gateway kapselt die fahrzeuginternen Kommunikationsmechanismen und exponiert Fahrzeugdaten und -funktionen über das standardisierte W3C-Protokoll VISS (Vehicle Information Service Specification / VISSv2).

2. Komponenten, Entitäten & Schnittstellen

• Akteure & Komponenten:
  • Users (Extern): Externe Clients, Cloud-Backends, Mobildienste oder In-Vehicle-Infotainment-Systeme (IVI), die Fahrzeugdaten abfragen oder Steuerbefehle absetzen.
  • Vehicle (Systemgrenze): Physische/logische Abgrenzung der fahrzeuginternen HPC- und Steuergeräte-Domäne.
  • Automotive API Gateway: Zentrale Adaptive Application (AA), die als Protokoll-, Daten- und Sicherheitsübersetzer zwischen Web-/Socket-Protokollen und AUTOSAR SOA agiert.
  • AUTOSAR Adaptive Applications (Gestapelt, 1..n): Lokale Service-Provider und -Consumer im Fahrzeug, welche konkrete Fahrzeugfunktionen (z. B. Karosserie, Antrieb, Sensorik) implementieren.
• Schnittstellen & Kommunikationspfade:
  • VISS Interface / VISS (Bidirektional):
    • Externe Schnittstelle des Gateways basierend auf W3C VISS (typischerweise über WebSocket oder HTTP/REST, Payload meist JSON, basierend auf dem VSS-Datenbaum – Vehicle Signal Specification).
    • Unterstützt Operationen wie get, set, subscribe, unsubscribe.
  • Service Interfaces / ara::com (Bidirektional):
    • Interne Dienstschnittstellen gemäß AUTOSAR Adaptive Metamodell.
    • Realisiert über die ara::com-Middleware (IPC, SOME/IP oder DDS).
    • Bestehend aus typisierten AUTOSAR-Service-Elementen: Events (Publish/Subscribe), Methods (Client/Server Request-Response) und Fields (Get/Set/Notifier).

3. Dynamisches Verhalten & Sequenzablauf

• Pfade & Trigger:
  • Request-Response (Downlink – Abfrage/Steuerung):
    1. Users senden synchronen oder asynchronen VISS-Request (z. B. GET Vehicle.Speed oder SET Vehicle.Cabin.Door.Row1.Left.IsOpen).
    2. Das Automotive API Gateway nimmt den Aufruf am VISS Interface entgegen, validiert Zugriffsrechte und mappt den VSS-Signalpfad auf das entsprechende ara::com-Dienstelement.
    3. Aufruf einer ara::com-Methode oder eines Field-Getters/Setters auf der Ziel-Applikation.
    4. Die AUTOSAR Adaptive Application verarbeitet den Call und liefert das Ergebnis via ara::core::Future / ara::core::Result an das Gateway zurück.
    5. Das Gateway serialisiert das Ergebnis in eine VISS-Response an den externen Client.
  • Event-/Stream-Mechanismus (Uplink – Telemetrie):
    1. Client registriert eine VISS-Subscription am Gateway.
    2. Das Gateway abonniert das korrespondierende ara::com-Event bzw. den Field-Notifier.
    3. Tritt ein Signalwechsel oder zyklisches Event in der AUTOSAR Adaptive Application auf, wird es über ara::com an das Gateway zugestellt.
    4. Gateway konvertiert das typisierte C++-Payload in das VISS-JSON-Format und pusht es über die offene WebSocket-Verbindung an die Users.

4. Normative Relevanz & Entwickler-Hinweise

• Dokumentstatus: AUTOSAR_AP_EXP_AutomotiveAPI ist ein Explanatory Document (Konzept/Leitfaden), definiert jedoch die Architekturvorgaben für standardkonforme VISS-Anbindungen in R24-11 und R25-11.
• Applikations- & Stack-Entwicklung:
  • Abstraktion: Adaptive Applications müssen keine Web-Protokolle (WebSockets, JSON, TLS-Terminierung) implementieren; sie exponieren ausschließlich native ara::com-Service-Interfaces.
  • Datenmodell-Mapping: Entwickler müssen ein Mapping zwischen dem baumstrukturierten W3C/COVESA VSS-Pfad und den C++-Typen der ara::com-Interfaces konfigurieren/pflegen.
  • Security & Access Control: Das Gateway ist das primäre Enforcement-Point für Authentifizierung und Autorisierung (z. B. OAuth 2.0 / Access Tokens gemäß VISS-Sicherheitsmodell), bevor Anfragen an sicherheitsrelevante ara::com-Dienste propagiert werden.
  • Threading & Latenzentkopplung: Asynchrone Web-Client-I/O muss im Gateway strikt von echtzeit- bzw. latenzkritischen IPC-/SOME/IP-Aufrufen entkoppelt werden (Verwendung von Event-Loops und Non-Blocking I/O).