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

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: UML-Komponentendiagramm / funktionale Systemarchitektur-Übersicht für AUTOSAR Adaptive Platform (AP R25-11).
• Technischer Zweck: Gegenüberstellung der zwei orthogonalen Pfade für Software-Updates über SOVD (Service-Oriented Vehicle Diagnostics, ASAM SOVD / ISO 23806):
  1. Vehicle Level Update (Fahrzeug-Ebene): Flotten- und fahrzeugweite Orchestrierung von Multi-ECU-Update-Kampagnen.
  2. Component Level Update (Komponenten-/Instanz-Ebene): Direktes Update eines einzelnen Funktionsclusters / einer einzelnen AP-Instanz über den Diagnostic Manager (ara::diag).
• Funktionale Einordnung: Veranschaulicht die funktionale Abgrenzung des Functional Clusters Diagnostics: Der Diagnostic Manager wickelt ausschließlich das SOVD-Protokollhandling (ara::diag::SovdSwUpdate) ab, während die Update-Geschäftslogik an eine OEM-spezifische Applikation und das Update and Configuration Management (ara::ucm) delegiert wird.

2. Komponenten, Entitäten & Schnittstellen

Entitäten nach Standardisierungs- und Architekturstatus (gemäß Legende)

• Standardized by AUTOSAR (Rot):
  • UCM (Update and Configuration Management): Lokaler Ausführer von Software-Paket-Operationen auf Instanzebene.
  • V-UCM (Vehicle Update and Configuration Management): Zentraler Koordinator für fahrzeugweite Update-Kampagnen.
  • Vehicle State Manager: Überwacht Fahrzeugzustände (z. B. Stand, Fahrbereitschaft, Hochvolt-Status).
  • Driver Interface: HMI-Anbindung für Fahrer-Interaktion (Zustimmung, Warnmeldungen).
  • Diagnostic Manager: Stack-Komponente für Diagnose- und SOVD-Dienste.
  • OTA Client (Kernkomponente): Empfänger fahrzeugweiter Over-the-Air-Kampagnen.
• Part of reference architecture (Blau):
  • SOVD Gateway: Zentraler fahrzeuginterner Routing- und Entkapselungsknoten für SOVD-Anfragen.
  • SOVD Interface: Protokolladapter des OTA-Clients.
• Proprietary Component (Orange):
  • Diagnostic Application: OEM-spezifische Applikation, welche die Brücke zwischen Diagnose-Stack und UCM bildet.
• External Component (Grün):
  • SOVD Client: Offboard-Tester, Werkstatttester oder Cloud-Backend.

Schnittstellen und Protokolle

• SOVD-Ebene (HTTP/REST / WebSocket):
  • SOVD: Transportkanal zwischen SOVD Client und SOVD Gateway.
  • SOVD: Vehicle Update: Routing-Endpunkt vom Gateway zum OTA Client / SOVD Interface.
  • SOVD: Component Update: Routing-Endpunkt vom Gateway zum Diagnostic Manager.
• AUTOSAR Adaptive Schnittstellen (ara::* C++ APIs):
  • ara::ucm::PackageManagement: Standardisierte Service-Schnittstelle des UCM zur Paketübertragung, Validierung, Aktivierung und zum Rollback; wird sowohl von V-UCM (Vehicle Level) als auch von der Diagnostic Application (Component Level) konsumiert.
  • ara::vucm::VehiclePackageManagement: Kampagnen-Schnittstelle zwischen OTA Client und V-UCM.
  • ara::vucm::VehicleStateManager: Zustandsabfrage- und Sperrschnittstelle zwischen Vehicle State Manager und V-UCM.
  • ara::vucm::VehicleDriverApplicationInterface: Dialogschnittstelle zwischen Driver Interface und V-UCM.
  • ara::diag: Interne IPC-Schnittstelle zwischen Diagnostic Manager und Diagnostic Application (Bereitstellung der SOVD-Software-Update-Methoden via ara::diag::SovdSwUpdate).

3. Dynamisches Verhalten & Sequenzablauf

Pfad A: Component-Level Software Update (Fokus AP SWS Diagnostics)

1. Trigger & Dispatching: Der SOVD Client sendet eine komponentenbezogene Update-Anforderung an das SOVD Gateway. Das Gateway leitet diese als SOVD: Component Update an den Diagnostic Manager weiter.
2. Protokoll-Handling (ara::diag::SovdSwUpdate): Der Diagnostic Manager terminiert das SOVD-Protokoll, validiert die SOVD-Methodenaufrufe ([SWS_DM_01796], [SWS_DM_01797], [SWS_DM_01798]) und reicht die Payload/Steuerbefehle über ara::diag an die Diagnostic Application weiter.
3. Data Transfer Strategy: Große Binärpakete werden nach den Transferstrategien von UDS Service 0x38 (RequestFileTransfer) segmentiert und gestreamt übertragen.
4. UCM-Ansteuerung: Die Diagnostic Application ruft ara::ucm::PackageManagement auf:
   • TransferData / Paket-Upload.
   • ProcessSwPackage (Integritäts- und Signaturprüfung).
   • Activate (Aktivierung der Softwareänderung).
   • Finish / Rückmeldung des Status an den Diagnostic Manager zur SOVD-Response-Generierung.

Pfad B: Vehicle-Level Software Update (Referenzpfad)

1. Trigger: SOVD Client initiiert fahrzeugweites Update über das SOVD Gateway an den OTA Client.
2. Orchestrierung: Der OTA Client adressiert das V-UCM via ara::vucm::VehiclePackageManagement.
3. Precondition & Safety Gate: V-UCM fragt über ara::vucm::VehicleStateManager den sicheren Fahrzeugzustand ab und fordert ggf. über ara::vucm::VehicleDriverApplicationInterface die Fahrerfreigabe an.
4. Verteilung: Nach Freigabe verteilt V-UCM die Einzelpakete parallel/sequentiell via ara::ucm::PackageManagement an die jeweiligen lokalen UCM-Instanzen.

4. Normative Relevanz & Entwickler-Hinweise

• Architektonische Entkopplung im Diagnostics-Cluster: Der Functional Cluster Diagnostics implementiert keine Software-Update-Zustandslogik oder Speicherbereinigung. Entwickler von Diagnostic Applications müssen die Übersetzung von ara::diag-Events in ara::ucm::PackageManagement-Methodenaufrufe vollständig applikativ implementieren.
• Protokoll-Schnittstellenvertrag ([SWS_DM_01796], [RS_Diag_04265]): Der Diagnostic Server muss standardisierte SOVD-Ressourcen für Software-Updates bereitstellen. Der Payload-Transport muss zwingend mit den Mechanismen aus UDS Service 0x38 konform sein (Chunking, Resume-Fähigkeit, Flow-Control).
• Umgehung von V-UCM bei Component Updates: Bei Nutzung von SOVD: Component Update wird das V-UCM umgangen. Die Diagnostic Application ist selbst dafür verantwortlich, Vorbedingungen (z. B. Fahrzeugstillstand, Diagnose-Session, Batteriestatus) abzusichern, bevor ara::ucm::PackageManagement angesteuert wird.
• UCM-Zustandsmodell-Konformität: Methodenaufrufe an ara::ucm::PackageManagement müssen exakt der UCM-State-Machine folgen (kTransferring → kProcessing → kReady → kActivating → kActivated), inklusive deterministischer Fehlerbehandlung via Revert oder Rollback.