Figure 3.1: Solution Approach for SOVD updates

1. Diagrammtyp & Architektur-Kontext

• Diagrammtyp: Funktionale Architekturübersicht / Komponenten- und Schnittstellendiagramm (AUTOSAR Adaptive Platform Reference Architecture).
• Technischer Zweck: Spezifikation der architektonischen Einbindung von ASAM SOVD (Service-Oriented Vehicle Diagnostics) in die Update- und Diagnoseinfrastruktur der AUTOSAR Adaptive Platform (AP). Das Diagramm definiert die Koexistenz und das Routing zweier alternativer Update-Pfade:
  1. Fahrzeugweites Update (Vehicle Update) über die zentrale UCM-Master-Orchestrierung.
  2. Komponentenweites Update (Component Update) über den klassischen Diagnosepfad via Diagnostic Manager direkt an eine lokale UCM-Instanz.

2. Komponenten, Entitäten & Schnittstellen

Entitäten & Klassifikation (gemäß Legende)

• Standardized by AUTOSAR (Rot):
  • UCM (Update and Configuration Management): Lokaler Funktionscluster zur Installation, Aktualisierung und Deinstallation von Software-Paketen auf einer Machine.
  • UCM Master: Zentraler Funktionscluster zur Orchestrierung fahrzeugweiter Software-Updates (Vehicle Packages) über mehrere UCM-Instanzen hinweg.
  • OTA Client (Kernkomponente): Applikation zur Abwicklung von Over-the-Air-Kampagnen.
  • Driver Interface: Interaktionsschicht für Benutzer-/Fahrerzustimmung und Statusrückmeldung.
  • Vehicle State Manager (VSM): Überwacht Fahrzeugsicherheitszustände (z. B. Stand, Ladezustand, Fahrbereitschaft).
  • Diagnostic Manager: Standardisierter Funktionscluster zur Diagnoseabwicklung (ara::diag).
• Part of reference architecture (Blau):
  • SOVD Gateway: Zentraler Endpunkt im Fahrzeug, der externe SOVD-HTTP/REST-Anfragen terminiert, authentifiziert und intern verteilt.
  • SOVD Interface: Adapter-/Schnittstellenschicht des OTA Clients zur Annahme von SOVD-Fahrzeug-Update-Befehlen.
• Proprietary Component (Orange):
  • Diagnostic Application: Herstellerspezifische Applikation, die Diagnoseanforderungen in UCM-Steuerbefehle übersetzt.
• External Component (Grün):
  • SOVD Client: Externer Tester (Werkstatttester, Flottenbackend, Off-Board-Diagnosewerkzeug).

Schnittstellen & Kommunikationsbeziehungen

• SOVD-Protokollebene (Blaue Pfeile):
  • SOVD Client → SOVD Gateway: Standardisierte REST/JSON-Kommunikation.
  • SOVD Gateway → OTA Client (SOVD Interface): SOVD: Vehicle Update (Ressourcenbasierte Endpunkte für ganzheitliche Flotten-/Fahrzeug-Updates).
  • SOVD Gateway → Diagnostic Manager: SOVD: Component Update (Ressourcenbasierte Endpunkte für Steuergeräte-/Komponenten-bezogene Flashvorgänge).
• Adaptive Platform Services (ara::*):
  • ara::ucm::VehiclePackageManagement:
    • Bereitgestellt von UCM Master.
    • Konsumiert von OTA Client (Kampagnenübergabe) und Driver Interface (Zustimmungsdialoge).
  • ara::ucm::VehicleStateManager:
    • Interaktion zwischen Vehicle State Manager und UCM Master zur Freigabe/Sperre von Update-Zuständen.
  • ara::ucm::PackageManagement:
    • Bereitgestellt von UCM.
    • Konsumiert von UCM Master (im Vehicle-Update-Pfad) sowie von Diagnostic Application (im Component-Update-Pfad).
  • ara::diag:
    • Verbindung zwischen Diagnostic Manager und Diagnostic Application zur Ausführung diagnostischer Routinen/Services.

3. Dynamisches Verhalten & Sequenzablauf

Pfad 1: Vehicle Update (Zentral orchestriert)

1. Trigger: SOVD Client adressiert den Vehicle-Update-Endpunkt am SOVD Gateway.
2. Forwarding: SOVD Gateway leitet die Payload an das SOVD Interface des OTA Client weiter.
3. Kampagnenstart: OTA Client ruft Methoden des ara::ucm::VehiclePackageManagement am UCM Master auf (TransferVehiclePackage, etc.).
4. Zustandsprüfung: UCM Master fragt über ara::ucm::VehicleStateManager den Sicherheitsstatus am Vehicle State Manager ab (Inhibit-Bedingungen, z. B. Parkbremse aktiv, kein Fahrbetrieb).
5. Fahrerinteraktion: Synchron/asynchron holt der UCM Master über das Driver Interface (ara::ucm::VehiclePackageManagement) die Zustimmung des Nutzers ein.
6. Deployment: UCM Master dekomponiert das Vehicle Package und steuert über ara::ucm::PackageManagement die Ziel-UCM-Instanzen an (Phasen: Transfer → Process → Activate → Finish/Rollback).

Pfad 2: Component Update (Diagnosegetrieben)

1. Trigger: SOVD Client initiiert ein gezieltes Update einer einzelnen Komponente/Machine.
2. Routing: SOVD Gateway dispatcht an den Diagnostic Manager (SOVD: Component Update).
3. Applikationsaufruf: Diagnostic Manager delegiert den Request über ara::diag an die zuständige Diagnostic Application.
4. Lokale Ausführung: Diagnostic Application fungiert als lokaler Client für den UCM und führt das Update direkt über dessen Service-Interface ara::ucm::PackageManagement aus, unter Umgehung des UCM Master.

4. Normative Relevanz & Entwickler-Hinweise

• Architektur-Entscheidung (Routing): Ein SOVD-basiertes Software-Update ist im System zwingend zu klassifizieren: Entweder als fahrzeugweites Manifest-Update über den UCM Master oder als lokales Komponenten-Update über den Diagnosepfad. Ein Mischbetrieb für dasselbe Package ist unzulässig.
• Service-Deployment & ARA-Bindungen:
  • Diagnostic Application muss als ara::com-Client für ara::ucm::PackageManagement und als Provider für ara::diag-Schnittstellen konfiguriert werden.
  • Der UCM Master benötigt Service-Discovery-Zugriff auf alle UCM-Instanzen im Verbund sowie auf den Vehicle State Manager.
• Sicherheitsanforderungen (Safety/Security):
  • Updates über den UCM Master sind strikt an den Status des Vehicle State Manager gekoppelt; Entwickler von VSM-Modulen müssen deterministische Übergänge in Safe-States gewährleisten.
  • Das SOVD Gateway muss Zugriffsrechte (Authentifizierung/Autorisierung) validieren, bevor Requests an OTA Client oder Diagnostic Manager durchgereicht werden.
• Package-Manifeste: Artefakte für den UCM Master-Pfad müssen als vollständige Vehicle Packages mit übergeordnetem Manifest vorliegen, während der Component-Update-Pfad isolierte Software Packages für die jeweilige Ziel-Machine erfordert.