Figure 5.2: Vehicle provides data via the Cloud Service

1. Diagrammtyp & Architektur-Kontext

• Diagrammtyp: Informelles Systemarchitektur- und Bereitstellungsdiagramm (High-Level Deployment & Communication Topology).
• Technischer Zweck: Darstellung des Off-Board-Integrationsmusters „Vehicle provides data via the Cloud Service“ gemäß AUTOSAR_AP_EXP_AutomotiveAPI (Kapitel 5: Deployment Scenarios).
• Funktionale Einordnung: Veranschaulicht die Entkopplung externer Datenkonsumenten (Consumer Tier) vom fahrzeuginternen Bordnetz durch Zwischenschaltung eines Cloud-basierten Gateways im Backend des Automotive Service Providers (ASP). Es realisiert den Zugriff auf Fahrzeugdaten über standardisierte Automotive-APIs (W3C / COVESA VISS – Vehicle Information Service Specification), ohne direkte End-to-End-IP-Verbindungen aus ungesicherten Netzen in das Fahrzeug zuzulassen.

2. Komponenten, Entitäten & Schnittstellen

• Akteure & Entitäten:
  • Smartphone: Mobiler Consumer-Client (Endanwender-Applikation), agiert als VISS-Client.
  • Non-Automotive Service Provider: Externe Third-Party-Cloud-Dienste (z. B. Flottenmanagement, Smart-Grid/Ladeinfrastruktur, Versicherungen, Smart-Home-Services), agieren als VISS-Client.
  • ASP (Automotive Service Provider): OEM-Backend-Infrastruktur / Cloud-Umgebung. Beherbergt die zentrale Instanz:
    • VISS Server (Cloud): Cloud-seitiger Mediator, Proxy und Aggregator für Fahrzeugdaten und Steuerkommandos.
  • Vehicle (Fahrzeug-Ebene): Repräsentiert das vernetzte Fahrzeug (Connected Vehicle Platform, z. B. Telematics Control Unit oder High-Performance Compute Cluster). Beherbergt:
    • VISS Server (In-Vehicle): Lokale fahrzeugseitige Server-Instanz, ausgeführt als Adaptive Application auf der AUTOSAR Adaptive Platform.
• Schnittstellen & Verbindungen:
  • Smartphone -> ASP (VISS Server): WAN/Internet-Verbindung; Protokollbindung über W3C VISSv2 (WebSocket, HTTP/REST oder MQTT) über TLS.
  • Non-Automotive Service Provider -> ASP (VISS Server): B2B-Cloud-Schnittstelle; W3C VISSv2 über TLS.
  • ASP (VISS Server) -> Vehicle (VISS Server): Backend-to-Vehicle-Telematikverbindung (Mobilfunk / Cellular Interface, eSIM). Punktierter Gateway-Übergang am Fahrzeug markiert den Eintritt über die Antennen-/Telematikschnittstelle in das interne Bordnetz.

3. Dynamisches Verhalten & Sequenzablauf

1. Asynchrone Telemetrie-Ingestion (Vehicle -> ASP):
   • Der fahrzeugseitige VISS Server aggregiert Signale aus den Subsystemen (über bordnetzweite ara::com-Service-Schnittstellen wie SOME/IP oder IPC) und synchronisiert diese zyklisch oder ereignisbasiert (on-change) mit dem VISS Server im ASP-Backend.
2. Entkoppelte Leseanfragen (GET / SUBSCRIBE):
   • Externe Clients (Smartphone, Drittanbieter) richten VISS-Anfragen an den Cloud-VISS-Server.
   • Der ASP-VISS-Server authentifiziert und autorisiert die Clients (z. B. via OAuth 2.0 / Access Grant Tokens).
   • Bei Lesezugriffen auf historische oder gepufferte Zustandsdaten (z. B. Batterieladestand, Verriegelungsstatus) bedient der ASP-VISS-Server die Anfragen direkt aus seinem Cloud-Cache, ohne das Fahrzeug aufzuwecken (Schonung des Bordnetzes und der 12V-Batterie bei Fahrzeug-Tiefschlaf).
3. Durchgriff bei Steuerbefehlen (SET / Remote Operations):
   • Kommandos mit Aktuator-Auswirkung werden nach Autorisierungsprüfung im Backend über die gesicherte Telematik-Session an den fahrzeuginternen VISS Server weitergeleitet.
   • Der In-Vehicle VISS Server übersetzt den VISS-Aufruf in fahrzeuginterne Service-Methoden (ara::com) und leitet ihn an die zuständigen Aktuator-Steuergeräte weiter.

4. Normative Relevanz & Entwickler-Hinweise

• Architektur-Entkopplung & Security Perimeter:
  • Der interne VISS Server exponiert keine direkt aus dem Internet erreichbaren Ports. Die Kommunikation zum ASP erfolgt über abgesicherte, ausgehende Tunnels bzw. mTLS-Verbindungen über ein Telematik-Gateway.
  • Schutz vor DoS-Angriffen: Der ASP-VISS-Server absorbiert Lastspitzen und unautorisierte Scans externer Provider.
• Konsequenzen für AUTOSAR Adaptive Applikationsentwickler:
  • VSS-Datenmodell-Mapping: Der In-Vehicle VISS Server muss VSS-Pfade (Vehicle Signal Specification, z. B. Vehicle.Speed, Vehicle.Cabin.Door.*) auf interne AUTOSAR-Datentypen und Schnittstellen (ara::com Service Interfaces / Events / Fields) mappen.
  • Power- & State-Management: Die Applikation muss robust gegen Verbindungsabbrüche (Funklöcher, Roaming) sein und über ara::sm (State Management) gesteuerte Ruhe- und Aufwachzyklen unterstützen (Caching- und Flush-Strategien vor dem Sleep-Modus).
  • Fehlerbehandlung: Lokale Kommunikationsfehler oder Timeout-Bedingungen zum Fahrzeug dürfen nicht zu unkontrollierten Zuständen führen; der Backend-Server muss definierte VISS-Fehlercodes (404 Not Found, 504 Gateway Timeout, etc.) an die Clients zurückmelden.