Figure 2.1: SOVD Reference architecture

1. Diagrammtyp & Architektur-Kontext

• Diagrammtyp: Logisches Systemarchitektur-Diagramm / Blockschaltbild (funktionale Komponentensicht und Protokoll-Routing-Ebene).
• Kontext: AUTOSAR Adaptive Platform (AP) im Zusammenspiel mit AUTOSAR Classic Platform (CP), fahrzeuginternen High-Performance Computern (HPCs) sowie externen On-Board- und Off-Board-Diagnose-Clients gemäß ASAM SOVD / AUTOSAR EXP SOVD (R22-11).
• Technischer Zweck: Spezifikation der zentralen Referenzarchitektur für serviceorientierte Fahrzeugdiagnose (Service-Oriented Vehicle Diagnostics, SOVD). Das Diagramm definiert den einheitlichen RESTful-/API-basierten Diagnosezugang (HTTP/JSON, WebSockets) für heterogene E/E-Architekturen, entkoppelt Clients von fahrzeuginternen Netzwerk- und Protokollgrenzen und etabliert das Routing zwischen nativen AP-Diensten, HPC-zu-HPC-Kommunikation und Legacy-UDS-Steuergeräten.

2. Komponenten, Entitäten & Schnittstellen

• Externe Clients (Client-Rolle, grün markiert):
  • Remote SOVD Client: Off-Board-Entität (OEM-Backend, Cloud-Flottenmanagement, OTA-Server), die über Mobilfunk/WAN angebunden ist.
  • Proximity SOVD Client: Vor-Ort-Diagnosewerkzeug (Werkstatttester, Bandende-Prüfstand, OBD-Ethernet-Dongle), das über Nahfeldkommunikation (WLAN, DoIP/Ethernet-Buchse) direkt ankoppelt.
• Konnektivitäts- & Vermittlungsschicht (Orange markiert = SOVD-Kernrouting):
  • Backend Connectivity: Telematik-/Konnektivitäts-Subsystem (TCU, Gateway-Firewall), Terminierungspunkt für TLS-Verbindungen aus dem WAN, zuständig für Authentifizierung (z. B. OAuth 2.0 / OpenID Connect) und sichere Tunnelung ins Fahrzeug.
  • SOVD Gateway (orange mit Begrenzungsakzent): Zentraler fahrzeuginterner SOVD-Server und Dispatcher. Terminiert die HTTP/REST-Schnittstelle, übernimmt URL-Pfad-basiertes Routing (/v1/systems/...), Rechteprüfung, Ressourcenverwaltung und Weiterleitung an interne Ausführungseinheiten.
  • SOVD to UDS Translation (orange mit Begrenzungsakzent): Protokolladapter/Transformator. Mappt SOVD-Ressourcenoperationen (CRUD auf JSON-Objekte) auf standardisierte UDS-Dienste (ISO 14229-1) und retourniert UDS-Responses als JSON-Payloads.
• Fahrzeuginterne Ausführungsziele (Adaptive & Classic Platform, blau markiert):
  • ara::diag / Diagnostic Manager: Funktionaler Cluster der AUTOSAR Adaptive Platform. Handhabt Diagnosesitzungen, Fehlerspeicher (Fault Management) und Routineausführungen auf dem lokalen HPC.
  • Application (Adaptive Applications): Nutzerprozesse im POSIX-Userspace, die über standardisierte C++ API-Ports von ara::diag (z. B. generische Diagnoseschnittstellen, Routine-Handler, Datenpunkt-Provider) an den Diagnostic Manager angebunden sind.
  • Other HPCs: Weitere Rechenknoten/Zentralrechner der Fahrzeugarchitektur, die über interne IP-Verbindungen als eigenständige SOVD-Instanzen oder untergeordnete Ressourcen angesprochen werden.
  • Classic ECU: Konventionelle Steuergeräte auf Basis des AUTOSAR Classic Platform BSW-Stacks (DCM, DEM, CanTp/DoIP), welche rein UDS-basiert arbeiten.
• Schnittstellen & Verbindungsbeziehungen:
  • Remote SOVD Client → Backend Connectivity: Gesicherte WAN-Verbindung (HTTPS / REST).
  • Backend Connectivity → SOVD Gateway: Internes IP-Netzwerk (HTTP/REST oder IPC).
  • Proximity SOVD Client → SOVD Gateway: Lokales Ethernet/WLAN (HTTPS / REST / WebSocket).
  • SOVD Gateway → Diagnostic Manager: Interne IPC-/Service-Schnittstelle innerhalb des lokalen Adaptive-Hostsystems.
  • Diagnostic Manager ↔ Application: Bidirektionale C++ Interprozesskommunikation über die standardisierten ara::diag-Portschnittstellen.
  • SOVD Gateway → Other HPCs: Interne Fahrzeug-Ethernet-Kommunikation (SOVD over IP).
  • SOVD Gateway → SOVD to UDS Translation: Interne SOVD-Aufrufe zur UDS-Konvertierung.
  • SOVD to UDS Translation → Classic ECU: Klassische Diagnose-Transportschichten (DoIP gemäß ISO 13400, CAN-FD via ISO-TP / ISO 15765-2).

3. Dynamisches Verhalten & Sequenzablauf

1. Request-Ingress & Autorisierung:
   • Ein Diagnose-Client initiiert einen synchronen REST-Call (GET, PUT, POST, DELETE).
   • Remote-Pfad: Zugriff via Backend Connectivity → Validierung des Träger-Tokens/mTLS → Weiterleitung an das SOVD Gateway.
   • Proximity-Pfad: Direkter Verbindungsaufbau zum SOVD Gateway über das Fahrzeug-Diagnose-LAN.
2. Pfad-Auflösung & Dispatching durch das SOVD Gateway:
   • Pfad A (Lokale Adaptive Services):
     • URI adressiert den lokalen Host → Weiterleitung an den Diagnostic Manager (ara::diag).
     • Der Diagnostic Manager führt session-/state-relevante Vorprüfungen durch und ruft über asynchrone Callbacks (ara::core::Future/Promise-Pattern) die registrierten Methoden der Ziel-Application auf.
     • Nach Methodenrückkehr formatiert ara::diag das Ergebnis und sendet es an das SOVD Gateway zurück.
   • Pfad B (Multi-HPC Routing):
     • URI adressiert Subsysteme auf anderen Rechenknoten → Weiterleitung als HTTP-Reverse-Proxy-Call an den Ziel-HPC.
   • Pfad C (Classic UDS Gatewaying):
     • URI adressiert Ressourcen eines klassischen Steuergeräts (z. B. Read Data by Identifier oder Routine Control).
     • SOVD Gateway triggert die SOVD to UDS Translation.
     • Die Translation-Unit übersetzt die SOVD-Operation deterministisch in UDS-PDUs (z. B. POST /routines/0x0201 → UDS SID 0x31 0x01 0x02 0x01).
     • Versand via DoIP/CanTp an die Classic ECU.
     • UDS Positive Response (0x71) bzw. Negative Response Code (NRC, z. B. 0x22, 0x31) wird empfangen, in den entsprechenden HTTP-Statuscode (z. B. 200 OK, 400 Bad Request, 404 Not Found) transformiert und als JSON an das Gateway gereicht.
3. Response-Konsolidierung:
   • Das SOVD Gateway assembliert den HTTP-Payload und liefert die synchrone HTTP-Response bzw. asynchrone WebSocket-Notifications an den anfragenden Client aus.

4. Normative Relevanz & Entwickler-Hinweise

• Für Adaptive Platform Applikationsentwickler (ara::diag):
  • Applikationen implementieren ausschließlich die abstrakten C++ Service-Interfaces von ara::diag. Es besteht kein direkter Kontakt zu HTTP-Servern, REST-Parsern oder JSON-Serialisierern; die Kapselung erfolgt vollständig durch den Diagnostic Manager und das SOVD-Framework.
  • Methoden müssen strikt nicht-blockierend ausgelegt sein (asynchron via Futures/Promises), um Pipeline-Blockaden im Diagnostic Manager bei parallelen SOVD-Anfragen zu vermeiden.
• Für Classic Platform Entwickler (DCM/DEM):
  • Auf den Classic ECUs bleibt der Standard-BSW-Stack unverändert. Es ist keine native SOVD-Unterstützung im Classic AUTOSAR Stack erforderlich.
  • Das Gateway (SOVD to UDS Translation) tritt gegenüber dem klassischen Steuergerät als regulärer UDS-Client (Tester) auf. Diagnose-P2/P2*-Timings und Session-Zustände (z. B. Extended Diagnostic Session, Security Access) müssen vom Translation-Modul verwaltet und gegen HTTP-Timeout-Mechanismen abgeglichen werden.
• System- & Gateway-Integration (HPC-Entwickler):
  • Fehlermapping-Konsistenz: Entwickler des Translation-Layers müssen eine exakte Bijektion zwischen UDS-NRCs und HTTP-Statuscodes sicherstellen (z. B. NRC 0x31 RequestOutOfRange ↔ HTTP 400 Bad Request; NRC 0x33 SecurityAccessDenied ↔ HTTP 403 Forbidden).
  • Ressourcenpfad-Konfiguration: Die URI-Struktur des SOVD Gateway muss über AUTOSAR-Modellbeschreibungen (Manifeste) statisch mit den internen Diagnosediensten, DIDs und UDS-Zieladressen verknüpft werden.
  • Security-Zonierung: Das SOVD Gateway bildet eine kritische Sicherheitsgrenze. Authentifizierung und Berechtigungsprüfungen müssen zwingend vor dem Dispatching an ara::diag oder die SOVD to UDS Translation vollständig abgeschlossen sein.