DEENESPTFRRUARHIKOZHNL
AUTOSAR_AP_EXP_SOVD FIG-2542a696e8f974dc 884 × 395 px 3 Release(s)

Figure 2.1: SOVD Reference architecture

SHA-256 Inhalts-Fingerabdruck: 2542a696e8f974dced4a44f21947565f7bde1da4d831c6212672cd695e1612bf

Im Versions-Explorer öffnen

Kanonischer Bildausschnitt (144 DPI WebP, gerendert aus Original-Vektorgrafik) · nicht öffentlich, nur mit Anmeldung und Freigabe
✦ KI-generierte Bildanalyse & technische Beschreibung Modell: gemini-3.8-flash (via agy) · Rezept figure-series@1 · erstellt am 2026-10-08

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

  • Legende & Standardisierungsstatus (Farbkodierung gemäß Legend):
    • Standardized by AUTOSAR (rot): Kernbestandteile der AUTOSAR Adaptive Platform (Application A, Application B, ara::diag, Diagnostic Manager mit UDS Handling und SOVD Handling).
    • Part of reference architecture (blau): Empfohlene standardisierte Architekturbausteine (SOVD Gateway, SOVD to UDS Translation).
    • Proprietary Component (orange): Nicht durch AUTOSAR standardisierte, herstellerspezifische Komponenten (Backend Connectivity, Other HPCs, UDS ECU).
    • External Component (grün): Externe Clients außerhalb des Fahrzeugs (Remote SOVD Client, Proximity SOVD Client).
    • Blauer Pfeil: Kennzeichnung der SOVD-Kommunikationsbeziehungen.
  • Netzwerksegmentierung:
    • Vehicle external network: Äußerer Netzwerkbereich, in dem sich die Diagnose-Clients befinden.
    • Vehicle internal network: Abgesichertes internes Fahrzeugnetzwerk, getrennt durch eine Zonengrenze (gestrichelte Linie).
  • Externe Diagnose-Clients (External Component, grün):
    • Remote SOVD Client: Externe Cloud-/Backend-Entität im externen Netzwerk, angebunden via Mobilfunk/WAN an die fahrzeuginterne Konnektivität.
    • Proximity SOVD Client: Lokales Diagnosetool (Werkstatttester) im externen Netzwerk, direkt an das interne SOVD Gateway angebunden (z. B. via Ethernet/WLAN).
  • Konnektivitäts- & Gateway-Ebene (Fahrzeuginternes Netzwerk):
    • Backend Connectivity (orange, proprietär): Telematik-/Gateway-Einheit, die das externe Mobilfunknetzwerk terminiert und SOVD-Anfragen an das interne Gateway weiterleitet.
    • SOVD Gateway (blau, Referenzarchitektur): Zentraler SOVD-Einstiegsknoten und Dispatcher/Reverse-Proxy. Verarbeitet eingehende SOVD-Requests und routet diese an die entsprechenden internen Endpunkte (Diagnostic Manager, Other HPCs, SOVD to UDS Translation).
    • Other HPCs (orange, proprietär): Weitere verteilte Hochleistungsrechner im Fahrzeug, die über SOVD adressiert werden.
    • SOVD to UDS Translation (blau, Referenzarchitektur): Protokolltransformator, der SOVD-Aufrufe in UDS-Dienste konvertiert.
    • UDS ECU (orange, proprietär): Klassisches bzw. UDS-basiertes Steuergerät (vormals Classic ECU), das ausschließlich über UDS angesprochen wird.
  • Lokaler AUTOSAR-Adaptive-Knoten (gestrichelter Umfassungsrahmen):
    • Diagnostic Manager (rot, AUTOSAR-standardisiert): Zentraler Diagnosemanager der Adaptive Platform, aufgeteilt in zwei funktionale Einheiten:
      • SOVD Handling: Terminiert die SOVD-Verbindung vom SOVD Gateway und wickelt serviceorientierte Diagnoseanfragen ab.
      • UDS Handling: Verarbeitet klassische UDS-Diagnosedienste auf dem lokalen Host.
    • ara::diag (rot, AUTOSAR-standardisiert): Standardisierte Laufzeit- und Diagnoseschnittstelle zwischen Applikationen und dem Diagnostic Manager.
    • Application A & Application B (rot, AUTOSAR-standardisiert): Diskrete adaptive Applikationen im POSIX-Userspace, die über bidirektionale Ports an ara::diag angebunden sind.
  • Schnittstellen & Protokolle:
    • Remote SOVD Client → Backend Connectivity: SOVD-Protokoll (blauer Pfeil) über die Netzwerkgrenze.
    • Backend Connectivity → SOVD Gateway: Fahrzeuginternes SOVD (blauer Pfeil).
    • Proximity SOVD Client → SOVD Gateway: Lokales SOVD (blauer Pfeil) über die Netzwerkgrenze.
    • SOVD Gateway → Diagnostic Manager (SOVD Handling): Internes SOVD (blauer Pfeil), spezifisch terminiert an der Subkomponente SOVD Handling.
    • Diagnostic Manager ↔ ara::diag: Bidirektionale standardisierte Schnittstelle (schwarzer Doppelpfeil).
    • ara::diag ↔ Application A / Application B: Standardisierte C++ Port-Interfaces (schwarze Doppelpfeile).
    • SOVD Gateway → Other HPCs: Fahrzeuginternes SOVD (blauer Pfeil).
    • SOVD Gateway → SOVD to UDS Translation: Fahrzeuginternes SOVD (blauer Pfeil).
    • SOVD to UDS Translation → UDS ECU: UDS-Protokoll (schwarzer Pfeil, explizit mit UDS beschriftet).

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.

Versionsvergleich KI-generiert · gemini-3.8-flash (via agy)

R22-11 → R23-11 normative Änderung Vorgänger: FIG-02e10a85991bb9c0
  • Diagnostic Manager: Funktional in zwei explizite Subblöcke unterteilt (UDS Handling und SOVD Handling); die SOVD-Verbindung vom SOVD Gateway terminiert nun gezielt am Subblock SOVD Handling.
  • Classic ECU: Umbenannt in UDS ECU (Generalisierung auf das Diagnoseprotokoll statt Bindung an die Classic Platform).
  • Application: Differenzierung der beiden zuvor generischen Anwendungsblöcke in Application A und Application B mit jeweils separater Schnittstellenanbindung an ara::diag.
  • Schnittstelle SOVD to UDS Translation → UDS ECU: Pfeil nun explizit mit dem Protokollbezeichner UDS beschriftet.
  • Legende: Hinzufügung einer formalen Komponenten- und Verbindungsklassifikation (Standardized by AUTOSAR [rot], Part of reference architecture [blau], Proprietary Component [orange], External Component [grün], Pfeil SOVD [blau]).
  • Farbkodierung: Komponenten entsprechend der Legende neu eingefärbt (SOVD Gateway und SOVD to UDS Translation von orange auf blau; Backend Connectivity, Other HPCs und UDS ECU von blau auf orange; Adaptive-Plattform-Elemente rot).
  • Netzwerkgrenzen: Einführung einer gestrichelten horizontalen Trennlinie zwischen Vehicle external network und Vehicle internal network.
  • Systemgrenzen: Zusammenfassung des lokalen Adaptive-Platform-Knotens (Application A, Application B, ara::diag, Diagnostic Manager) in einem gemeinsamen gestrichelten Umfassungsrahmen.

Zugeordnete Anforderungen

Diese Angaben zeigt der Versions-Explorer.

Aus dem Dokument extrahierter Text & Kontext

Begleitender Spezifikationstext:

Explanation of Service-Oriented Vehicle Diagnostics AUTOSAR AP R25-11 2 SOVD Reference Architecture Providing a central SOVD edge node in a distributed system does require some infrastructural components. To achieve this a reference architecture that clusters functions into several blocks has been introduced. This architecture is displayed in Figure 2.1). Main components of this reference architecture are: • SOVD Gateway • Diagnostic Manager • SOVD to UDS Translation Figure 2.1: SOVD Reference architecture 2.1 SOVD Gateway Upon request from a SOVD client the SOVD Gateway acts as SOVD edge node and routes the requests to respective internal SOVD endpoints. The routing takes place based on the entity part in the URI of the SOVD request. The SOVD Gateway must extract this part of the URI and route towards the corresponding endpoint. The setup of potential internal SOVD endpoints can be statically configured or dynamically discovered using mDNS. The forwarding itself takes place on application layer, i. e. the SOVD gateway acts as HTTP reverse proxy. For the configuration of the SOVD Gateway the SOVDGatewayInstantiation has been introduced in the TPS_Manifest. This manifest allows to configure the external SOVD connection towards SOVD clients as well as the internal forwarding targets. 6 of 14 Document ID 1064: AUTOSAR_AP_EXP_SOVD

Vorkommen in AUTOSAR-Releases (3)

Release Dokument Seite Nr. Bildunterschrift im Dokument
R23-11 AUTOSAR_AP_EXP_SOVD S. 6 2.1 Figure 2.1: SOVD Reference architecture
R24-11 AUTOSAR_AP_EXP_SOVD S. 6 2.1 Figure 2.1: SOVD Reference architecture
R25-11 AUTOSAR_AP_EXP_SOVD S. 6 2.1 Figure 2.1: SOVD Reference architecture