Figure 13.1: Vehicle Update Architecture

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: UML-Komponentendiagramm / Deployment-Diagramm mit Schichtenarchitektur (AUTOSAR Adaptive Platform Execution Environments & Systemgrenzen).
• Technischer Zweck: Spezifikation der fahrzeugweiten Over-The-Air- (OTA) und Tester-basierten Update-Architektur (Vehicle Update Management) gemäß AUTOSAR Adaptive Platform (EXP_PlatformDesign, R21-11/R22-11).
• Funktionale Einordnung: Orchestrierung verteilter Software-Updates über heterogene Steuergeräte hinweg. Das Diagramm definiert das Zusammenspiel zwischen fahrzeugexternen Quellen (Cloud-Backend, Diagnosetester), fahrzeuginterner Koordination (UCM Master), fahrzeugeigenen Zustands-/Fahrersicherheitsinstanzen (VSM, VDI), knotenlokalem Update-Management (UCM, SM, EM) sowie der Flash-Anbindung von Classic AUTOSAR ECUs über ISO 22900-2 (D-PDU API).

2. Komponenten, Entitäten & Schnittstellen

Externe Entitäten & Artefakte

• Backend: Cloud-Infrastruktur; liefert das Gesamt-Artefakt «deployment...» VehiclePackage aus, welches einzelne SoftwarePackage A und SoftwarePackage B aggregiert («deploy»-Beziehung).
• Diagnostic Client: Stationärer Diagnosetester (Werkstatttester); kann alternativ/ergänzend SoftwarePackage C über einen fahrzeugseitigen DoIP socket («optional») einbringen.
• Driver Interface (from Actors): Physischer Fahrer/Bediener; interagiert mit der Vehicle Driver Interface-Applikation (Einwilligung, Installationsbestätigung, Countdown).

Fahrzeuginterne Hardware- und Laufzeitumgebungen

• Vehicle: Physische Fahrzeugbegrenzung.
• «device» ECU (Adaptive Platform ECU): Zentrales Steuergerät / HPC-Knoten.
  • «executionEnvironment» Machine: Host-Betriebssystem / POSIX-Instanz.
    • «executionEnvironment» Autosar Adaptive Application layer (Applikationsebene):
      • OTA Client: Adaptive Application; terminiert die Backend-Verbindung via Backend-Port, extrahiert das VehiclePackage und übergibt es an den UCM Master über VehiclePackageManagement («use»).
      • Vehicle State Manager (VSM): Adaptive Application; prüft/garantiert Fahrzeugsicherheitszustände (z. B. Stillstand, Ladezustand, Parkbremse) und stellt Status via VSM-Port über ara::com bereit («use»).
      • Vehicle Driver Interface (VDI): Adaptive Application; Benutzeroberfläche zur Einholung von Fahrer-Zustimmungen; angebunden an UCM Master via VDI-Port über ara::com («use»).
      • Flashing Adapter: Adaptive Application; Brücke zu Classic ECUs. Konsumiert PackageManagement (UCM Sub-Rolle) über ara::com und spricht die D-PDU API ISO22900-2 an.
      • Diagnostic Application: Adaptive Application zur Verarbeitung von Diagnose-Update-Pfaden über den Diagnostic Manager.
    • «executionEnvironment» AUTOSAR Adaptive Platform (Plattform-Dienste/Foundation):
      • «service» UCM Master: Zentrale Orchestrierungsinstanz für das Fahrzeug-Update. Exponiert Services:
        • VPM (VehiclePackageManagement): Interface für OTA Client.
        • VSM (VehicleStateManager): Schnittstelle zur Abfrage von Sicherheitsbedingungen.
        • VDI (VehicleDriverApplication): Schnittstelle zur Fahrerinteraktion.
        • UCM Sub: Steuerkanal zur Verteilung von Teilpaketen an lokale UCMs und Flashing Adapter.
      • «service» UCM (Update and Configuration Management - Subordinate): Knotenlokaler Dienst zur Installation, Aktivierung und Verifikation von SoftwarePackages auf der lokalen Machine; exponiert PackageManagement (ara::com).
      • Diagnostic Manager (DM): Terminiert fahrzeugexterne Diagnoseverbindungen über den DoIP socket (ISO 13400) und bindet an PackageManagement / Diagnostic Application an.
      • SM (State Management): Empfängt UpdateRequest vom lokalen UCM; koordiniert Plattform-Zustandswechsel für Vorbereitung, Stoppen von Prozessen und Aktivierung.
      • EM (Execution Management): Wird von SM gesteuert (Zustandsübergänge, Start/Stopp von Prozessen/Manifesten).
      • D-PDU API ISO22900-2: Plattformkomponente für standardisierte Diagnose- und Flashprotokolle; bindet über DoIP socket / Feldbus an nachgelagerte Steuergeräte an.
• «device» Classic AUTOSAR ECU: Peripheres Steuergerät; empfängt Binär-Updates/Flashdaten vom Flashing Adapter über die D-PDU API.

3. Dynamisches Verhalten & Sequenzablauf

1. Transfer & Ingestion (Asynchron):
   • OTA-Pfad: Backend transferiert VehiclePackage an den OTA Client («deploy»). Der OTA Client ruft Methoden des VehiclePackageManagement (VPM) am UCM Master via ara::com auf.
   • Tester-Pfad: Diagnostic Client verbindet sich via DoIP socket mit dem Diagnostic Manager, welcher Update-Kommandos an die PackageManagement-Schnittstelle routet.
2. Sicherheits- & Zustandvalidierung (Gating):
   • UCM Master fragt vor Entpacken und Weiterleitung über VDI die Fahrerbestätigung ab (Vehicle Driver Interface).
   • UCM Master synchronisiert und verifiziert die fahrzeugweiten Voraussetzungen (z. B. Standby, Fahrstufe P, Batterielevel) zyklisch oder ereignisgesteuert über VSM (Vehicle State Manager).
3. Paketverteilung (Fächerung):
   • UCM Master zerlegt das VehiclePackage in gerätespezifische Pakete:
     • Lokale Pakete (SoftwarePackage A/B) werden über die Service-Schnittstelle UCM Sub an die lokale UCM-Instanz via PackageManagement übertragen.
     • Classic-ECU-Pakete werden an den Flashing Adapter übergeben.
4. Lokale Koordination & Vorbereitung (Local Machine):
   • Lokaler UCM meldet UpdateRequest an SM (State Management).
   • SM initiiert den Wechsel des Machine-States bzw. Function Groups über EM (Execution Management), um betroffene Applikationen kontrolliert zu terminieren oder in einen Update-Modus zu versetzen.
5. Klassisches Flashen (Classic ECU):
   • Der Flashing Adapter serialisiert/konvertiert die Daten und nutzt die D-PDU API ISO22900-2, um das Flashen über Busse (DoIP, CAN, FlexRay) auf der Classic AUTOSAR ECU durchzuführen.
6. Aktivierung, Verifikation & Rollback:
   • Nach erfolgreichem Schreiben triggert der UCM Master die parallele Aktivierung.
   • SM und EM starten neue Software-Instanzen. Scheitert die Verifikation (Self-Tests), wird über UCM und UCM Master ein fahrzeugweites Rollback auf die vorherige Partitions-/Software-Revision veranlasst.

4. Normative Relevanz & Entwickler-Hinweise

• UCM Master vs. UCM Standard-Spezifikation (SWS UCM):
  • Entwickler müssen strikt zwischen ara::ucm (knotenlokal, standardisierte C++-API für Paketinstallation) und UCM Master (fahrzeugweite Kampagnen-Logik) differenzieren. Der UCM Master ist ein Aggregator, der mehrere Subordinate-UCMs parallel steuert.
• Service-Interfaces via ara::com:
  • VehiclePackageManagement, VehicleStateManager und VehicleDriverApplication sind serviceorientierte Schnittstellen. Service Discovery (via SOME/IP oder IPC) muss in den Execution-Manifesten für den UCM Master und die korrespondierenden Applikationen (OTA Client, VSM, VDI) konsistent konfiguriert sein.
• State Management Interaction (UpdateRequest Contract):
  • Der lokale UCM darf Prozesse nicht direkt terminieren. Das Stoppen und Starten obliegt ausschließlich dem EM, getriggert durch SM. Entwickler von Adaptive Applications müssen signalfest gegen SIGTERM/Graceful Shutdown sein, wenn das State Management sie im Zuge eines UpdateRequest herunterfährt.
• Classic ECU Legacy-Integration via Flashing Adapter:
  • Classic ECUs besitzen keinen Adaptive-Stack und keine UCM-Client-Bibliothek. Entwickler müssen im Flashing Adapter proprietäre oder OEM-spezifische Flash-Bootloader-Sequenzen (UDS ISO 14229-1 Routinen wie $34 RequestDownload, $36 TransferData, $37 RequestTransferExit, $31 RoutineControl) über die D-PDU-API kapseln.
• Vehicle Safety State Constraints:
  • Fehlendes Signal-Feedback von VSM blockiert die UCM Master-Zustandsmaschine zwingend (keine unautorisierte Aktivierung während des Fahrbetriebs – ASIL-D-relevante Absicherung der Activation Phase).