Figure 5.1: Connectivity of vehicle and remote devices with short-range communication technologies

1. Diagrammtyp & Architektur-Kontext

• Diagrammtyp: Informelles Systemtopologie- und Bereitstellungsdiagramm (High-Level Deployment Context Diagram) im Kontext der AUTOSAR Adaptive Platform (AP).
• Architektonischer Zweck: Darstellung des lokalen, fahrzeuggebundenen Bereitstellungsszenarios für die Automotive API (basierend auf der W3C/COVESA Vehicle Information Service Specification, VISSv2).
• Funktionale Einordnung:
  • Das Diagramm verortet den VISS Server als Komponente des Functional Clusters Automotive API Gateway auf einer fahrzeuginternen Recheneinheit (z. B. High-Performance Controller / Telematics Unit mit AP-Laufzeitumgebung).
  • Es illustriert den direkten Kommunikationspfad zwischen einem externen Mobilgerät (Remote Device) und dem On-Board-VISS-Server unter Umgehung von Backend-/Cloud-Infrastrukturen über Nahfeld-Funktechnologien (Short-Range Communication).
  • Funktional dient der VISS-Server als Entkopplungs- und Standardisierungsschicht: Interne Kommunikationsprotokolle (wie SOME/IP, DDS, IPC oder Gateway-geroutete Classic-CAN/LIN-Signale) werden in standardisierte, baumstrukturierte VSS-Signale (Vehicle Signal Specification) übersetzt und über Webschnittstellen bereitgestellt.

2. Komponenten, Entitäten & Schnittstellen

• Dargestellte Entitäten & Akteure:
  • Remote Device (Smartphone/Tablet-Piktogramm):
    • Rolle: Externer VISS-Client / Consumer.
    • Plattform-Kontext: Fremdsystem außerhalb der AUTOSAR-Domain (z. B. Android-, iOS-Applikation oder drahtloser Servicetester).
  • Vehicle (Fahrzeugkontur):
    • Physische und bordnetztopologische Systemgrenze. Kapselt interne Vernetzung und Steuergeräte.
  • VISS Server (Rechteckblock auf Fahrzeug-Ebene):
    • Rolle: Service Provider / Gateway-Serverinstanz.
    • Plattform-Kontext: Native AUTOSAR Adaptive Application (Execution Management gesteuert, unter POSIX OS wie Linux/QNX) bzw. integrierter Bestandteil des Automotive API Gateway.
  • Service Access Point (Schwarzer Endpunkt am VISS-Server):
    • Symbolisiert den logischen/physischen Netzwerk- und Protokoll-Endpunkt (Socket/Port), an dem der Server auf eingehende Verbindungsanfragen lauscht.
• Beziehungen, Schnittstellen & Datenfluss:
  • Kardinalität: Im Diagramm abstrahierend als 1:1 dargestellt; architektonisch unterstützt der VISS-Server 1:n-Verbindungen zu multiplen gepairten Nahbereichs-Clients.
  • Physikalische & Verbindungsschicht: Drahtlose Kurzstrecken-Technologien (Short-Range): Bluetooth Classic / BLE, Wi-Fi (IEEE 802.11 Access Point / Wi-Fi Direct) oder Ultra-Wideband (UWB).
  • Transport- & Anwendungsprotokolle:
    • IP-basiertes Netzwerk (TCP/IP über den lokalen Funk-Link).
    • VISSv2-Transport-Bindings: HTTP/1.1 bzw. HTTP/2 (RESTful via TLS/HTTPS) sowie WebSocket (Full-Duplex via WSS).
  • Datenmodell: Adressierung über hierarchische VSS-Pfade (z. B. Vehicle.Powertrain.TractionBattery.StateOfCharge).
  • Modellierungshinweis: Da es sich um ein konzeptionelles Übersichtsschaubild eines Explanation-Dokuments (EXP) handelt, sind keine formalen AUTOSAR-ARXML-Stereotypen (wie «atpSplitable» oder «isOfType») ausgewiesen.

3. Dynamisches Verhalten & Sequenzablauf

1. L2/L3-Verbindungsaufbau & Kopplung (Discovery/Pairing):
   • Das Mobilgerät etabliert die physische Nahfeldverbindung zum Fahrzeug (z. B. BLE-Pairing oder Assoziation am In-Car-WLAN-Hotspot).
   • Vergabe lokaler IP-Adressen (DHCP/Auto-IP) und Auflösung des Service-Endpoints (via mDNS/DNS-SD oder feste Gateway-IP/Port).
2. Session-Initialisierung & Security-Handshake:
   • Etablierung einer gesicherten Transportschicht via TLS 1.3 (wss:// bzw. https://).
   • Lokale Authentifizierung/Autorisierung: Da kein direkter Cloud-Zugriff besteht, muss der VISS-Server Zugriffsrechte autark prüfen (z. B. über vorab gecachte Access Tokens, asymmetrische Schlüsselpaare oder ein lokales Pairing-Token-Verfahren).
3. Datenzugriff & Signalaustausch:
   • Synchrone Request/Response-Pfade:
     • HTTP GET: Abfrage von Fahrzeug-Telemetriedaten (z. B. Reifendruck, Batteriestatus).
     • HTTP SET: Setzen von Aktordaten (z. B. Vorklimatisierung, Türverriegelung). Der VISS-Server validiert Berechtigungen und leitet Anforderungen über ara::com an zuständige Applikationen weiter.
   • Asynchrone Event-Pfade:
     • Client sendet WebSocket-Subscription (subscribe).
     • VISS-Server registriert Event-Handler und pusht Wertänderungen periodisch oder ereignisbasiert (subscriptionNotification) über den offenen WebSocket.
4. Fehlerbehandlung & Terminierung:
   • Bei Signalabriss des Nahbereichsfunknetzes (Link-Loss/Timeout) erfolgt ein kontrollierter Abbruch der Socket-Verbindung, Löschung temporärer Sessions und Deregistrierung interner Event-Subskriptionen.
   • Berechtigungs- und Syntaxfehler werden über native VISS-/HTTP-Statuscodes (z. B. 401 Unauthorized, 403 Forbidden, 404 Path Not Found, 400 Bad Request) an das Remote Device quittiert.

4. Normative Relevanz & Entwickler-Hinweise

• Dokumentenstatus: AUTOSAR_AP_EXP_AutomotiveAPI ist ein informativer Spezifikationsbestandteil (Explanation). Es definiert keine verbindlichen SWS-Anforderungs-IDs ([SWS_...]), setzt jedoch das Referenzmodell für die Realisierung der Automotive API Gateways.
• Auswirkungen auf Stack- und Gateway-Entwickler:
  • Protokoll-Stack-Integration: Erfordert die Bereitstellung eines robusten, ressourceneffizienten Web-Server-Stacks (HTTP/WebSocket) auf der Adaptive Platform mit Bindung an POSIX-Socket-Interfaces.
  • Service-to-Signal-Mapping: Implementierung des bidirektionalen Mappings zwischen dem COVESA VSS-Objektbaum und den internen AUTOSAR-Kommunikationsmustern (ara::com Methods, Events, Fields bzw. Signal-to-Service-Translation).
  • Lokale Policy Enforcement: Architekten müssen sicherstellen, dass Autorisierungsmechanismen (Policy Enforcement Point - PEP / Policy Decision Point - PDP) ohne permanente Online-Cloud-Anbindung lauffähig sind (Offline-Capability für Short-Range-Szenarien).
• Cybersecurity & Safety-Einschränkungen:
  • Security Boundary: Der direkte Zugriff von externen Devices über Nahbereichsfunk stellt eine primäre Angriffsoberfläche dar. Eine strikte Trennung (Firewalling, Ratenbegrenzung zur DoS-Prävention, strikte JSON/VISS-Payload-Validierung) vor Weiterleitung an ASIL-relevante Bordnetzdomänen ist zwingend vorgeschrieben.
  • Schreibzugriffe (Actuation): Aktorische Eingriffe via Kurzstreckenfunk (z. B. schlüsselloser Zugang via Smartphone) erfordern zusätzliche End-to-End-Sicherheitsmechanismen (Challenge-Response, Challenge-Signaturen) jenseits des einfachen Transportschutzes.