Figure 6.1: A cloud server requesting VSS data through a web services interface

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: Systemübergreifendes Topologie- und Bereitstellungsdiagramm (Cloud-to-Vehicle Deployment & Integration Architecture).
• Technischer Zweck & Einordnung: Spezifikation des End-to-End-Zugriffspfads für fahrzeugbezogene Daten basierend auf der Vehicle Signal Specification (VSS). Das Diagramm veranschaulicht das Zusammenspiel zwischen fahrzeuginterner AUTOSAR Adaptive Platform (AP), dem OEM-Backend (Automotive Service Provider, ASP) und externen Drittsystemen unter Berücksichtigung des Extended Vehicle (ExVe)-Sicherheitskonzepts.

2. Komponenten, Entitäten & Schnittstellen

Entitäten & Akteure

• Mobile Device (Client): Endanwender-Schnittstelle (z. B. Smartphone-App), die fahrzeugbezogene Mehrwertdienste nutzt.
• Non-Automotive Service Providers (Third-Party Cloud): Drittanbieter-Backend (z. B. Flottenmanagement, Versicherungstelematik, Smart Home), das keinen direkten Zugriff auf das Fahrzeug besitzt.
• ASP (Automotive Service Provider / OEM-Cloud): Zentrales OEM-Backend. Beherbergt eine Cloud-Instanz des VISS Servers (W3C/COVESA Vehicle Information Service Specification), dient als Policy Enforcement Point (PEP) und aggregiert/puffert Fahrzeugdaten.
• Vehicle / In-Vehicle VISS Server: Ausführungsumgebung auf einem High-Performance Controller (HPC) bzw. Telematics Control Unit (TCU) unter AUTOSAR Adaptive Platform. Stellt die fahrzeugseitige Gegenstelle zur Bereitstellung der VSS-Knotenpunkte dar.

Schnittstellen & Protokolle

• Web services interface [ISO 20078 series]: Standardisierte ExVe-Schnittstelle (RESTful HTTP/JSON, OAuth 2.0 / OpenID Connect) zwischen Third-Party-Servern und dem ASP-Backend zur Entkopplung und rechtssicheren Zugriffskontrolle (Nutzerkonsens, Mandantenfähigkeit).
• ASP-to-Vehicle Channel (VISS Server ↔ VISS Server): Gesicherter bidirektionaler Telematikkanal (typischerweise TLS-gesicherte WebSockets oder MQTT/HTTP) zum Abgleich von VSS-Datenbäumen zwischen On-Board- und Off-Board-VISS-Instanzen.
• Client-to-Provider Interface: Endgeräte-API (HTTPS/REST) zur Dienstinteraktion.

3. Dynamisches Verhalten & Sequenzablauf

1. Request-Trigger: Der Endanwender fordert über das Mobilgerät einen Dienst an; der Non-Automotive Service Provider initiiert eine Abfrage spezifischer Fahrzeugparameter (z. B. Batterieladestand, Kilometerstand).
2. ExVe-Anfrage via ISO 20078: Der Drittanbieter sendet eine authentifizierte und autorisierte Anfrage an die Webservice-Schnittstelle des ASP.
3. Validierung & Policy Check (ASP): Das ASP validiert Zugriffstoken, Datenschutz-/Consent-Status und leitet die angefragten Parameter auf die entsprechenden VSS-Signalpfade (z. B. Vehicle.Powertrain.TractionBattery.StateOfCharge) ab.
4. Off-Board/On-Board VISS-Synchronisation:
   • Synchron / Cached: Sofern die geforderte Datengüte (Freshness/Timestamp) erfüllt ist, antwortet der Cloud-VISS-Server direkt aus dem Backend-Cache.
   • Asynchron / Live-Dispatch: Bei Live-Bedarf sendet der Cloud-VISS-Server eine get-/subscribe-Anfrage an den In-Vehicle VISS Server.
5. Fahrzeuginterne Signalauflösung: Der In-Vehicle VISS Server liest die Signale über adaptive Kommunikationsmechanismen (ara::com / Automotive API) aus den internen AUTOSAR-Software-Clustern bzw. über Unterbussysteme (CAN/LIN/Ethernet) aus.
6. Response-Kaskade: Die Signalantwort durchläuft den umgekehrten Pfad (In-Vehicle VISS → Cloud-VISS im ASP → ISO 20078 Response → Drittanbieter → Mobilgerät).

4. Normative Relevanz & Entwickler-Hinweise

• Applikations- & Stack-Entwicklung (AUTOSAR AP):
  • Der In-Vehicle VISS Server fungiert als Adaptionsschicht zwischen VSS-Hierarchien (W3C/COVESA) und den typisierten C++ Service-Schnittstellen (ara::com Services/Events/Fields).
  • Entwickler müssen Signal-Mappings, Typkonvertierungen (VSS-Datentypen zu AUTOSAR C++ Primitives) und Aktualisierungsraten deterministisch konfigurieren.
• Security & Safety Isolation:
  • Externe Drittanbieter haben keine direkte IP-Verbindung zum Fahrzeug. Das ASP fungiert als zwingende Sicherheits- und Protokollgrenze (Firewall / Gateway).
  • Der In-Vehicle VISS Server muss strikt read-only bzw. streng entkoppelt von sicherheitskritischen Steuergeräten betrieben werden; Schreibzugriffe (Control-Kommandos via VISS) erfordern kryptografisch gehärtete End-to-End-Autorisierungsketten.
• Bandbreiten- & Ressourcenmanagement:
  • Zur Schonung von Mobilfunkressourcen und ECU-Last sind fahrzeugseitig Mechanismen für Deadband-Filterung, Throttling und ereignisgesteuerte Subskriptionen vorzusehen.