Figure 11.1: Exemplary vehicle software update scenario

1. Diagrammtyp & Architektur-Kontext

• Diagrammtyp: UML-Verteilungsdiagramm (Deployment Diagram) mit geschachtelten Knoten (Nested Execution Environments & Devices) zur Darstellung der logischen und physikalischen Software-Deployment-Topologie.
• Technischer Zweck: Abbildung des fahrzeugweiten Software-Update-Szenarios gemäß AUTOSAR Adaptive Platform (AP) Release R20-11 (Kapitel Update and Configuration Management – UCM).
• Funktionale Einordnung: Heterogene Architektur-Kopplung von Adaptive-Platform-Knoten (High-Performance Compute / POSIX), Classic-Platform-Steuergeräten (Deeply Embedded / OSEK-basiert) und externen Trigger-Quellen (OTA-Backend vs. lokaler Werkstattiagnose-Tester).

2. Komponenten, Entitäten & Schnittstellen

Externe Entitäten (Off-Board)

• :Backend System: Cloud-/OEM-Server zur Bereitstellung signierter Vehicle Packages / Software Packages für Over-the-Air (OTA) Kampagnen.
• :Diagnostic Client: Werkstatt-Tester / Flashtool, angebunden über standardisierte Diagnoseschnittstellen (z. B. UDS over DoIP nach ISO 13400 / ISO 14229).

Fahrzeugknoten & Ausführungsumgebungen (On-Board)

• «device» Vehicle: Umfassender System-Root-Knoten (Fahrzeugnetzwerkverband).
• «device» gateway: Machine:
  • Zentraler Ingress/Egress-Rechner (HPC / Domain Controller).
  • Beherbergt «executionEnvironment» :Adaptive Runtime (POSIX OS, ara-Core-Dienste).
  • «executable» OTA Client Application: Applikationsebene; terminiert die externe Backend-Verbindung, handhabt Kampagnenmetadaten und steuert den Download.
  • «executable» Update and Configuration Management: Instanz des AUTOSAR AP UCM-Dienstes.
  • «deployment spec» UCM Master: Konfigurationsrolle; fungiert als fahrzeugweiter Koordinator für Multi-Target-Updates (Vehicle Package Management).
• «device» machine1: Machine:
  • Sekundäre Adaptive-Recheneinheit (z. B. ADAS-, Infotainment- oder Zonen-Controller).
  • Beherbergt «executionEnvironment» :Adaptive Runtime.
  • «executable» Update and Configuration Management: Lokaler UCM-Dienst.
  • «deployment spec» UCM Subordinate: Konfigurationsrolle; empfängt Teilpakete (Software Packages) vom UCM Master und führt lokale Paketoperationen aus.
• «device» ecu1: ECU:
  • Mikrocontroller-basiertes Steuergerät mit «executionEnvironment» :Classic Platform (AUTOSAR CP Basic Software Stack, RTE, DCM/FBL).

Schnittstellen & Topologische Relationen

• Gateway ↔ Extern: Drahtlose Verbindung (Mobilfunk/Wi-Fi) zum :Backend System; kabelgebundene Diagnoseverbindung (OBD/Ethernet) zum :Diagnostic Client.
• Gateway ↔ machine1: Fahrzeug-Ethernet; Service-Orientierte Kommunikation (ara::com / SOME/IP) zwischen UCM Master und UCM Subordinate.
• Gateway ↔ ecu1: Interne Buskopplung (CAN-FD, FlexRay oder Automotive Ethernet); UCM Master steuert das CP-Steuergerät über klassische UDS-Diagnosedienste (DCM, Flash Bootloader) oder proprietäre Gateway-Protokolle an.

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

• UCM Master/Subordinate Trennung (ARXML):
  • Entwickler müssen im AUTOSAR-Modell explizit differenzieren, ob eine UCM-Instanz als Master (UcmMasterDeploymentSpec) oder Subordinate (UcmSubordinateDeploymentSpec) deployed wird. Pro Fahrzeugverbund darf nur genau ein UCM Master aktiv sein.
• API-Vertrag (ara::ucm):
  • Die OTA Client Application darf nicht direkt auf das Dateisystem oder Paketmanager des OS (wie dpkg, rpm) zugreifen, sondern muss strikt das Service-Interface ara::ucm::pkgmgr::PackageManager bzw. VehiclePackageManager ansprechen (TransferVehiclePackage, ProcessVehiclePackage, Activate, Finish, Revert).
• Classic Platform Integration:
  • Classic-ECUs erfordern keine UCM-Implementierung, müssen aber über einen AUTOSAR-konformen UDS-Stack (DCM, MEMIF, Flash Bootloader) verfügen, der vom Gateway als Diagnose-Master angesprochen werden kann.
• Sicherheits- & Zustands-Restriktionen:
  • Vor Aktivierung muss über ara::sm sichergestellt werden, dass sich das Gesamtfahrzeug in einem sicheren Betriebszustand befindet (Safe State, z. B. Fahrzeug steht, Zündung aus).
  • Sämtliche Zwischenstände müssen stromausfallfest (power-fail safe) persistiert werden, um unvollständige Flash-Zustände (Bricking) zu verhindern.