Figure 7.4: SOVD Software Update API - concept. Figure elobarates on the difference of vehicle level and component level SOVD Software Update API.

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: Konzeptuelles Komponenten- und Interaktionsdiagramm (Blockdiagramm) der AUTOSAR Adaptive Platform (AP).
• Technischer Zweck: Gegenüberstellung zweier komplementärer Software-Update-Architekturpfade über das standardisierte ASAM SOVD-Protokoll (Service-Oriented Vehicle Diagnostics):
  1. Vehicle Level Update (orchestrierter, flottenweiter Gesamtfahrzeug-Updatepfad).
  2. Component Level Update (direkter, komponentenspezifischer Updatepfad auf ECU-/Instanzebene).
• Funktionale Einordnung: Abgrenzung der Verantwortlichkeiten zwischen den Adaptive Functional Clustern Diagnostics (ara::diag), Update and Configuration Management (ara::ucm), Applikationsschicht und externem SOVD-Zugang gemäß AUTOSAR AP R23-11 / R24-11.

2. Komponenten, Entitäten & Schnittstellen

Entitäten & Rollen

• SOVD Client: Externes Diagnosetool, Cloud-/Flottenbackend oder Werkstatttester, das Diagnose- und Update-Operationen über HTTP/REST-basierte SOVD-Endpunkte anfordert.
• SOVD Gateway: Zentrale Protokoll- und Routing-Instanz an der Fahrzeugperipherie. Terminiert externe SOVD-Sessions und dispatcht eingehende Requests anhand des URI-Pfads/Scopes (Fahrzeug vs. Komponente).
• OTA client: Adaptive Application zur fahrzeugseitigen Entgegennahme und Steuerung von Over-the-Air-Kampagnen. Beinhaltet das SOVD Interface.
• UCM Master: Orchestrierendes Cluster auf Gesamtfahrzeugebene; koordiniert Multi-ECU-Updates, Abhängigkeiten und Sicherheitszustände.
• Driver Interface: Benutzerschnittstelle / HMI-Applikation zur Fahrerinteraktion (Einholen von Zustimmungen, Anzeige von Update-Status und Stillstandsaufforderungen).
• Vehicle State Manager: Steuerungsinstanz zur Ermittlung und Validierung globaler Fahrzeugzustände (z. B. Stillstand, Zündungsstatus, Hochvolt-Sicherheit).
• DM (Diagnostic Manager): Functional Cluster ara::diag; terminiert SOVD-Diagnoseendpunkte für die jeweilige Adaptive-Instanz.
• Diagnostic application: Adaptive Application, die die systemspezifische Update-Geschäftslogik auf Komponentenebene implementiert.
• UCM (Update and Configuration Management): Lokales Functional Cluster auf Instanzebene zur Verwaltung, Verifikation, Speicherung und Aktivierung lokaler Software-Pakete.

Schnittstellen & Interaktionsbeziehungen

• SOVD: Standardisiertes ASAM-SOVD-Protokoll zwischen SOVD Client und SOVD Gateway.
• SOVD: Vehicle Update: Weiterleitung fahrzeugweiter Update-Requests vom Gateway an das SOVD Interface des OTA client.
• SOVD: Component Update: Weiterleitung komponentenspezifischer Update-Requests vom Gateway an den DM.
• ara::ucm::VehiclePackageManagement: Schnittstelle zwischen OTA client und UCM Master zur Übergabe von Vehicle Packages.
• ara::ucm::VehicleDriverApplicationInterface: Bietet dem UCM Master Methoden für Fahrerinteraktionen.
• ara::ucm::VehicleStateManager: Schnittstelle zur Prüfung der Update-Sicherheitsbedingungen vor und während des Flashvorgangs.
• ara::diag: Service-Schnittstelle zwischen DM und Diagnostic application (insb. ara::diag::SovdSwUpdate), entkoppelt das Protokollhandling von der Update-Logik.
• ara::ucm::PackageManagement: Einheitliche Schnittstelle zur Paketübergabe, Integritätsprüfung und Aktivierung auf dem lokalen UCM:
  • Wird im Vehicle-Pfad hierarchisch vom UCM Master aufgerufen.
  • Wird im Component-Pfad direkt von der Diagnostic application aufgerufen.

3. Dynamisches Verhalten & Sequenzablauf

Pfad A: Vehicle Level Update (Orchestriert via UCM Master)

1. Trigger: SOVD Client adressiert den Root-/Vehicle-Update-Endpunkt am SOVD Gateway.
2. Dispatching: Weiterleitung an den OTA client via SOVD: Vehicle Update.
3. Kampagnenstart: OTA client übergibt Kampagnendaten via ara::ucm::VehiclePackageManagement an den UCM Master.
4. Zustandsprüfung & Freigabe: UCM Master fragt fahrkritische Zustände via ara::ucm::VehicleStateManager ab und holt die Fahrerzustimmung via ara::ucm::VehicleDriverApplicationInterface ein.
5. Verteilung & Ausführung: UCM Master transferiert die Software-Pakete per ara::ucm::PackageManagement an die jeweilige Zielinstanz (UCM).

Pfad B: Component Level Update (Lokal via DM & Diagnostic Application)

1. Trigger: SOVD Client adressiert die Komponenten-Ressource am SOVD Gateway.
2. Direktes Routing: SOVD Gateway routet via SOVD: Component Update direkt an den zuständigen DM.
3. Protokollterminierung: DM dekodiert die SOVD-Payload und delegiert die Anfrage über ara::diag (SovdSwUpdate::SovdSwUpdate) asynchron an die Diagnostic application.
4. Payload-Transfer: Die Diagnostic application wickelt den Datenstrom ab (angelehnt an UDS Service 0x38 RequestFileTransfer zur blockweisen Datenübertragung).
5. Paketverarbeitung: Die Diagnostic application übergibt die Blöcke/Pakete über ara::ucm::PackageManagement direkt an den lokalen UCM zur Validierung, Installation und Aktivierung.

4. Normative Relevanz & Entwickler-Hinweise

• Protokoll-Entkopplung (SWS_DM_01796, SWS_DM_01797): Der Diagnostic Manager (ara::diag) verarbeitet nicht die funktionale Update-Logik, sondern ausschließlich das SOVD-Protokollhandling. Entwickler müssen die Update-FSM innerhalb der Diagnostic application implementieren.
• Transfer-Strategien: Der Datenupload auf Komponentenebene basiert funktional auf den Übertragungsmodi von UDS Service 0x38 (RequestFileTransfer gemäß AUTOSAR AP Diagnostics Section 7.3.2.8.22), um flexible Upload-Szenarien (Chunking, Resume, Streaming) abzubilden.
• Dual-Client-Rolle der Diagnostic application: Die Applikation agiert als Service-Provider bzw. Port-Implementierer gegenüber ara::diag und gleichzeitig als Service-Consumer gegenüber ara::ucm::PackageManagement.
• Schnittstellen-Orthogonalität: Die Schnittstelle ara::ucm::PackageManagement ist invariant bezüglich des Aufrufers; sie akzeptiert Aufrufe identisch von der lokalen Diagnostic application (Component Update) wie vom zentralen UCM Master (Vehicle Update).