Figure 12.1: Exemplary vehicle software update scenario

1. Diagrammtyp & Architektur-Kontext

• Diagrammtyp: UML-Verteilungsdiagramm (Deployment Diagram), kombiniert mit Komponenten- und Manifest-Spezifikationen («manifest»-Abhängigkeiten) zur Abbildung der Software-Deployment- und Paketierungs-Topologie.
• Technischer Zweck: Spezifikation des fahrzeugweiten Software-Update-Szenarios gemäß AUTOSAR Adaptive Platform (AP) Release R21-11 (Kapitel Update and Configuration Management – UCM).
• Funktionale Einordnung: Verteilung und Zuordnung von Software-Komponenten-Manifesten (OTA Client, UCM Master, UCM Subordinate) auf physische Steuergeräte (gateway: Machine, machine1: Machine, ecu1: ECU) im heterogenen Verbund aus Adaptive Platform (POSIX/HPC) und Classic Platform (CP).

2. Komponenten, Entitäten & Schnittstellen

• Externe Entitäten (Off-Board):
  • :Backend System: Cloud-/OEM-Server für OTA-Software-Pakete (Vehicle Packages).
  • :Diagnostic Client: Lokaler Werkstatt-Tester / Flashtool (UDS over DoIP nach ISO 13400 / ISO 14229).
• Fahrzeugverband & Ausführungsknoten (On-Board):
  • «device» Vehicle: Gesamtfahrzeugnetzwerk.
  • «device» gateway: Machine: Zentraler Ingress-/Rechenknoten mit «executionEnvironment» :Adaptive Runtime. Beherbergt die Executables «executable» OTA Client Application und «executable» Update and Configuration Management.
  • «device» machine1: Machine: Sekundärer Adaptive-Knoten mit «executionEnvironment» :Adaptive Runtime und dem Executable «executable» Update and Configuration Management.
  • «device» ecu1: ECU: Klassisches Steuergerät mit «executionEnvironment» :Classic Platform (AUTOSAR CP Stack, Bootloader/DCM).
• Software-Komponenten & Manifest-Spezifikationen (Off-Node/Modell-Ebene):
  • OTA Client: Komponentendefinition für OTA-Backend-Kommunikation und Download-Steuerung.
  • UCM Master: Komponentendefinition für fahrzeugweite Update-Orchestrierung (Vehicle Package Management).
  • UCM Subordinate: Komponentendefinition für maschinenlokale Paketinstallation (Software Package Management).
• Manifest-Abhängigkeiten («manifest»):
  • OTA Client Application (Gateway) → OTA Client.
  • Update and Configuration Management (Gateway) → UCM Master sowie UCM Subordinate (Gateway fungiert als Master und zugleich als lokales Subordinate-Target).
  • Update and Configuration Management (machine1) → UCM Subordinate.
• Schnittstellen & Busanbindungen:
  • Extern ↔ Gateway: Drahtlos (Backend) bzw. kabelgebunden (Diagnostic Client).
  • Gateway ↔ machine1: Fahrzeug-Ethernet (SOME/IP via ara::com).
  • Gateway ↔ ecu1: Fahrzeugbus (CAN-FD/FlexRay/Ethernet) via UDS/DCM.

3. Dynamisches Verhalten & Sequenzablauf

1. Triggering & Ingestion:
   • OTA-Pfad: :Backend System notifiziert die OTA Client Application. Diese lädt das Vehicle Package via TLS/HTTPS herunter und übergibt es über die interne UCM-C++-API (ara::ucm::pkgmgr::VehiclePackageManagement) an den UCM Master.
   • Diagnose-Pfad: :Diagnostic Client adressiert das Gateway via DoIP/UDS (TransferData, RequestDownload, RoutineControl).
2. Paket-Validierung & Dekomposition:
   • Der UCM Master validiert die Signatur des Vehicle Package (Integritäts- und Authentizitätsprüfung via ara::crypto).
   • Parsen des Vehicle Package Manifests; Auflösung von Abhängigkeiten und Zielzuweisungen (machine1, ecu1, lokales Gateway).
3. **Verteilung (Transfer):**
   • Adaptive Subordinates: Streaming der systemspezifischen Software Packages via SOME/IP an den UCM Subordinate auf machine1.
   • Classic Platform: UCM Master initiiert diagnostische Session (0x10) und Programmiersequenz (RequestDownload 0x34, TransferData 0x36) in Richtung ecu1: ECU.
4. **Vorbereitung & Staging (Process):**
   • UCM Subordinate entpackt und verifiziert lokale Pakete und schreibt diese in redundante Partitionen (A/B-Staging) oder Overlay-Bereiche.
   • ecu1: ECU flasht die Daten über den Flash Bootloader in inaktive Flash-Bänke.
5. **Aktivierung & Synchronisation (Activate):**
   • Synchronisierter Aktivierungsaufruf durch den UCM Master nach erfolgreicher Verifikation aller Knoten.
   • Interaktion mit dem State Management (ara::sm) und Execution Management (ara::exec) für Prozessneustarts bzw. ECU-Resets.
6. **Abschluss oder Rollback (Finish / Rollback):**
   • Konsistente Bestätigung an :Backend System bzw. :Diagnostic Client.
   • Bei Fehlern (z. B. Integritätsprüfung schlägt fehl): Koordiniertes Rollback aller betroffenen Subordinates und ECUs auf den vorherigen Softwarestand.

4. Normative Relevanz & Entwickler-Hinweise

• AUTOSAR-Spezifikationsbezug: AUTOSAR AP R21-11 (Update and Configuration Management sowie TPS Manifest Specification).
• Manifest-Modellierung: Die vormaligen internen UML-«deployment spec»-Elemente wurden durch formale AUTOSAR-Manifest-Beziehungen («manifest») ersetzt. Entwickler müssen für Executables konkrete Software-Package- und Execution-Manifeste konfigurieren.
• Dual-Rolle des Gateways: Das Executable Update and Configuration Management auf dem Gateway manifestiert sowohl UCM Master als auch UCM Subordinate. Entwickler müssen beachten, dass das Gateway für lokale Updates seine eigene Subordinate-Instanz adressiert, analog zu entfernten Knoten wie machine1.
• Klassische ECU-Integration: ecu1 besitzt kein eigenes UCM-Manifest; die Aktualisierung erfolgt über das UCM-Master-Backend via UDS-Diagnosedienste (DCM/FBL).