Figure 5.3: In-Vehicle Application Requesting VSS Data

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: Architektonisches Systemkontext- und Bereitstellungsdiagramm (Topologie- und Interaktionsübersicht auf Gesamtfahrzeugebene).
• Technischer Zweck: Spezifiziert die Bereitstellung und das Konsummuster von standardisierten Fahrzeugsignaldaten gemäß COVESA VSS (Vehicle Signal Specification) über einen zentralen VISS-Server (Vehicle Information Service Specification, W3C-Standard) innerhalb der AUTOSAR Adaptive Platform (AUTOSAR_AP_EXP_AutomotiveAPI).
• Funktionale Einordnung: Dient als standardisierte Abstraktionsschicht zwischen heterogenen In-Vehicle-Softwarekomponenten und dem fahrzeuginternen Signal- und Service-Ökosystem. Der VISS-Server entkoppelt High-Level-Applikationen von proprietären Busprotokollen (CAN, FlexRay) und hardwarenahen IPC-/RPC-Mechanismen (z. B. SOME/IP, ara::com).

2. Komponenten, Entitäten & Schnittstellen

• Ausführungsdomänen (Execution Domains / Boundaries):
  • Non-AUTOSAR Domain (Front-End / Compute Node): Plattformfremde Ausführungsumgebung (z. B. Linux OS, Android Automotive OS / IVI, Telematics Control Unit). Beherbergt externe Applikationen ohne AUTOSAR-Laufzeitumgebung.
  • AUTOSAR Adaptive Platform Domain (Zentraler Host / HPC-Partition): POSIX-kompatible AP-Instanz/Machine, die den standardisierten Service-Stack und native Adaptive Applications ausführt.
• Komponenten & Akteure:
  • VISS Server: Zentraler Service-Provider-Dämon auf der Adaptive Platform. Verwaltet den VSS-Fahrzeugdatenbaum, verarbeitet Abfragen und kapselt das Mapping auf zugrundeliegende Signale/Services.
  • Adaptive Application 1: Native AUTOSAR Adaptive Application (Process gemäß AUTOSAR-Ausführungsmodell).
  • App1, App2: Plattformfremde In-Vehicle-Clients (z. B. Infotainment-App, Flottenmanagement-Agent, Navigationsdienste).
• Schnittstellen & Topologie:
  • Service-Access-Point (Lollipop/Socket-Endpunkt am VISS Server): Exponierter VISS-Endpunkt (W3C VISSv2 Core, typischerweise realisiert über WebSockets, HTTP REST oder IP-basierte Transportbindungen).
  • Kommunikationsbeziehungen (gerichtete Pfeile): N:1-Client-Server-Beziehung. Sowohl plattformfremde (App1, App2) als auch native (Adaptive Application 1) In-Vehicle-Clients greifen einheitlich über dieselbe VISS-Schnittstelle auf den Server zu.

3. Dynamisches Verhalten & Sequenzablauf

• Verbindungs- und Kanalaufbau:
  • Clients initiieren eine TCP-/IP-basierte Verbindung (z. B. WebSocket-Handshake) zum VISS-Server-Endpunkt.
• Interaktionsmuster (Request/Response & Publish/Subscribe):
  1. Get Request (Synchron/Asynchron Pull): Client sendet standardisierten Pfadaufruf (z. B. GET /Vehicle/Speed). Der VISS-Server liest den Wert aus dem internen Cache oder triggert ein Signal-Mapping via ara::com, validiert den Datentyp und antwortet mit dem Signalwert (typischerweise JSON-/CBOR-Payload).
  2. Set Request (Write Access): Client adressiert Aktordaten (z. B. SET /Vehicle/Cabin/Door/Row1/Left/IsOpen). Der VISS-Server prüft Berechtigungen und leitet den Steuerbefehl über die interne Middleware weiter.
  3. Subscribe / Eventing (Asynchron Push): Client registriert Subscription auf Signalpfade (optional mit Filtern wie Zykluszeit oder Hysterese). Der VISS-Server pusht Änderungen asynchron an den Client.
• Validierung & Abbruchbedingungen:
  • Ablehnung ungültiger VSS-Pfade (404 Not Found / VISS-spezifischer Fehlercode).
  • Abweisung nicht-autorisierter Zugriffe über Access-Token-Validierung (Security-Token/OAuth2-Mechanismus).

4. Normative Relevanz & Entwickler-Hinweise

• Protokoll- und Schnittstellenvertrag:
  • Für Applikationsentwickler entfällt die Implementierung herstellerspezifischer CAN-/SOME/IP-Signal-Mappings. Interaktionen müssen strikt gegen die standardisierte VSS-Pfadhierarchie und VISS-Syntax spezifiziert werden.
  • Native Adaptive Applications können den VISS-Server entweder direkt netzwerkbasiert (IP/WebSocket) oder über einen plattforminternen IPC-Wrapper ansprechen.
• Security & Access Control:
  • Da externe, nicht-validierte Anwendungen (App1, App2) Zugriff auf Fahrzeugdaten erhalten, muss der VISS-Server zwingend eine granulare Zugriffskontrolle (Read/Write-Scopes pro VSS-Signal) mittels Access-Control-Listen oder Token-Mechanismen (z. B. IAT/AGL Security Framework) durchsetzen.
• Echtzeit- und Latenzgrenzen (Soft Real-Time):
  • Die VISS/VSS-Schicht ist für Telematik-, Infotainment-, Diagnose- und Komfortfunktionen konzipiert. Sie erfüllt keine harten Echtzeitanforderungen (Hard Real-Time, ASIL C/D); sicherheitskritische Regelschleifen dürfen nicht über den VISS-Server geführt werden.
• Konfigurationsanforderung (AP-Manifeste):
  • Auf Seite der Adaptive Platform erfordert der VISS-Server adäquate Network-Endpoint- und Process-Deployment-Konfigurationen im Execution Management (ExecutionManifest) sowie Service-Mappings im Service Instance Manifest.