Figure 6.3: Example of Cascaded VISS server deployment

1. Diagrammtyp & Architektur-Kontext

• Diagrammtyp: Systemweites Bereitstellungs- und Topologiemodell (High-Level Cascaded Deployment / Network Topology Diagram).
• Architektur-Kontext:
  • AUTOSAR Adaptive Platform (AP) – Dokumentation AUTOSAR_AP_EXP_AutomotiveAPI (Releases R24-11, R25-11).
  • Spezifikation der verteilten Bereitstellung von W3C VISS (Vehicle Information Service Specification) Servern in Verbindung mit der COVESA VSS (Vehicle Signal Specification).
  • Bereitstellung eines standardisierten, signalbasierten API-Zugriffs auf Fahrzeugdaten über Cloud-Grenzen hinweg bis in heterogene On-Board-Ausführungsumgebungen (AUTOSAR Adaptive/Classic und Android Automotive OS).

2. Komponenten, Entitäten & Schnittstellen

Off-Board-Entitäten (Cloud & Third-Party)

• Smartphone: Mobiles Endgerät als externer VISS-Client (Endanwender-Applikation) für Statusabfragen und Steuerbefehle.
• ASP (Automotive Service Provider):
  • Zentrale Cloud-Infrastruktur des OEM.
  • Beherbergt einen primären VISS Server, der als zentraler Proxy, Authentifizierungs- und Autorisierungs-Endpunkt sowie Caching-Layer für externe Zugriffe dient.
• NASP (Non-Automotive Service Providers):
  • Drittanbieter-Dienste (z. B. Flottenmanagement, Versicherungen, Ladeinfrastrukturen, Smart-City-Dienste).
  • Besitzt ausschließlich eine Anbindung an den ASP-VISS-Server; kein direkter Durchgriff auf das physische Fahrzeug.

On-Board-Entitäten (In-Vehicle Topology)

• Zentraler In-Vehicle VISS Server:
  • Platziert auf einem zentralen Gateway, Domain Controller oder High-Performance Computer (HPC / Telematics Control Unit).
  • Fungiert als Schnittstellenknoten (Edge Gateway) zwischen ASP-Cloud und bordnetz-internen Domänen.
  • Realisiert eine Kaskadierungsfunktion: Nach außen (Richtung ASP) tritt er als Server auf; nach innen (Richtung Subsysteme) agiert er als VISS-Client/Aggregator.
• Subsystem „Android“ (Android Automotive OS / AAOS):
  • Lokaler VISS Server innerhalb der Infotainment- und Cockpit-Domain (IVI).
  • Zuständig für Infotainment-, Navigations-, HMI- und nutzerspezifische Signale.
• Subsystem „AUTOSAR“ (Adaptive & Classic Platform):
  • Lokaler VISS Server innerhalb der AUTOSAR-Laufzeitumgebung.
  • Verantwortlich für echtzeit- und sicherheitskritische Fahrzeugdaten (Powertrain, Chassis, Body, ADAS, BMS) mit Anbindung an ara::com bzw. Classic BSW/RTE.

Schnittstellen & Kaskadierungshierarchie

• Standard-Protokoll: W3C VISS (Transport über WebSockets wss:// oder HTTP/REST; Nutzdaten in JSON oder CBOR; Adressierung über VSS-Datenbäume wie Vehicle.Speed, Vehicle.Cabin.*).
• Hierarchische Delegation (Kaskade): $$\text{Client / NASP} \longrightarrow \text{ASP VISS Server} \longrightarrow \text{In-Vehicle Gateway VISS Server} \longrightarrow \begin{cases} \text{Android VISS Server} \\ \text{AUTOSAR VISS Server} \end{cases}$$
• Jeder übergeordnete Server dispatcht spezifische Teilbäume (Subtrees) des Vehicle Signal Trees an die dafür autorisierte Zielplattform.

3. Dynamisches Verhalten & Sequenzablauf

Request- & Subscription-Kaskadierung (Synchrone & Asynchrone Pfade)

1. Anfrage-Initiierung:
   • Ein Client (Smartphone oder NASP) sendet einen VISS-Request (get, set oder subscribe) für einen Signalpfad (z. B. Vehicle.Powertrain.TractionBattery.StateOfCharge) an den ASP-VISS-Server.
2. Off-Board-Filterung & Autorisierung:
   • Der ASP-VISS-Server validiert Zugriffsrechte (OAuth 2.0 / Access Tokens) und prüft Rollen (NASP-Berechtigungsmatrix).
   • Unzulässige Zugriffe werden unmittelbar mit HTTP/VISS-Fehlercodes (401 Unauthorized, 403 Forbidden) abgewiesen.
3. Telematik-Weiterleitung:
   • Bei zulässiger Anfrage leitet der ASP-VISS-Server das VISS-Paket über den gesicherten Telematik-Kanal (WSS/mTLS) an den fahrzeuginternen VISS-Server weiter.
4. On-Board-Routing (VSS-Subtree-Dispatching):
   • Der zentrale fahrzeuginterne VISS-Server parst den Pfad:
     • Signale des Pfades Vehicle.Cabin.Infotainment.* → Weiterleitung an den Android VISS Server.
     • Signale des Pfades Vehicle.Speed, Vehicle.Powertrain.*, Vehicle.Chassis.* → Weiterleitung an den AUTOSAR VISS Server.
5. Plattform-spezifische Auflösung:
   • Der AUTOSAR VISS Server mappt das VSS-Signal über die Adaptive Platform Middleware (ara::com) auf entsprechende Service-Instanzen (SOME/IP-Events/-Fields oder IPC) bzw. leitet Anfragen an Classic-ECUs über CAN/LIN weiter.
6. Rückmelde- und Benachrichtigungspfad:
   • Daten oder Subscription-Events propagieren in umgekehrter Richtung: $$\text{AUTOSAR / Android} \xrightarrow{\text{VISS Notification}} \text{Zentraler VISS} \xrightarrow{} \text{ASP} \xrightarrow{} \text{Client / NASP}$$

4. Normative Relevanz & Entwickler-Hinweise

• VSS-to-AUTOSAR Mapping:
  • Entwickler auf der AUTOSAR Adaptive Platform müssen eine deterministische Übersetzungsschicht zwischen dem flachen/hierarchischen VSS-JSON-Namensraum und den C++-Datentypen in ara::com (Service Interfaces, Skeleton/Proxy) bereitstellen.
• Partitionierung & Zuständigkeiten:
  • Kein direkter Zugriff von Android-Applikationen auf AUTOSAR-Signale ohne Durchlaufen der definierten Gateway-/VISS-Instanzen.
  • Trennung von Sicherheitsdomänen (ASIL vs. QM): Der AUTOSAR-Knoten kapselt sicherheitsrelevante Busse; Android fungiert als reine QM-HMI-Umgebung.
• Latenz- und Determinismus-Grenzen:
  • Die mehrstufige Kaskadierung über TCP/WebSockets (Off-Board → Gateway → Plattform-Server) erzeugt variable Latenzen und signifikanten Serialisierungs-Overhead (JSON/CBOR-Parsing).
  • Die Kaskade ist ausschließlich für Monitoring-, Komfort- und Telematik-Anwendungsfälle geeignet; closed-loop Steuerungsaufgaben mit harten Echtzeitanforderungen dürfen nicht über diesen Pfad abgewickelt werden.
• Fehler- und Ausfallmanagement:
  • Geht die Verbindung zwischen zentralem VISS-Server und Plattform-Servern verloren, müssen Timeouts normgerecht in VISS-Fehlerstatus (z. B. 504 Gateway Timeout oder 502 Bad Gateway) übersetzt werden, ohne den lokalen Stack zu blockieren.